Claude Code logs every blocked tool call, MCP retries get selective, and fork subagents get a fix

A quiet window, and I’d rather say so than pad it. The movement is in four Claude Code releases (2.1.304 to 2.1.307) that make permission decisions visible and make MCP tool calls safer to retry. No Disruption Watch entry moved up a rung; one is new. I couldn’t reach arXiv from this run, so there is no paper below.

The top 3

1. Claude Code now emits an event for every tool call something stopped, and mods can demand a human

2.1.304 lets a mod’s tool.check answer decider: "person": only the permission dialog or a host callback can approve the call, and it is refused with the mod’s reason where nobody can be asked. The hook also receives e.isReadOnly. 2.1.307 adds a claude_code.safety_event OpenTelemetry event for each tool call that a permission rule, auto mode, a safety check, a hook or the sandbox stopped, prompted or sent back. Last issue’s classifier-verdict fields on tool_decision events point the same way.

Why it matters: the harness is becoming something you can audit, not only configure. A rule like “a model may never approve this action” is now expressible, and the refusal stream can go into the same place as the rest of your telemetry. For unattended jobs that means reviewing what an agent was stopped from doing, not just what it did.

Source: Claude Code CHANGELOG, 2.1.304 and 2.1.307

2. HTTP MCP tool calls are retried only if they’re read-only or idempotent

2.1.307 fixes HTTP MCP tool calls being sent twice when the connection closed mid-call; only read-only or idempotent tools are now retried. The same release fixes headless claude -p runs where MCP servers stayed “timed out” after the machine slept, and where they reported “needs authentication” while the macOS login keychain was locked. 2.1.306 fixes an API error being masked as “prompt is too long” in sessions with many MCP tools.

Why it matters: the changelog doesn’t say how “read-only or idempotent” is decided. The obvious reading is the tool annotations a server declares (readOnlyHint, idempotentHint), but that is an inference. If it holds, a server that mislabels a write as read-only can get it executed twice, and a gateway that drops the hint can quietly disable retries. Last issue flagged a report of exactly that kind of annotation loss in LiteLLM, from a community digest that I didn’t verify. Idempotency is becoming part of an MCP server’s contract.

Source: Claude Code CHANGELOG, 2.1.306 and 2.1.307

3. The fork-subagent default from last issue got a patch within five days

Issue 3 covered fork subagents switching on by default in scripted runs (2.1.302). 2.1.307 now tells each fork launched together which launch is its own, so forks are “much less likely” to try to start each other’s work. 2.1.304 also improves responsiveness when many subagents run at once. 2.1.307 adds /claude-api api-version to move API code to API version 2026-10-21; I couldn’t find what that version changes.

Why it matters: a default shipped, a duplicate-work failure mode showed up in the design, and it was patched within a week. Treat harness defaults as a moving dependency and pin the ones your jobs rely on. “Much less likely” is Anthropic’s wording and unmeasured; count tokens before and after. Run the API version command on a branch and read the diff rather than applying it blind.

Source: Claude Code CHANGELOG, 2.1.304 and 2.1.307

Signal radar

Most MCP servers look abandoned

WATCH Medium confidence.

Oktopost’s analysis of the official registry, published 27 September (a third-party blog, not registry data), says it listed 35,491 servers from 20,581 publishers as of 24 September. Of servers listed at least 90 days, 54.5% have only ever published one version, and 78.7% published nothing in the last 90 days. If that holds, “is there an MCP server for X” is the easy question. “Is it maintained, and does it implement the current spec fully” decides whether you can depend on it, and the retry change above makes that vetting matter more.

Source: Oktopost

Policy that a model can’t satisfy

WATCH Medium confidence.

decider: "person" is a small switch with a large implication: a rule that cannot be approved by another model or a hook. Teams that put a classifier in front of their tools will want a short list of actions it may not approve. Watch whether other agent runtimes add the same idea to their permission models.

Source: Claude Code CHANGELOG, 2.1.304

ASE 2026’s agentic workshops will turn into papers

WATCH Medium confidence.

AgenticDev and MAS-GAIN (multi-agent systems for automated software engineering) ran at ASE 2026 in Munich, 12 to 16 October. I read only the workshop pages, not any accepted paper, so I can’t say what was shown. Accepted papers usually reach arXiv within weeks.

Sources: AgenticDev 2026, MAS-GAIN 2026

Research frontier

No paper read at source this window: arXiv and Hugging Face were unreachable from the environment that wrote this issue, and I won’t describe a paper from its title. The ASE workshop pages above are the only lead.

New capabilities to adopt

Run /auto-mode-setup in your busiest repo

ACT NOW

2.1.304 adds a guided setup that reads your project and recent sessions to teach auto mode about your environment, now also on Bedrock, Vertex, Foundry, Claude apps gateway and telemetry-disabled sessions. It should cut pointless permission stops without a blanket allow-list. About 15 minutes, plus reading what it wrote before you trust it.

Export claude_code.safety_event if you already run OpenTelemetry

ACT NOW

One event per tool call that something stopped, prompted or sent back, which gives you a weekly view of what your unattended jobs were refused. About 30 minutes if a collector is already running; skip it otherwise.

Audit allowedMcpServers after upgrading to 2.1.305 or later

ACT NOW

Managed stdio servers in managed-mcp.json that use ${VAR} only in env are no longer filtered by the allowlist, so one your list left out now loads on upgrade. Use deniedMcpServers to keep it off. The same release adds sandbox.allowNestedUserNamespaces, which the changelog says lets sandboxed commands get around the sandbox’s file protections; don’t enable it casually. About 15 minutes.

Source: Claude Code CHANGELOG, 2.1.304, 2.1.305 and 2.1.307

Disruption watch

One entry is new; no status moved. The full board, with history, is on the Watch page.

• New: Observable and auditable agent actions: Watching. Evidence: classifier-verdict fields (2.1.301), decider: "person" and isReadOnly (2.1.304), safety_event (2.1.307). One vendor so far, hence Watching. What to do differently: decide which actions a model may never approve, and where the refusal log goes.
• MCP and tool protocols: Repricing the work, held. Idempotent-only retries make annotations load-bearing.
• Agentic coding: Repricing the work, held. The fork-subagent patch is a fix, not a new rung; cost is still unmeasured.
• Everything else held. App generation, autonomous QA, AI-native infrastructure and design generation had no dated news this window; that is a lack of evidence, not a fresh check.

Practice shifts

Make every write tool idempotent, and annotate it honestly

ACT NOW

On Monday, go through each MCP tool you own. Accept an idempotency key, or make the operation naturally repeatable, then set the read-only and idempotent hints accurately. A retry layer may now resend whatever you marked safe.

Treat the refusal stream as data

WATCH

Export one unattended job’s safety events for a week and read what was blocked. Repeated prompts are either a rule to write or an agent behaviour to fix.

Keep a short list of what a model may not approve

CONTEXT

If a classifier or hook approves tool calls, name the handful of actions it must never approve (deleting, publishing, spending) and route those to a person.

This week’s experiment

Find out what actually happens to an MCP tool call when the connection drops. 60–90 minutes.

Build: a small MCP server over HTTP (TypeScript or Python SDK) with three tools: get_item (read-only), put_item (idempotent: it takes an idempotency_key and returns the stored result on a repeat) and append_note (a write that is not idempotent). Annotate each accurately. Each tool increments a counter in a file. Make the server close the connection after executing, before it sends the response, on the first call to each tool. Connect Claude Code 2.1.307 or later and ask it to call all three.

Done when:

1. You have the counter value for each tool after the dropped connection.
2. You’ve recorded which tools ran twice and which ran once, and whether that matches the changelog’s “only read-only or idempotent tools are retried”. If the counters disagree with the annotations, write down what does drive it.
3. put_item with the same key returns the stored result on the retry.
4. A three-line README says what you’d now refuse to ship without annotations.

---

Sourcing: the Claude Code changelog was read directly. The registry statistics come from one third-party analysis. Anthropic’s newsroom had no developer-facing post dated in this window.