Version 2.1.210

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.

• 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.

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

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

• 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.

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

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

/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>

• --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.

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

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

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

• --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.

New flag strings (search for "--publish-report" and "Write a self-contained HTML report (scores, prompts, grader verdicts) to <path>")

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.

• 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.

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

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.

• 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".

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

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.

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

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)

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.

• 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.

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

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.

• 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.

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

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

• 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.

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

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.

• 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.

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

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.

• 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."

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

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

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

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

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

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.