Claude Code's New Privacy Lock Can Freeze Your Agent All Night, Then Call It a 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.

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.
• The opt-out users report is "enabledPlugins": {"cc-plugin-privacy@builtin": false} in ~/.claude/settings.json. The catch: it also lets through calls that really do send the email. It only takes effect in sessions started after the change.

What nobody knows yet

The trigger rules, the "success" exit and the 8.7-hour stall all come from users. Anthropic hasn't replied on any of the three issues. Its docs don't name the plugin behind the check, cc-plugin-privacy, at all.

What to watch

The next Claude Code releases, which usually land every day or two. The fix to look for: the check skips calls that can't leave the machine, or a blocked step ends a headless run as an error.