Claude Code v2.1.210 / Changelog

Pick an entry · j / k steps through

4 entries

New Featuresopen

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")

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

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")

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.

v2.1.229 Listing artifacts no longer asks for permission

`/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")

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

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>")

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

9 entries

Improvementsopen

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

Feature flag

tengu_haze_glass Off in both readings

The flag server returned off for the account this site reads and for the anonymous baseline. A reading of off cannot rule out a rollout these two readings sit outside of.

This account: off · anonymous baseline: off · compiled default in v2.1.210: 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.

tengu_memory_stream_list Not enough to say

Nothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.

This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.210: 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.

Read once, for one account on one subscription tier, against v2.1.210. It isn't a statement about your account. What a flag value here can and cannot tell you

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")

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

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

Feature flag

tengu_mcp_proxy_needs_approval_retry Not enough to say

Nothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.

This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.210: 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.

Read once, for one account on one subscription tier, against v2.1.210. It isn't a statement about your account. What a flag value here can and cannot tell you

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")

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

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)

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

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):")

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

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")

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

`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")

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

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")

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

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")

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

`/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")

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.

v2.1.206 Health Check Description Update

1 entry

Bug Fixesopen

#

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")

1 entry

Notesopen

#

Feature flag

tengu_herring_clock Off in both readings

The flag server returned off for the account this site reads and for the anonymous baseline. A reading of off cannot rule out a rollout these two readings sit outside of.

This account: off · anonymous baseline: off · compiled default in v2.1.210: 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.

Read once, for one account on one subscription tier, against v2.1.210. It isn't a statement about your account. What a flag value here can and cannot tell you

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.

Claude Code v2.1.210

New Featuresopen

SendFile — Send Files Between Claude Code Sessions #

Artifact Listing — Shared and All Scopes #

Related

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

Eval Report Publishing #

Improvementsopen

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

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

Stale Worktree Lock Auto-Cleanup #

Subagent Output Instruction-Pattern Sanitization #

Cowork Setup Expanded to Six Steps #

`CLAUDE_CODE_SYNC_SESSION_REFS` Environment Variable #

Daemon Service Launcher Self-Healing #

PreToolUse Hook Timeout Message Improved #

`/doctor` Command Description Expanded #

Related

Bug Fixesopen

#

Notesopen

#

Anthropic’s official release notes