Daily signal: Claude Code 2.1.314 closes policy and sandbox gaps in resumed sessions and Monitor commands, MCP's extension lifecycle is merged, and Codex 0.166.0 adds secret substitution at the proxy

Executive summary

The level stays elevated, carried by the security brief. The ecosystem news is a day of control repairs in the coding agents themselves. What changes risk is where the repairs are: policy that did not apply when its source was unreachable, a sandbox that did not apply in a resumed session, and hooks that did not run on one class of commands. Each is a case where the control was configured correctly and the situation sat outside the path it covered, which is the property an auditor asks about and a configuration review cannot see. In the protocol process, the extension lifecycle text is now merged, so the open question about how a Stable extension gets a security fix has its answer on paper.

Claude Code 2.1.314: controls that did not apply at the edges

Official30 OctUpdate · 23 to 30 Oct

What happened. The 2.1.314 release notes list: forceRemoteSettingsRefresh set only in remote managed settings no longer stops applying once the stored copy expires (“previously, sessions could start without policy when the server was unreachable”); sandbox protections did not apply to a worktree entered through claude -p --resume or --continue; hooks matching Bash did not run on shell commands started by the Monitor tool (they now do, with the limit that they can block or ask but not approve or rewrite those commands); a settings file excluded with --setting-sources still supplied some settings, such as auto-mode rules and saved permission consents; and calls blocked by auto mode, a deny rule or a PreToolUse hook no longer appear as if they ran. New controls: permissions.blockWritesOutsideWorkingDirectories, and in CI claude ultrareview and claude remote-control refuse an untrusted folder immediately.

Analysis. Take the managed-settings fix first, because it is the one with a fail-open shape: an organisation that enforces forceRemoteSettingsRefresh expects the session to refuse to start without fresh policy, and the bug let it start without once the cached copy aged out and the policy server could not be reached. The precondition is an unreachable policy endpoint, which an attacker on the network path, or a laptop on a bad connection, can produce. The sandbox gap in resumed worktrees and the hook gap on Monitor commands are of the same family as the 23 Oct fix, where PreToolUse hooks on Windows could let a call through when Git Bash was missing: the control exists, and a particular entry path bypasses it. The exposure for each is the agent’s own actions after a prompt injection in a repository or tool result; none was reported as exploited. Compared with the 22 Oct set (shell startup files outside the sandbox, denyWrite globs through symlinks), the pattern is stable: each release closes a few edge paths, which is evidence the review is working and also evidence the edges are many. Mapping: OWASP LLM06 (excessive agency) and the Agentic Top 10 category on tool misuse and privilege.

Why it matters. Teams that rely on managed settings, hooks and the sandbox for policy have to treat them as layers that can each miss a path, not as guarantees. The opt-in blockWritesOutsideWorkingDirectories closes one of the most useful gaps (writes to dotfiles, shell profiles and other repositories) but is not on by default.

Mitigation and detection. Update to 2.1.314. Turn on permissions.blockWritesOutsideWorkingDirectories and permissions.blockReadsOutsideWorkingDirectories in managed settings. Test the policy-unreachable case on a managed laptop: block the settings endpoint and confirm the session refuses or restricts. For resumed sessions and Monitor commands, check that your hook logs record the commands you expect. Keep the 27 Oct change in mind when you rely on telemetry: Claude Code stopped sending the claude_code.safety_event OpenTelemetry event in 2.1.312.

Recommendation (opinion): update this week and add the three controls to your baseline. The managed-settings behaviour in particular should be a documented test in your endpoint checklist, not an assumption.

Sources: Claude Code releases

MCP: SEP-3392 is merged, and two proposals wait

OfficialUpdate · 29 Oct

What happened. SEP-3392 (Extension Lifecycle) was merged on 29 Oct by pja-ant as commit 84d8457. It had been marked final on 27 Oct and approved by dsp-ant. The merged page shows a late change that moves the stage into the directory path, so promotion from one stage to another no longer renames a repository, and the final commit message says that as a Process SEP it has no conformance requirement. The summary text is unchanged: “A Stable extension changes only with a new core protocol revision.” I could not read the merged SEP document itself, so I do not know whether it gives a separate path for security fixes; the page did not mention one.

Analysis. Yesterday’s signal flagged that, with two core releases a year, a flaw in a Stable extension’s semantics has no faster route than the next revision. The merge does not change that reading, and “no conformance requirement” means that nothing in the test suite checks the lifecycle. For a defender the practical effect is that Stable extensions are the ones to enable by default only if you accept that a semantic security flaw would wait months, and that your compensating controls (gateway policy, client-side allow-lists) are the real patch path.

Two other proposals moved. SEP-2624 (Interceptors) adds validators and mutators at lifecycle points such as tools/call, with interceptors/list and interceptor/invoke, and was updated on 29 Oct; later commits let the invoker set failOpen, priorityHint, mode and timeoutMs per chain entry and say hook narrowing may only narrow. A review comment from June argues that per-call checks miss risky sequences, such as retrieve, propose and then approve a memory write, which is the design question for a governance layer. If an interceptor can be configured to fail open, the guardrail is only as strong as that setting’s default and who may change it. PR 3306 (identity-provider support for enterprise-managed authorization) lists which providers issue and accept the ID-JAG token; a maintainer asked on 29 Oct whether to continue or close it, and the bot reports a code-owner review is blocking it. Neither is a security change yet.

Why it matters. Enterprise-managed authorization is the route by which a company, rather than each user clicking through, decides which agents get tokens for which servers. A support matrix that is stuck in review leaves buyers without a public statement of which vendors ship it.

Mitigation and detection. Treat Stable status as maturity, not as a security guarantee. If you plan to build on interceptors, require failOpen to default to false and make overrides administrator-only.

Recommendation (opinion): watch. Read SEP-2624’s failure semantics before any vendor sells you “MCP interceptors” as a guardrail.

Sources: SEP-3392 · SEP-2624 · PR 3306 · Yesterday’s signal

Releases read for security

Codex 0.166.0 (29 Oct)

Official29 Oct

What happened. The release notes list, among others: acknowledged permissions preserved when resuming and forking threads (#57227); glob search that fails closed when it cannot read search-root metadata (#57186); permission request preparation and approval actions centralised (#57260); the working directory reported to PreToolUse hooks (#57198); a constraint-aware standalone network proxy and network_proxy in managed requirements (#57180, #57286); scoped request-body secret substitution in MITM hooks (#57174); masked AWS credentials for local proxy signing (#56554); OTEL exporter headers redacted in app-server config responses (#57654); and opt-in protocol discovery for local stdio MCP servers, with eligible local stdio connections shared across chats (#57210, #57211).

Analysis. Two entries change the trust model. Secret substitution at a proxy means the model and the agent process see a placeholder while the real credential is added to outgoing traffic, which is the right direction for keeping secrets out of context; it also makes the proxy a high-value component whose scope rules decide whether a hostile destination can receive a real secret, so the word “scoped” carries the security claim and I cannot assess it from release notes. Sharing local stdio MCP connections across chats trades isolation for speed: state and tool results from one conversation could be reachable by another if a server keeps session state. “Preserve acknowledged permissions on resume and fork” is a convenience that depends on the permission being bound to the right context. This is a read of release notes only; I have not tested any of it and the alpha builds have no notes.

Mitigation and detection. Update to 0.166.0, then review the proxy scope configuration for any secret-substitution rule and test that a request to an unlisted host does not receive the secret. Do not enable shared local stdio connections for MCP servers that hold per-conversation state until you have checked how they key it.

Sources: Codex 0.166.0 release

Models, platforms and protocols: nothing else moved

No new model or system card that I could verify, no A2A release, and no new MCP specification revision. Google’s MCP Toolbox for Databases released v1.15.0 on 23 Oct, which sanitises server filesystem paths in read errors; its earlier releases extended the SSRF guard to the CGNAT and IETF-assigned ranges. I note it because the Toolbox has a critical path-traversal advisory (CVE-2026-93328) whose fixed version I could not confirm; see the security brief.