What happened
Anthropic merged pull request #107768 into the anthropics/claude-code repository on November 6, 2026. The change publishes the source for Claude Code’s built-in privacy mod in mods/privacy, including its hooks module, manifest, and README. It also adds an entry to mods/README.md and declares $.session.identity in mods/types/claude-code.d.ts, the session identity value that the mod reads. The pull request’s contributor summary says explicitly that this is a source publication, with no new behavior. Its test plan reports that tsc -p mods/tsconfig.json passes using TypeScript 5.9.3; the mod has no tests/ directory, so the workflow typechecks it but runs no mod-specific tests.
The underlying protection refuses a shell call when it contains both the signed-in account’s email address and a User-Agent naming pattern. The published README describes this as a narrow check, not a general network-control system. The condition is significant because both terms must be present in the shell call described by the source; the material does not describe it as a generic scan of all sensitive data or all network traffic. Its disclosure of accepted false refusals matters operationally: teams may encounter blocked shell calls that are not necessarily evidence of malicious behavior, but a consequence of the rule’s matching logic.
The README also records ways the mod can be turned off: /plugin disable, setting enabledPlugins to false, a server-side switch, or overriding plugin hooks. These are not merely theoretical implementation details for an audit: they define configuration states in which the built-in rule may no longer provide the same protection. The effective state therefore depends on configuration and the surrounding harness, not merely on the presence of the source in the repository. A team auditing its setup should check which controls are active in its actual deployment and whether local plugin configuration or hook overrides alter the expected behavior.
The documented coverage excludes WebFetch, WebSearch, and MCP. The pull request therefore exposes a specific shell-call safeguard and its limits; it does not claim to prevent every route by which data could leave a session. That boundary also separates source availability from a complete security assessment: publishing the hook lets a reviewer inspect this control, while the stated exclusions identify paths that require separate consideration. The release context in the supplied material is that Claude Code 2.1.317, published November 3, listed the original ask-before-send network email check, followed by version 2.1.318 on November 4. The November 6 merge makes the mod’s implementation and stated boundaries available for inspection.
What the archive adds
The archive has covered other Anthropic safeguards, including Claude Duet’s safety, privacy, and security safeguards, but that is a separate product and event. A prior note also records a separate Claude Code prompt rule about recreating existing games; shared product terms do not make it the same story. This is a new fact about Claude Code’s privacy guard, not a restatement of those earlier events.
Trend signal
This is a modest example of the runtime-boundary problem: a protection’s value depends on what it can inspect, where it applies, and how it can be disabled. The story supports agent security moves to runtime boundaries, while also showing that publishing source alone does not establish complete runtime coverage.
Why now
The source publication follows the Claude Code release context in the supplied material: version 2.1.317 listed the original ask-before-send network email check, and version 2.1.318 followed the next day. The November 6 merge gives teams a way to inspect the implementation after those releases, without announcing a new behavior or expanded protection.
Why it matters
Teams often evaluate coding agents by their visible permissions or by a headline description of a safety feature. This source release makes a more useful review possible: inspect the exact matching condition, identify accepted false refusals, confirm whether disable paths are available in the deployment, and compare the documented coverage with the tools agents actually use.
The exclusions are particularly important for threat modeling. A shell-call filter that does not cover WebFetch, WebSearch, or MCP should not be treated as a universal outbound-data barrier. Teams can use the source to decide whether the built-in check is sufficient for a low-risk workflow or whether they need additional hooks, network controls, or a different harness. They should also distinguish a typechecked implementation from evidence that the guard behaves correctly across their own commands, plugins, and tool routes. The practical gain is auditability, not a stronger guarantee.
Limits and uncertainty
The pull request establishes that source files were added and merged, and its summary says runtime behavior did not change. The supplied material does not establish how often the check triggers, how frequently false refusals occur, or how effective it is against deliberate exfiltration. It also does not quantify adoption of the mod or provide a security evaluation. The TypeScript typecheck is not a behavioral test, and the absence of a mod-specific test directory leaves runtime cases unverified in the described workflow. The README’s stated exclusions should be read as scope documentation, not proof that every unlisted route is covered.
Reader takeaway
Claude Code’s privacy mod is now inspectable, but it remains a narrow shell-call check. Audit its matching rule and disable paths in your own configuration, and do not infer that WebFetch, WebSearch, MCP, or every other data route is covered by it.