On August 20, OpenAI added an Apple Messages plugin to the ChatGPT desktop app for macOS. Once connected, ChatGPT can read and search iMessage, SMS, and RCS conversations on that Mac, and can also draft, send, and delete messages. It's available on every subscription tier, and works the same way inside ChatGPT Work and Codex.
The boundaries are drawn tightly. The plugin ships only with the Apple silicon build of the desktop app — Intel Macs don't get it — and the capability isn't available on the web or mobile apps. To use it, you need a Mac with Apple's own chips and must grant the Messages app's system permission.
A default checkpoint you can switch off
OpenAI put the safety valve at the sending step. By default, both the message body and the recipient have to be reviewed by the user before anything goes out. Anyone who finds that tedious can turn off per-conversation confirmation, after which messages in that conversation are sent directly.
The wording OpenAI uses for that toggle is blunt: standing authorization removes "your last chance to review before ChatGPT sends a message as you."
That one line lays bare the hardest part of permission design. Approving every message is safe but gets annoying fast; granting blanket access is convenient, but nothing stops things from going wrong once it's on. Which way most people end up choosing is easy to guess — just look at how many apps get clicked through to "Always Allow."
From reading to sending
Reading and writing are permissions of a different order. When it reads your messages, the model gets context that makes its answers more relevant; when it sends a message on your behalf, it's using your social identity — whoever's on the other end sees you.
OpenAI isn't alone in taking this step. Over the past quarter, mainstream assistants have been moving from read-only integrations toward write actions, opening up email, cloud storage, and calendars one after another. The desktop is the easiest place to make that connection: the app is installed locally, and once system permission is granted, the assistant can reach local data directly — no need to wait for a platform to open an API, and no server-side integration approval process to go through.
The risk surface grows along with it. The combination of reading incoming messages and being able to send messages on the user's behalf is a textbook target for prompt injection — a carefully crafted text from a stranger lands in the model's context, and if the user has already turned off send confirmation, there's one less human checkpoint on whatever happens next. This part is speculative risk analysis; there's no public incident yet, but the permission combination is there.
"Runs locally" is a vague promise
OpenAI told Bloomberg that the plugin runs on-device and doesn't build an index of every message. That statement leaves plenty of room for interpretation: not indexing everything doesn't mean fragments aren't sent to the cloud at query time, and the plugin running locally doesn't mean inference runs locally too. Reporters pressing for more detail haven't gotten a clearer answer yet.
The fact that it ships only for Apple silicon is itself a clue. An arm64-only release usually points to a local component that depends on Metal or the Neural Engine; if everything ran in the cloud, there'd be little reason to exclude Intel Macs.
An awkward spot for Apple
Messages is one of the stickiest apps in Apple's ecosystem. Now a third-party assistant has gained read-and-write access to it, going through macOS's own permission channel, and Apple hasn't said a word about it.
Given the pace Apple has moved at with Siri over the past couple of years, a capability like "read your messages and reply for you" should have come from the system assistant first. That spot has been taken by someone else.
Sources: 9to5Mac, TechCrunch, CocoLoop, Bloomberg, OpenAI's official documentation; the plugin's availability, chip requirement, and send-approval mechanism were cross-checked across multiple reports.