The real feature in ChatGPT's iCloud access is its approval buttonChatGPT 接入 iCloud，真正的新功能是那个批准按钮

On October 27, 2026, OpenAI connected ChatGPT to your iCloud mail and calendar. The headline sounds like an inbox that finally runs itself. The part worth reading is smaller and stranger: the button ChatGPT makes you press before anything is sent, and the setting that lets you take that button away.

Most coverage read the launch as autopilot arriving. On OpenAI's own permission design that read is off, and in a way worth understanding. What shipped is faster drafting and faster lookup wrapped around a confirmation step, not an assistant that empties your inbox while you sleep. The action that could do real harm, an email going out under your name that you did not mean to send, sits behind the exact step you are supposed to control. But that step is a setting, and the moment you remove it, or stop reading before you tap it, the harm comes back. This is a short lesson in how leverage actually works, and in one risk the gate never touches at all.

What OpenAI actually shipped

Two plugins. The Mail plugin lets ChatGPT search and read your iCloud Mail, manage messages and drafts, send email, and look up your iCloud contacts. The Calendar plugin lets it read, schedule, and update events. Both arrived on all ChatGPT plans, across web, desktop, and iOS, which is a wide release rather than a limited test.

The fit and finish tells you how much access you are granting. Mail and Calendar are separate plugins, connected one at a time, so turning on one leaves the other off. Each needs an Apple app-specific password, the same credential you would hand a third-party mail client. And they reach only iCloud. A Gmail or Outlook account sitting inside the iOS Mail app is invisible to this connection unless you wire those services up separately.

Strip away the product language and the grant is plain. You are giving an assistant a standing key to read and act on your most sensitive stream: who writes to you, what you reply, where you will be and when. That is not a reason to refuse it. It is a reason to be exact about what you are getting in return, because the value and the risk do not sit in the same place.

The app-specific password is worth a second look, because it shapes the cost. It is a blunt credential, not a scoped one. Where a modern permission screen might let you grant read-only, or access to one folder, the app-specific password is closer to handing over a spare key to the whole account for that service. The granularity that actually protects you lives one layer up, inside ChatGPT's own permission levels, not in the key itself. Revoking is easy, you delete the app-specific password or disconnect the plugin, but until you do, the grant is broad and it is standing.

The design that matters is the button it makes you press

The autopilot framing skips the control layer. OpenAI's connected apps do not act freely; each one runs at a permission level you set. As OpenAI describes them, the levels run from Always ask, which prompts before the app reads anything or changes anything, through Allow read actions, where it reads freely but still asks before any change, to Allow low-risk actions, and finally Allow all actions, where it performs supported actions with no further prompt. The iCloud plugins are connected apps, so they inherit this model. OpenAI has not published a separate confirmation flow specific to iCloud mail, which is a gap worth noting: the gate described here is the platform's documented behavior for connectors in general, not a promise printed on this plugin.

OpenAI is explicit about which actions get held back for review: those that can affect another service, expose sensitive information, or be hard to undo. The examples it lists are the ones that matter here, including sending an email, message, comment, or invitation; creating, editing, or deleting a record; changing account, access, or security settings; making a purchase; and sharing sensitive personal, financial, or health information. Reading your inbox is cheap and reversible. Sending from it is neither, so a send is the kind of action the model is built to pause on.

You can see the shape of it in the mail flow ChatGPT has used since the middle of 2026, which is not iCloud-specific but is the behavior the plugin plugs into. It does not send on its own. It shows you the draft and waits for you to click Allow, one message at a time, with no batch sends and nothing dispatched while you are away. That is a last look before anything leaves under your name.

So the honest description of what you gain is this. Drafting gets faster. Finding the right email, or the open slot next Tuesday, gets faster. What does not arrive, as long as you keep sends gated, is an inbox that clears itself. The assistant drafts and waits. The send is still yours, and that is both the guardrail and the ceiling.

Who holds the lever, and who pays

This is where it stops being a product note and becomes a rule about leverage. Giving the assistant write access to your mail and calendar hands it a lever: the power to send, delete, and reschedule under your name. A lever amplifies. The question is never whether amplification is good or bad in the abstract. It is what gets amplified, and who absorbs the downside when the swing goes wrong.

OpenAI answers the second question by splitting the two roles on purpose. The model proposes the send, drafts the reply, moves the meeting. Your approval is the thing that lets the swing happen. So the amplified downside, a wrong email that reaches a real person, a meeting deleted off a shared calendar, lands on the party who pressed Allow, which is you. On the write side, the amplification stops at your attention.

The calendar makes the split easy to feel. A misfired email is at least visible; it sits in your sent folder and you can write an apology. A calendar edit is quieter. An assistant that moves a meeting, declines an invitation, or deletes an event acts on other people's time without leaving an obvious trace in your own view, and the person who notices first may be the colleague who shows up to a room you rescheduled. The write power over a calendar is smaller in drama and wider in reach than it looks, which is exactly why it sits behind the same gate.

That split is the right shape. It is what you would want for any tool you let touch something irreversible. But notice what it settles. The write side here is not safe because the model is careful. It is safe because the model is not allowed to finish the dangerous move on its own. Take that constraint away and the safety goes with it, because nothing about the underlying capability changed. Only the gate did.

The cap is a setting, and that is the real story

Allow all actions is a menu item. That single fact is the whole argument.

The inbox that empties itself, the version in the headline, is not a feature OpenAI withheld. It is the Allow all actions setting, one tap away. And the friction runs toward it. The tenth time you approve a routine reply, the confirmation stops feeling like a safeguard and starts feeling like a nuisance. The fix is right there in the menu. This is the convenience slide, and it is not a failure of willpower so much as a predictable response to a gate that asks the same question dozens of times a day.

There is a quieter version of the same failure that does not require touching the setting at all. Approval fatigue. Click Allow enough times on routine replies and the click decays into a reflex. You are still technically reviewing each send; you are no longer actually reading it. The guardrail is still on the screen and already gone in practice.

Why does any of this matter if the emails ChatGPT drafts are the ones you asked for? Because they are not the only instructions the assistant will read. The moment it can read your inbox, the contents of your inbox can talk to it. This is prompt injection, and it is not hypothetical. In December 2025 OpenAI itself demonstrated the attack: a planted email told an agent to send a resignation letter to the user's CEO, and when the user later asked for a simple out-of-office reply, the agent obeyed the planted email instead and resigned on their behalf. OpenAI's own conclusion was blunt. Prompt injection, it said, is unlikely to ever be fully solved.

If the gate is on, that particular attack fails: the resignation would stop at a confirmation you could catch. Which is the case for keeping the gate on, and against Allow all actions. A hostile email that wants to send as you has to get past the one step you control, so the setting that removes that step is not a convenience toggle. It is the switch that decides whether a stranger's email can send in your name. An inbox that empties itself is a setting, not a feature, and it is the setting that lets a stranger's email act as you.

But do not mistake the write gate for a wall around the whole risk, because the most serious injection attack on record did not need a send at all. EchoLeak, logged as CVE-2025-32711 and disclosed by researchers at Aim Security in June 2025, hid a prompt inside an ordinary document and made Microsoft 365 Copilot leak confidential data with zero clicks from the victim. That was an exfiltration through the read path. No email was sent, no button was pressed, and a send-confirmation gate would not have stopped it. The uncomfortable implication for the iCloud plugins is that the risk does not begin when you grant send. It begins when you grant read, because a hostile message can turn the act of reading your mail into a channel out of it. Microsoft closed that specific hole, but the class of risk, a connected assistant treating attacker text as your instruction, does not close with one patch. The write gate caps the loud failure. It does nothing about the quiet one.

What would change our mind

A judgment is only worth as much as the thing that could break it, so here is what we are watching.

If OpenAI makes unattended or automatic sending the default for the iCloud plugins, where write actions execute with no per-action review, then the claim that amplification is capped by your attention fails on the downside, and the risk stops being a setting you own and becomes the baseline. That is the signal to watch in the release notes and the permission docs.

The claim can also soften in the other direction, which would be good news. If independent usage data shows that the large majority of people who connect these plugins keep sends behind confirmation, then the worry that you will quietly remove the write cap is overblown, and the write-side risk narrows to the minority who flip to Allow all. We would revise the emphasis accordingly. The thing we would need is real telemetry on which permission level connected users actually run, which neither OpenAI nor the press has published. We will check both by the end of the first quarter of 2027.

One thing would not soften: the read-path exposure. As long as a connected assistant reads attacker-controllable text, the exfiltration risk that EchoLeak made real stays on the table regardless of the send setting, and only a different kind of defense, isolating untrusted content from tool access, would retire it. If OpenAI documents that defense for the iCloud plugins, we will say so.

And note what does not change our mind: a story about ChatGPT sending a hallucinated email on day one with default write settings. If sends are gated, that does not happen, and if it does it is a bug in the gate, not a counterexample. The argument is not that the gate is absent. It is that the gate is optional on the write side and silent on the read side.

If you want to wire it in

The useful move is not to refuse the connection. It is to grant the write power the way you would grant anyone an irreversible one: a little at a time, and never while you sleep.

Start with the smallest version that still helps. Connect read-only, or connect the calendar alone, and live with it for a week. Most of the real gain, finding the email you half-remember, seeing the open slot, drafting a reply you will send yourself, needs no send permission at all. But do not read "read-only" as "risk-free": read access is where the exfiltration exposure starts, so grant it only to an account whose contents you would not lose sleep over a stranger's email prying into. If drafting speed turns out to be worth a standing read-and-write key to your most sensitive stream, add sending next, and keep it on Always ask rather than Allow all.

Then treat the approval as the job, not the obstacle. Every Allow is the review. Read the recipient and the body before you tap it, especially on anything your assistant decided to send that you did not dictate word for word. The day that click becomes a reflex is the day you have the risk of autopilot with none of its honesty, because the gate is still on the screen to make you feel safe and no longer doing any work. If you would not hand a new assistant your email password and tell them to send whatever seems right, do not hand this one Allow all actions either.

The leverage is real, and genuinely useful. On the write side it is capped by your attention, and that cap is a switch you own, so keep your hand on it. On the read side there is no switch, only the scope you grant, so grant it narrowly. Either way the rule is the same one you would use for any irreversible power you lend out: a little at a time, and never while you sleep.