Claude Code's New Privacy Check Is Stopping Harmless Commands, and Unattended Runs Still Say 'Success'

On November 2, Anthropic shipped Claude Code 2.1.317 with a new safety check. In the release notes, the check is one line: Claude Code now asks before a web or shell command sends the user's account email address out over the network. Within two days, people running Claude Code without anyone watching found it can stop work that sends nothing at all.

The check exists because of a real leak. Back in August, version 2.1.234 told the model to use the signed-in email only to identify the user. That was a written instruction, not a lock. Two users then reported that research helpers, called sub-agents, put their email into requests to government sites anyway. One issue from October 24 counts 9 such requests to sec.gov. A second from October 29 counts 15 across four projects. The likely reason, per the first report: the SEC asks automated visitors for a contact address. Neither issue has an answer from Anthropic yet.

Version 2.1.317 turns the instruction into a gate. But an issue opened November 4 reports how the gate decides. It flags any shell command that holds the account email plus a word like curl or https, even when the command only writes a note to a local file. A request to 127.0.0.1, the machine talking to itself, gets blocked too. In a headless run (Claude Code started by a script, with no person at the keyboard), nobody can say yes. The step is denied, and the run still ends with "success" and exit code 0.

Commenters on that issue add worse cases. One says agents driven from a phone kept stopping to ask permission for harmless commands, even in interactive sessions. Another reports an overnight session that sat about 8.7 hours waiting for an approval no one saw, and a scheduled run that simply skipped the step.

Then Anthropic answered. On November 5, under a new issue from a user who blames the leak for a flood of scam email, a Claude Code maintainer named the check: a built-in add-on called cc-plugin-privacy, on by default. Half an hour later, its code went public. Its notes say it refuses a shell command only when the command holds the address and also sets a User-Agent, the name tag a program sends with each web request. It never pauses to ask. It calls itself "a courtesy, not a boundary": web-fetch tools aren't checked at all. A contributor who tested that code found it lets the local note, the loopback request and the Drive download through. So, by the bug reporter's own tests, the builds users ran on November 2 to 4 blocked more than the code Anthropic has now published.

Jon's agents are exactly this kind of job: Claude Code sessions that fire on a schedule with nobody watching. The fleet already reads each run's own written receipt instead of trusting a "succeeded" label, and its link checks send a generic browser name, not an email. Both habits matter more after this release.

How to use it

• Read permission_denials, not the exit code. Claude Code's headless docs say that with --output-format stream-json, each denial shows up as a permission_denied message and is listed in the final result.
• Keep the signed-in email out of scripts, notes and User-Agent strings that also hold a URL. Use a separate contact address for sites that demand one.
• To turn it off: /plugin disable, or "enabledPlugins": {"cc-plugin-privacy@builtin": false} in ~/.claude/settings.json. A project's own settings can't do it. The catch: the address can then go out in a User-Agent again. One user reports it only takes effect in sessions started after the change.

What nobody knows yet

Whether 2.1.319, now the default, ships the narrower check. The bug reporter says the 2.1.317 and 2.1.318 builds refused more than the published code, and a second user on 2.1.318 couldn't find the add-on in /plugins, where the maintainer said it would be. No one has said whether the extra blocks came from this add-on or from another check beside it.

What to watch

Version 2.1.319 became the default download on November 6, and its release notes don't mention this check. If the local note and the loopback request run on it, the false alarms are fixed. The old advice still holds either way: read permission_denials, not the exit code.