Blog5 min read

Your Messages Are Not Only Yours. The ChatGPT iMessage Plug-in Assumes They Are.

OpenAI's Apple Messages plug-in reads, sends and deletes your texts. The privacy debate is aimed at the wrong target: consent in messaging is structurally two-sided, and the consent model here is one-sided.

MB
Michael Bennett · AI marketing systems
A phone lying face down on a kitchen table late in the evening, beside two used cups and a set of keys.

On August 20, OpenAI shipped a ChatGPT plug-in for Apple Messages. It can search your iMessage, SMS and RCS history, draft replies, delete messages, and send texts on your behalf. It works with Codex and ChatGPT Work, so this is aimed at professional use rather than only personal convenience.

The privacy conversation that followed has been aimed at the wrong target. It has focused almost entirely on what OpenAI can see of your data, which is a reasonable question, and a less interesting one than the question underneath it.


Two details from the setup

Before the larger point, two specifics that are doing more work than the headline.

It requires Full Disk Access.

That is not a messaging permission. It is read and write access to effectively everything on the machine. The permission granted is dramatically broader than the feature requested, which is a familiar pattern on macOS (the message database sits somewhere that requires it) but familiarity is not the same as proportionality. OpenAI states the plug-in runs locally and does not build a full index of your messages. Both of those may be entirely true. Neither is what Full Disk Access grants, and the grant is what persists.

OpenAI's own warning about persistent approval.

The company notes that enabling it removes your final opportunity to review a message before ChatGPT sends it as you.

As you. The recipient sees your name, your number, your thread. There is no marker distinguishing a message you wrote from one written on your behalf, because the entire point is that there isn't one.

ChatGPT + Apple Messages, CONSENT & MESSAGING

The structural problem

Here is the part that is not really about OpenAI, and will outlast this particular product.

Consent in messaging is inherently two-sided. The consent model here is one-sided.

Two columns describing the same permission. The party who consented read the dialog, granted Full Disk Access and can revoke it. The parties who did not include everyone who has ever texted you; they were never asked and cannot revoke it.
The permission is one grant. The people inside its scope are everyone who has ever trusted you with a message.

You can consent to all of it. You read the permission dialog, you understand the tradeoff, you decide the convenience is worth it. That is a legitimate choice about your own data.

The colleague who texted you a salary figure did not make that choice. The friend who sent you something at 2am did not. The client who shared something commercially sensitive on the assumption that it stayed between two phones did not.

Every message in your archive was written by someone who made an assumption about its audience at the moment they sent it. That assumption was part of why they sent it, and in many cases part of what they sent.

One party can now change that assumption unilaterally, retroactively, for the entire history of the thread.

This is not a hypothetical about future messages. The plug-in searches your existing archive. Every confidence anyone has ever placed in you by text is inside the scope of a permission they were never asked about and cannot revoke.


Why we are bad at reasoning about this

We have had roughly a decade of practice thinking about the privacy of data we generate. Cookie banners, tracking consent, data subject requests, the right to deletion, the entire apparatus is built around the idea that data is about you and therefore yours to control.

We have almost no framework for the other category: data that other people generated and handed to us in confidence.

Your message archive is overwhelmingly the second kind. Half of every conversation was written by someone else. The privacy interest in those messages is not solely yours, but the access control over them is entirely yours, and that mismatch is the whole problem. The permission system is built around device ownership. The confidence was placed in a person.

Consent frameworks handle "my data, my choice" well. They handle "data about our conversation, in my custody, that you cannot reach" not at all.


This shipped into an active dispute, which is worth dating carefully because it is moving.

Apple sued OpenAI in July 2026 over alleged trade secret misappropriation. On August 3, Apple filed a motion for a preliminary injunction. OpenAI responded publicly (its rebuttal is titled "Apple is getting this wrong") and filed a 31-page motion to dismiss on August 5, arguing Apple failed to identify specific trade secrets or demonstrate reasonable secrecy measures.

No court has ruled. The preliminary injunction hearing is set for October 1, 2026.

Meanwhile the commercial relationship continues: ChatGPT remained integrated with Siri as of mid-August, and neither company has moved to terminate that partnership. The suit concerns alleged trade secret misuse, not the integration.

So a product that reads Apple users' most private data on Apple's own platform shipped while Apple was seeking to enjoin the company shipping it. That is not an accident of timing. It is a position, and until October 1 it is an unresolved one. Anything written about this before that date, including this piece, is provisional.


What this means if you run a business

If you operate anywhere near a regulated environment, the question is not whether you trust ChatGPT with your messages.

It is whether your counterparties consented to a third party processing theirs.

That reframing has teeth:

Confidentiality obligations do not distinguish by channel. If a client shares something under an NDA and it arrives by text, the obligation attached to the information, not to the medium. A tool with access to that thread is a processor of that information, and your agreement probably has something to say about processors.

"It runs locally" is a technical claim, not a legal one. It may materially reduce risk. It does not answer whether disclosure to the tool was permitted.

Legal hold and discovery. A plug-in that can delete messages sits awkwardly beside any retention obligation. That is a conversation to have before enabling it, not after.

Regulated communications. In sectors with supervision requirements for business communications, an AI that sends messages as you creates records whose authorship is genuinely ambiguous.

Consider a policy before someone asks. The useful version is narrow: which threads are in scope, whether client communications are excluded, and whether persistent send approval is permitted at all. The last of these is the one that matters most, because it is the setting that removes the human from the loop entirely.


The question worth sitting with

None of this requires believing OpenAI is acting in bad faith. The engineering may be exactly as described. The local processing may be real.

The problem is structural and would exist regardless of vendor: a permission model built around device ownership, applied to data whose privacy interest is shared, with no mechanism for the other party to express a preference, or even to know.

The clarifying test is not whether you would enable this.

It is whether you would want a client to enable it on a thread with you.

If the answer to those two differs, that gap is the thing worth thinking about.

MB
Michael Bennett
I build AI marketing systems that acquire, convert & retain customers.

Working out where AI actually fits in your marketing?

I write these while building the systems behind them: measurement, creative pipelines, and agents that do real work. Connect on LinkedIn and tell me what you are working on. That is where these conversations start.

Connect on LinkedIn