# Claude Code v2.1.210

> Claude Code v2.1.210, released 14 Jul 2026 (2026-07-14). 15 entries read out of the shipped bundle. Unofficial, and not affiliated with Anthropic.

Web version: https://changelogs.core-directive.com/v/2.1.210

This is a large architectural release. The memory sync backend has been completely replaced — old personal and team sync is gone, replaced by an org memory discovery system that auto-provisions shared stores. A new `SendFile` tool lets Claude send files directly between Claude Code sessions. The `/auto-mode-setup` command gains a non-interactive wizard mode for scripted setup, and eval runs can now publish HTML reports. Several security and reliability improvements round out the release.

## New Features

### SendFile — Send Files Between Claude Code Sessions

**What**

A new `SendFile` tool lets Claude send one or more local files to another Claude Code session — a peer session on the same machine or a Remote Control / cloud session on a different machine.

**Details**

- Local sessions are addressed by name or by explicit `uds:<socket>` address. Cloud sessions use `bridge:<session-id>`.
- Files are verified with a SHA-256 digest after transfer, so the receiver can confirm integrity.
- Same-machine transfers travel over a Unix domain socket (no data leaves the host). Cross-machine transfers upload file contents through Anthropic servers; this path can be restricted with the `isolatePeerMachines` setting.
- An optional `message` parameter delivers a short note alongside the files.
- Agents within the same session are explicitly excluded — they already share the filesystem, so there is nothing to transfer.
- When `isolatePeerMachines` is enabled, cross-machine sends require explicit approval before anything is uploaded.
- To find available peer sessions, use the existing session-listing tool: `Use <ListSessions> to see the sessions you can send files to`.

**Evidence**

Tool definition with name `"SendFile"` (search for `"Send one or more files to another Claude Code session"`)

### Artifact Listing — Shared and All Scopes

**What**

The Artifact listing tool now accepts a `scope` parameter with three values: `mine` (the default, unchanged), `shared` (artifacts that other people shared with you), or `all` (both together).

**Details**

- `scope` only applies to the `list` action; publishing ignores it.
- Listing shared artifacts requires one-time consent per session — the first call that touches the shared scope shows a confirmation prompt because it reads titles and links from other users' sessions.
- A fresh consent prompt is shown only on the first `shared` or `all` listing per session; subsequent calls within the same session are silently permitted.

**Evidence**

New `Pje` scope resolver (search for `"scope: shared —"`) and new consent flow (search for `"First shared-scope artifact listing this session requires confirmation"`)

### `/auto-mode-setup` Wizard and Proposal Workflow

**What**

The `/auto-mode-setup` slash command gains a structured non-interactive mode via a `--wizard` flag and a two-phase propose/apply workflow.

**Usage**

`/auto-mode-setup --wizard posture=<personal|open-source|enterprise|mixed> scope=<all|project> depth=<both|shell|repos|here> --propose /auto-mode-setup --apply-file <absolute-path>` **Details** - `--wizard` sets up context without user questions. Posture values: `personal` (hobby/personal projects), `open-source` (public repos), `enterprise` (work/private repos), `mixed`. - `--propose` scans the repo and recent sessions, then asks the model to draft a settings proposal and writes it to a temp file. The proposal can be reviewed before applying. - `--apply-file <path>` reads a previously generated proposal file and writes it to user settings. The path must be inside the system temp directory or the Claude config directory. - The proposal now includes `removeFromPermissionsAllow` suggestions — broad or dangerous allow rules flagged during the scan can be removed as part of applying. - Scope `all` also reads sibling repos in the GitHub org via `gh`. Depth `shell` includes shell history; depth `repos` checks other checkouts in `~`. - The wizard mode feeds all parameters non-interactively so agents and CI scripts can drive setup without keyboard interaction. **Evidence** Wizard mode and proposal flow (search for `"--wizard posture=… scope=… depth=… --propose | --apply-file <path>"` and `"--apply-file needs a path to the reviewed proposal JSON"`)

### Eval Report Publishing

**What**

The `claude plugin eval` command can now export its results as a styled HTML report, optionally published as a private artifact on claude.ai.

**Usage**

`claude plugin eval --report results.html # write HTML to a local file claude plugin eval --publish-report # publish to claude.ai and print the link claude plugin eval --json results.json # existing flag, unchanged` **Details** - `--report <path>` writes a self-contained HTML file with per-case scores, prompts, grader verdicts, and summary statistics. - `--publish-report` uploads the HTML as a private artifact and prints the URL. Publishing is unavailable when claude.ai artifacts are turned off for the account or provider. - If the run is interrupted before all cases finish, the report is skipped rather than written with incomplete data. - `--max-cost-usd` ceiling is reported when it cuts the run short. **Evidence** New flag strings (search for `"--publish-report"` and `"Write a self-contained HTML report (scores, prompts, grader verdicts) to <path>"`)

## Improvements

### Memory Architecture: Org Memory Discovery Replaces Personal/Team Sync

**What**

The old personal and team memory sync backend — which replicated `.md`/`.txt` files against `/api/claude_code/memory` and `/api/claude_code/team_memory` — has been replaced by a new org memory system. Shared memory stores are now discovered automatically from the server; there is no more per-repo sync loop in the client.

**Details**

- Claude Code calls a new `/v1/code/local/memory/mounts` endpoint to discover which org memory stores are available for the current account.
- Discovered stores are cached locally in `org-memory-discovery.json` (under the cache directory) and refreshed once per hour.
- Credential provisioning uses a new `/v1/code/local/memory/credential` endpoint, with a configurable token lifetime.
- The feature is controlled by the `tengu_haze_glass` feature flag (off by default during rollout) and can be disabled with `CLAUDE_CODE_DISABLE_ORG_MEMORY=1`.
- Directory listing now uses a streaming NDJSON protocol (`exportMetadata`) when the backend supports it, falling back to paged listing on older backends. The stream path can be disabled with `CLAUDE_CODE_DISABLE_MEMORY_STREAM_LIST=1` or the `tengu_memory_stream_list` flag.
- Mount directories that already contain unmanaged content before the store is mounted are suppressed with a warning rather than overwriting user files: `"mount dir exists without a .memory-sync manifest and is not empty — suppressing sync"`.
- The environment variable `CLAUDE_CODE_DISABLE_ORG_MEMORY` is new. `CLAUDE_MEMORY_STORES` still overrides store configuration.
- `ANTHROPIC_BEDROCK_MANTLE_API_KEY` (an old Bedrock-specific key type) has been removed.

**Evidence**

Discovery endpoint (search for `"/v1/code/local/memory/mounts"`), credential endpoint (search for `"/v1/code/local/memory/credential"`), feature flag (search for `"tengu_haze_glass"`)

- Flag `tengu_haze_glass`: Off in both readings (read for one account on one subscription tier against v2.1.210; this account: off, anonymous baseline: off, compiled default: on) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.
- Flag `tengu_memory_stream_list`: Not enough to say (read for one account on one subscription tier against v2.1.210; this account: no value returned, anonymous baseline: no value returned, compiled default: off) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.

### MCP Connector Approval Retry (CCR / `-32003`)

**What**

When an MCP connector returns a new `-32003 needs_approval` error code, Claude Code now surfaces a retroactive approval card instead of propagating the error. The user can approve or deny the call from within the normal permission flow.

**Details**

- Previously, `-32003` responses would surface as raw errors. Now they trigger a consent prompt with the connector name and a description of the required action.
- If the user approves, the call is automatically retried; if they deny, an informative `"Approval denied for <connector>"` error is returned to the model.
- Approval is surfaced as an `"approval card"` in the UI with the message `"This connector call requires your approval to proceed."`.
- The feature is controlled by `tengu_mcp_proxy_needs_approval_retry` (default enabled).
- If the approval was conditioned on edited arguments (which cannot safely be replayed), the tool raises a clear error: `"The approval for X was conditioned on edited arguments, which can't be applied on this retroactive card"`.

**Evidence**

Error code constant (search for `"-32003"`) and approval message (search for `"connector requires approval for this call"`)

- Flag `tengu_mcp_proxy_needs_approval_retry`: Not enough to say (read for one account on one subscription tier against v2.1.210; this account: no value returned, anonymous baseline: no value returned, compiled default: off) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.

### Stale Worktree Lock Auto-Cleanup

**What**

Claude Code now automatically detects and releases worktree locks that were left behind by processes that have since exited, rather than leaving them to block future operations.

**Details**

- On each sweep, the worktree registry is scanned for locks whose lock-reason string encodes a PID. Only reasons matching the pattern `^claude (?:agent|session) .{1,255} \(pid (\d{1,10})(?: start .{1,255})?\)$` (and no longer than 512 characters) are eligible; lock reasons that don't follow this format are skipped entirely.
- If `process.kill(pid, 0)` returns `ESRCH` (no such process), the lock is treated as stale and released. Any other result (process exists, or PID ≤ 1 / non-integer) is treated as live and left alone.
- The per-sweep cap is **50 releases**: once 50 stale locks have been released in one sweep, the remainder are logged and deferred to a later sweep with the message `"releaseStaleClaudeWorktreeLocks: per-sweep cap of 50 reached; remaining stale locks will be reconciled on later sweeps"`.
- Worktrees with no `.git` file at their path are also skipped, preventing cleanup of already-removed trees.
- The registry is re-read at release time (double-checked before each individual unlock) to prevent TOCTOU races where another process might have claimed the lock between the scan and the release.
- The current session's own worktree is always excluded from cleanup (matched by resolved real path).
- When at least one lock is released, a `tengu_worktree_stale_lock_released` telemetry event is emitted with `{ attempted: N }`, and a debug log reports the count: `"releaseStaleClaudeWorktreeLocks: attempted release of N stale liveness lock(s)"`.

**Evidence**

Cleanup function (search for `"releaseStaleClaudeWorktreeLocks: attempted release of"`) and PID check logic (search for `"stale liveness lock(s) in"`); cap constant (`$zc = 50`); lock-reason regex (`Mtt`)

### Subagent Output Instruction-Pattern Sanitization

**What**

Text returned by subagents is now scanned for directive-shaped patterns — XML control tags, `<function_calls>` fences, and similar constructs that could be mistaken for instructions — before being relayed to the host session. Suspicious patterns are neutralized and flagged.

**Details**

- Matched patterns have their `<` characters escaped to `<\`` so they render as inert text rather than live markup.
- A harness note is prepended to the output when reportable patterns are found: `"[harness: subagent output matched instruction-shaped pattern(s): ...]"`.
- Non-reportable patterns (silently neutralized) are not surfaced to the user but are still counted in telemetry.
- Findings are reported via `tengu_subagent_output_flagged` telemetry, keyed by pattern category.

**Evidence**

Sanitizer entry point (search for `"Control tags below are neutralized"`) and the harness note (search for `"[harness: subagent output matched instruction-shaped pattern(s):"`)

### Cowork Setup Expanded to Six Steps

**What**

The `Setup Cowork` skill prompt was expanded from four steps to six, adding "writing voice" and "wrap" as new configuration phases, and a checklist step before the first user-facing message.

**Details**

- Old order: role, plugin, try a skill, connectors.
- New order: role, plugins, connectors, try a skill, writing voice, wrap — plus a Step 0 checklist.
- "Writing voice" captures style preferences that persist across sessions. "Wrap" closes the setup with a summary and next-steps message.

**Evidence**

Updated Cowork prompt (search for `"Six steps — role, plugins, connectors, try a skill, writing voice, wrap"`)

### `CLAUDE_CODE_SYNC_SESSION_REFS` Environment Variable

**What**

A new environment variable `CLAUDE_CODE_SYNC_SESSION_REFS` enables session-reference syncing when set alongside a `CLAUDE_CODE_SESSION_ID` that passes validation.

**Details**

- Session-reference syncing is activated only when `CLAUDE_CODE_SYNC_SESSION_REFS` is truthy AND `CLAUDE_CODE_SESSION_ID` passes the format validator (`Kae(e) !== e` — the session ID must produce a different canonical form when normalized).
- When active, both skills sync and plugin sync bypass the regular account-based sync APIs (`oto()` / `nto()`) and instead fetch a pre-assigned manifest from `GET /worker/skill-manifest` on the `ccr-session` host. That host resolves to the CCR Remote session URL supplied via `--sdk-url`; if no `--sdk-url` is provided the request throws `"ccr-session host requires --sdk-url"`.
- The manifest response is a JSON object `{ skills: [...], plugins: [...] }` where each entry carries `{id, name, description, version, directory}`. Only entries with a non-empty `id` are used.
- A single manifest fetch is shared across both skills and plugins via a lazy singleton (`YKb()`), so only one HTTP round-trip is made per sync cycle; the request carries a 30-second timeout.
- If the manifest fetch fails (no auth, HTTP ≥ 300, 503 unavailable, or malformed body), sync silently returns `{success: false}` and emits `tengu_skills_sync_manifest_failed` or `tengu_plugins_sync_manifest_failed` telemetry rather than raising an error.
- The `jot()` helper — which gates whether skill invocation waits for skill materialization — returns `true` when either `CLAUDE_CODE_SYNC_SKILLS` is set OR session-refs mode is active, so skill-wait logic applies to session-ref sessions as well.
- `CLAUDE_CODE_SYNC_SESSION_REFS` is also forwarded to spawned worker processes by the CCR preload layer alongside `CLAUDE_CODE_SESSION_ID`, so child sessions inherit the same sync path.

**Evidence**

New constant check (search for `"CLAUDE_CODE_SYNC_SESSION_REFS"`); manifest fetch (search for `"/worker/skill-manifest"`); sync branch (search for `"sync_session_refs_skills"`)

### Daemon Service Launcher Self-Healing

**What**

When the background daemon service finds that its launcher binary has been deleted or replaced (as happens after a version upgrade), it regenerates the service file from current settings rather than crash-looping.

**Details**

- New logic distinguishes between three failure modes: the service file points at a binary that no longer exists, the launcher setting changed, and the daemon is running unwrapped (without the corporate launcher when required).
- The `"installed service starts through a launcher that was deleted or is no longer executable — regenerating the service file from the current settings"` message indicates self-healing was triggered.
- `claude daemon install` can be run manually to force a clean repair.

**Evidence**

Self-heal path (search for `"installed service starts through a launcher that was deleted or is no longer executable — regenerating the service file from the current settings"`)

### PreToolUse Hook Timeout Message Improved

**What**

When a PreToolUse hook times out before the host client responds, the error message now explicitly states that the tool call was not executed and that other hooks may not have run.

**Details**

- Old behavior: the hook timeout error was surfaced as a generic error with less context.
- New message: `"PreToolUse hook did not respond before its timeout (host client may be unreachable). The tool call was not executed; other configured hooks may not have completed."`

**Evidence**

New message constant (search for `"PreToolUse hook did not respond before its timeout"`)

### `/doctor` Command Description Expanded

**What**

The `/doctor` command description was updated to enumerate its capabilities: install health diagnostics, unused extension detection, memory file trimming, and slow hook identification.

**Details**

- New description: `"/doctor is a full setup checkup — it diagnoses install health, finds unused extensions that cost context at startup, trims bloated memory files, flags slow hooks, and can fix what it finds with your confirmation"`

**Evidence**

Updated description string (search for `"it diagnoses install health, finds unused extensions"`)

## Bug Fixes

- Background daemon no longer exits on ECONNRESET errors originating from the HTTP server's internal connection handling. The error is now swallowed with a debug log rather than causing a crash (search for `"Swallowed unhandled http.Server ECONNRESET rejection"`)

- MCP telemetry for claude-in-chrome and computer-use tools no longer logs tool names outside the known action set, preventing false positives in usage metrics (search for the updated `Cee` function which checks `R3n(r.serverName)`)

- Worktree branch deletion error messages now consistently include a configurable label rather than a hard-coded prefix, making them easier to attribute in logs (search for `"Could not delete worktree branch"` vs. the old hard-coded `"Could not delete worktree branch:"`)

- Auto-mode `autoMode.environment` validation now rejects entries that contain the `"$defaults"` template token, preventing placeholder tokens from being written verbatim into settings (search for `"contains an entry with a literal \"<settings_\" template token"`)

## Notes

The memory sync architecture change removes the following:

- The `ANTHROPIC_BEDROCK_MANTLE_API_KEY` environment variable is no longer recognised.
- The old `/api/claude_code/memory` and `/api/claude_code/team_memory` endpoints are no longer contacted by the client. If your infrastructure blocks outbound access to the new `/v1/code/local/memory/mounts` and `/v1/code/local/memory/credential` endpoints, org memory will not function. The `CLAUDE_CODE_DISABLE_ORG_MEMORY=1` environment variable can disable the feature entirely.
- The `tengu_herring_clock` feature flag (which gated the old personal memory sync) has been removed along with the sync implementation it guarded.

- Flag `tengu_herring_clock`: Off in both readings (read for one account on one subscription tier against v2.1.210; this account: off, anonymous baseline: off, compiled default: not a boolean we can read) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.