Claude Code v2.1.265

What

• A new subsystem decides, per assistant turn, whether an API request should continue a previous server-side "thread" (previous_message_id) or start a new one. It tracks per-agent thread state, retries on thread-related errors (thread_not_found, thread_fingerprint_mismatch, thread_already_continued), and falls back to stateless mode when the server rejects thread continuation. This feature is gated and off by default.
• Three new telemetry events were added for it: one fired when deciding to create/continue a thread, one on the final outcome of the live request, and one ("echo audit") auditing divergence between sent and echoed conversation turns.
• The echo-audit piece compares the message content sent versus what the server echoed back, classifying differences such as reordered, turn_split, turn_dropped, added/dropped tool_use, tool_name_changed, or caller_dropped, and reports them via tengu_tether_echo_audit.

Why Threading requests server-side can reduce redundant context sent per turn, but only works if server and client stay in sync; the echo-audit and outcome telemetry let this be verified and the retry/fallback logic keeps conversations working even when the server rejects or loses a thread.

What

A new "advisor tool" mechanism has been added. It can send the model an attachment (attachment.type === "advisor_tool") telling it whether an advisor tool is or isn't currently available, with messages like "The advisor tool is no longer available" or "is available". A new "advisor_tool" category token was also added to several of the internal lists used for telemetry and context-injection categorization, alongside existing tokens like remote_session_change.

Why

The feature is controlled by a feature gate and is off by default, so it doesn't affect current sessions, but lays groundwork for Claude to be told when an advisor tool becomes available to it.

What

• A new consent model for the Artifact tool, called "five-class asks," is being built behind the CLAUDE_CODE_ARTIFACT_FIVE_CLASS_ASKS environment variable (off by default), which latches the behavior on or off for the life of the process and reports whether it was on via telemetry.
• When enabled, it changes how Claude asks for permission on artifact actions:
  • Pinning someone else's artifact to your own list is now auto-allowed instead of prompting.
  • Uploading, reading (list_assets/read_asset/list_files/read_file), commenting, and replying all go through a new classification system (pathAsk, readRule, flaggedSpelling, outsideAsk, hardLinked, plus an unknown/someone_else/from_type/cowritten split) and a new ruling flow, instead of always asking.
  • Uploads get an "already approved this session" fast path.
  • Reading someone else's shared artifact can be auto-allowed via a per-conversation "class consent" latch, with the message "Reading ... needs no approval"; wording also changed from "another person's artifact" to "someone else's artifact."
• When the experiment is off, the previous single-path deny/ask logic is used unchanged.

Why

This reduces how often Claude has to interrupt with a permission prompt for routine, low-risk artifact actions, like pinning or re-reading something already approved, while still asking for genuinely new or risky ones.

What

• The artifact database's write tool gained a str_replace operation for editing a string field in place by exact old-text/new-text match, instead of resending the whole document. It supports replace_all to replace every match, and reports clear errors when the match can't be made: edit_no_match, edit_ambiguous, edit_field_missing, edit_field_not_string.
• Writes can now use optimistic concurrency: passing if_version (ifVersion) rejects the write with a version_mismatch error if the document changed since it was last read, and write results can report the document's new version number.
• A new as_level parameter on read_db/write_db lets the caller simulate reading or writing as a lower access level (interact or admin), to check what a less-privileged user would be allowed to do, without actually lowering the caller's own access.
• str_replace is threaded through both the single-write and batch (write_db/batch) code paths, and is currently gated off by default behind a feature flag (requiring both the artifact database and a dedicated str-replace flag to be enabled).

Why

These changes let Claude make small, precise edits to artifact database records instead of rewriting entire documents, avoid clobbering concurrent changes via version checks, and preview permission outcomes for other access levels before acting.

What

• The background turn-state classifier gained a projectsRecap mode: when invoked with projectsRecap: true, it skips the normal preclassify/heuristic path, uses a distinct (server-overridable) system prompt, and asks the model to produce a recap "card" with a state of needs_reply, needs_approval, done, failed, or working, plus a "happened" summary. It retries once if the response JSON is invalid.
• The mid-turn/end-of-turn background-agent status classifier now passes a projectsRecap flag into the classification call that produces a task's working/idle/blocked detail text.
• A project's task/thread status can now use this richer "recap" object (headline, needs, needsYou, happened, reply) instead of the old flat detail/needs/output.result fields.
• Results and failures are logged via a projects_thread_recap telemetry event, with reasons like heuristic_engine, line_truncated, parse_failed, and side_query_failed.
• The whole feature is behind the tengu_projects_thread_recap flag and currently off.

Why This lays the groundwork for showing a more useful, model-written summary of what happened in a Projects background task, rather than a flat status line, though it isn't enabled yet.

What

• The SDK/CLI initialize request now accepts an optional workspaceTrust object ({accepted, directory}) so a host application (for example, Claude Desktop's Code tab over SSH/WSL) can attest that it already showed its own trust dialog for the working directory, instead of the CLI needing to show its own.
• A new handler validates that the directory is an absolute path, resolves to the same trust key as the session's working directory, and isn't a screened/untrusted network path, then records the directory as trusted the same way the interactive terminal dialog does, and re-applies project settings afterward. The outcome is reported via telemetry.
• The initialize response gains a workspace_trust_recorded boolean (marked internal) reporting whether the attestation was actually persisted as trust — it can be false for reasons like an obfuscated/untrusted path, a wrong key, a write failure, or a home-directory session-only trust.
• The same workspace_trust_recorded field is included in the system-init/hello JSON payload sent out, alongside existing fields like current_permission_mode and hooks_applied.

Why This lets a host that already handles its own trust UI (like Claude Desktop) skip showing a redundant trust prompt inside the CLI, while still letting the CLI confirm and record whether that trust was actually saved.

What

• Plugins can now register, run, list, and describe custom slash commands using new host operations command.register, command.run, command.list, and command.describe.
  • command.register adds a new slash command (name, description, argument hint, immediate flag), rejecting name collisions with other plugins, built-in commands, or MCP commands, and capping how many commands one plugin can register.
  • command.run lets a plugin queue a command invocation for the current session.
  • command.list lists available commands together with where each comes from (built-in, plugin, user, or MCP).
  • command.describe lets a hook dynamically override a command's description, argument hint, or hidden state.
  • A plugin command with no matching command.run hook now replies with an explanatory stub message instead of failing silently.
• Plugins can also open and close a new UI surface called a "pane": a persistent, titled window, using new ui.open/ui.close operations (with id, title, and focus options). Each plugin can have at most 8 panes open at once.
• Internally, the hooks event dispatch table was expanded to recognize ui.open, ui.close, command.run, and command.describe as valid events (and the old PreToolUse event was renamed classic.PreToolUse without changing its behavior).

Why

This gives plugins much deeper integration with Claude Code: they can add slash commands that behave like built-in ones, and they can show their own persistent UI panels instead of being limited to existing surfaces.

What

• A full retry-and-backoff engine for organization-managed policyHelpers (per-OS helper scripts or static settings payloads) was added, covering arming, execution, retrying, and telemetry, including remote (managed-settings-dialog) arming/consent flows and mid-session re-arming. Helper failures are classified as transient (non-zero exit, timeout, missing file, interpreter unavailable) and retried with bounded exponential backoff, or permanent (bad path, oversized, parse failure, invalid envelope, schema rejected) and not retried.
• policyHelpers can now be honored from remote managed settings, not just admin-controlled policy sources, for plain policy payloads; a helper or any payload touching something the managed-settings approval dialog lists still requires the settings to be verified and approved first that session. The singular policyHelper key itself is still never honored from remote.
• New validation messages explain that onFailure and retries are ignored when set on the singular policyHelper key, and are honored only on the per-OS policyHelpers.<os> entries; a missing helper combined with onFailure: refuse and no static fallback is now startup-fatal when delivered from an OS-admin policy source.
• A new warning fires when more than one managed-settings source defines helper configuration and managedSourcesBehavior is "merge", since only the highest-priority source's helper configuration actually takes effect.
• A warning (status-only, or startup-fatal via MDM/managed settings) now flags cases where onFailure: "require" has no usable default fallback, since a failing helper with no defaultSettings would otherwise silently produce nothing.
• When no per-OS entry matches and Claude Code falls back to a static default settings payload, it no longer logs an info message or fires a telemetry event about the fallback; this now happens silently.

Why

Together these changes make organization-managed policy helpers more robust and predictable: failures retry sensibly, misconfigurations are caught early instead of silently doing nothing, and administrators get clearer signals about which settings actually take effect when multiple sources conflict.

What

Two new methods are added alongside the existing project_info/project_read/project_search:

• project_memory_list lists a project's memory files (path, size in bytes, last-updated time, and whether the list was truncated), capped at a fixed number of entries with a truncation notice when there are more.
• project_memory_read reads a single memory file by path, returning its content (with a truncation notice if the server had to cut the file short).

Both methods have matching UI action descriptions ("List project memory", "Read project memory file") and are backed by a real tool that reads documents from the memory store.

Why

This gives Claude Code a way to browse and read a project's stored memory files directly, rather than only being able to access general project info, files, or search.

What

The Projects tool's context now includes a '## Project memory' block, listing files that have been remembered for the project across different chats, alongside its existing docs, files, and synced sources. Malformed memory entries are validated and dropped.

Memory contents are surfaced with a note to read them via project_memory_read/project_memory_list, and a new backend route fetches this data (a project's melange_memory) to feed project_memory_list. That route explicitly refuses to work when accessed through a certain bridge mode.

Why

This lets a project's Claude carry memory of things noted in previous chats forward into new ones, while treating memory content as data rather than as instructions to follow, the same way it already treats docs.

What

The engine that syncs your files and directories for cloud sessions now supports being remotely muted via an "emergency switch." It checks this switch both when sync starts and periodically afterward (via a recheck). When muted:

• Sync pauses uploads and pulls instead of continuing as normal.
• The user sees a warning message explaining that sync has been paused.
• The sync engine's status reporting now distinguishes "muted" as its own state, separate from being shut down or blocked by another writer.

Why

This gives an operator a way to pause file syncing for a session remotely (for example, in an emergency), while clearly communicating to the user why sync has stopped rather than leaving them wondering.

What

• Tools that declare classifierOnly() are now always evaluated by the auto mode classifier — saved always-allow rules and hook-based allows are ignored, and outside auto mode such tools are denied with a message naming the tool.
• These tools can now set onBlock: 'flag'. When the classifier would otherwise block the action, refuse to review it, or return no verdict, the action is now delivered (allowed) instead of denied, but annotated with a decisionReason noting it was "Flagged by the classifier, delivered with its warning: ...".
• A new guard denies the action with an explicit bug message if a classifier-only tool serializes to an empty classifier input, since the classifier would have nothing to judge.
• The core auto-mode permission pipeline now checks each tool's classifier-only config: if onBlock === "refuse" and a hook asked for a prompt (or the host re-asks on every allow), it denies with an explanation; if onBlock === "flag", it forces the new allow-with-flag outcome.

Why This lets certain sensitive tools stay strictly gated by the auto-mode classifier (never allowed by saved rules or hooks) while giving them a softer failure mode: instead of silently blocking an action the classifier is unsure about, Claude Code can deliver it with a visible warning explaining why it was flagged.

What

• claude import (and its /import slash command) now accepts cursor as a source, alongside the existing codex and gemini sources, across the command's argument list, usage text, argument hints, CLI validators, and config-review messaging.
• A new importer reads Cursor IDE configuration from ~/.cursor and .cursor/ (and .agents/skills) — including mcp.json, rules/*.mdc, skills/, commands/, hooks.json, and .cursorrules — and converts it into Claude Code MCP servers, skills, CLAUDE.md instructions, and slash commands. It includes safety checks (refusing symlinks, flagging values that look like credentials, refusing workspace-folder scoping, size caps, deduplication) and explicitly does not import Cursor hooks, .cursorignore, Cursor Memories, Custom Modes, or Team Rules.
• The CLAUDE.md import-fallback marker now recognizes cursor as a third source id alongside codex/gemini when merging or reconciling previously imported instructions.
• .cursor directories are now treated the same as .windsurfrules/.clinerules for worktree/context purposes (while .cursorrules was removed from that particular list), and a cursor boolean was added to import-related telemetry.

Why

This lets people who have been using Cursor bring their existing MCP servers, rules, skills, and commands into Claude Code with a single import command, instead of recreating them by hand.

What

• The /design slash command's dispatch logic was rewritten to resolve a mode via a new router into one of consent, types, canvas, or hub, each with its own description, menu text, argument hint, and file-loading behavior (canvas mode loads design canvas files). The command also gained subcommandsBareOnly and survivesBundledKillSwitch flags, and its policy gate is now skipped for the types and canvas modes.
• A new /slides command is added alongside /design, letting you create a Slides deck artifact from a brief the same way /design creates a Design artifact. Both commands instruct the model to look up the matching published Artifact type and create a new artifact from it.

Why

Routing /design into distinct modes lets it handle browsing types, working with canvas files, and consent separately instead of one undifferentiated command, and /slides extends the same brief-to-artifact workflow to slide decks.

What

A new hidden CLI flag, --attach-serve <session_id>, attaches a serve-only helper to an existing, bound cloud session (identified by an id like cse_...) instead of creating a new one. It's meant for sessions spawned by the desktop app and is not for interactive use.

The flag is rejected if combined with --cloud/--remote, and it requires the non-interactive stream-json serve mode.

Why

This lets the desktop app attach a lightweight headless client to a cloud session it already created, rather than spinning up a new session each time.

What

• Commands and skills can now define a getArgumentCompletions callback; the prompt input calls this while typing to generate custom suggestions for a command's arguments.
• Command/skill definitions gained a menuDescription field: a shorter description shown in menu/listing UI, separate from the full description.
• Command/skill definitions gained a policyGate field: a policy object with a .policy check that can hide or disable a command.
• Internally, policyGate is now set up as a lazy getter during registration (rather than a plain assigned property), and getArgumentCompletions is passed through registration alongside it.

Why These fields give command and skill authors more control over how their commands appear and behave in menus: a concise label for tight UI space, a way to restrict visibility based on policy, and live, tailored argument suggestions instead of generic ones.

What

• Workflow's validateInput/checkPermissions now handle a resumeFromRunId input: when the script path can't be resolved, they look up the stored run's journal via the run id, and reconstruct the script to run from it.
• If the resume lookup fails, the tool can now return a "refused" outcome instead of erroring out unclearly.
• The background-workflow notification text was updated to say to relaunch with Workflow({scriptPath, resumeFromRunId}) using the run id from the summary, instead of showing a literal resumeFromRunId value.

Why This lets you resume an in-progress or interrupted workflow run using just the run id reported earlier, without needing to track down or retype the original script path.

What

When switching to a model alias with a 1M-token context window (a [1m]-suffixed alias), Claude Code now checks for three specific problems before switching, each with its own clear error message telling you what to do instead:

• 1M context has been turned off via the CLAUDE_CODE_DISABLE_1M_CONTEXT environment variable.
• The target model doesn't support a 1M-token context window.
• The alias has no 1M variant for the current mode.

These checks run before the older Opus-1M-specific check that previously handled this.

Why

Previously these failures likely surfaced as a generic error; now each case is distinguished with its own message and telemetry reason, making it clear why a 1M-context switch didn't happen and what to try instead.

What

• db_read and db_write calls can now include an asLevel parameter (returned as as_level), letting a call ask to run as if at a different access level.
• Results now include as_level_confirmed (from the server's levelConfirmed field), reporting whether the server actually enforced the requested level; when unconfirmed, a caveat message is added.
• The batch-write fallback path also tracks this confirmation across a sequence of writes, and appends a warning to error messages when a requested level wasn't confirmed, noting the writes may have run at the caller's own level instead.
• The db_write validation schema was updated to accept the new as_level (max 16 characters) and as_level_confirmed fields.

Why This makes it clear when an artifact database operation requesting an elevated or different access level actually got that treatment from the server, instead of silently succeeding or failing under the wrong permissions.

What

A new self-contained unified-diff parser reads Index:/diff/---/+++/@@ headers and hunks into structured objects, validating that the added/removed line counts match what the hunk header claims.

The Code component gained a new format value, "diff", alongside the existing "source" format. When set, the text is validated and parsed through this new parser, and anything with a malformed @@ -a,b +c,d @@ header (missing, non-numeric, or out-of-bound numbers) is rejected with a specific error such as "no @@ hunk header found" or "header is not @@ -a,b +c,d @@ within N lines". A companion wrap prop accepts "wrap" or "truncate-end" to control how long diff lines are displayed.

Why

This lets diff/patch text be rendered as a properly parsed, validated diff view instead of plain text, catching malformed diffs before they're displayed.

What

A new "Pane" keybinding context has been added. It maps:

• Tab/Shift+Tab to move to the next/previous pane (abovePrompt:next/previous)
• Enter/Escape to press/leave a pane
• Arrow, page, home, and end keys to six new pane-scrolling actions: pane:scrollUp, pane:scrollDown, pane:pageUp, pane:pageDown, pane:top, and pane:bottom, shown in the UI as "scroll", "page up", "page down", "top", and "bottom"

Why

This gives keyboard users a consistent way to navigate and scroll within panes, and these keys can now be customized like other Claude Code keybindings.

What

• Remote/cloud sessions now track when a queued message is "held" (queued but not yet sent to the cloud session) and could still be withdrawn. RemoteSessionManager calls a new tellWithholdableHeld() method on release, gate resolution, withdrawal, and settlement, and fires an onWithholdableHeldChanged callback when that status changes; the UI tracks this as a cloudMessageHeld state.
• Users can now press Escape while idle to reclaim messages that were queued but not yet sent, via a new cancelHeldMessages capability, instead of triggering a full interrupt. This shows a notice and logs telemetry.
• Cancelling with an empty prompt while in remote mode now also cancels held remote messages, via the same cancelHeldMessages path.
• Taking back the very first prompt (the one given on the command line, which starts out withheld) now shows a distinct notice: "You took back your first message (the one given on the command line) — it wasn't sent to the cloud session."

Why

Previously a message queued for a remote/cloud session but not yet sent couldn't easily be pulled back. Now pressing Escape, or cancelling with an empty prompt, retracts it before it reaches the cloud session, with clear feedback about what happened.

What

• When Claude saves a large tool result to disk, the content is now capped to a byte budget (1GiB by default) using an encoding-aware truncator.
• The saved result records a new truncatedAtBytes field when truncation happened, plus a derived truncatedAtCap boolean alongside estimatedOriginalTokens/estimatedPersistedTokens.
• The message shown to you after a tool result is saved now distinguishes a full save from a truncated one, telling you only the first N bytes were saved when the cap kicked in.

Why Without a cap, an unusually large tool result could produce an oversized file on disk; the new byte cap keeps saved files bounded, and the accompanying message and tracking fields let you (and Claude) know when a saved copy is incomplete rather than assuming it's the full result.

What

The command input's autocomplete now supports a new "mid-command" suggestion type. Previously, autocomplete suggestions only appeared when you were at the very start of typing a command; now they can also appear and be completed partway through a command line you've already started typing.

Pressing Tab now checks for a mid-command completion first, before falling back to its other existing behavior.

Why

This lets you get autocomplete help while editing or extending a command you've already begun, instead of only when starting fresh.

What

The plugin marketplace UI now has a new "directory-search" view, distinct from the existing browse view ("discover-plugins"), the installed-plugins view, and others. Running /plugin directory or /plugin search now routes to this dedicated directory/search screen, which has its own title shown in the UI ("directory").

Why

This gives users a focused way to search for plugins directly, instead of only being able to browse the general marketplace listing.

What

The set of recognized official, first-party plugin/skill categories has grown to include many enterprise SaaS connector names: Asana, BigQuery, Confluence, Datadog, Google Drive, Grafana, HubSpot, Jira, Linear, Notion, PagerDuty, Redshift, Salesforce, Sentry, and Snowflake, plus three internal tags (claude-tag-data-viz, claude-tag-oncall, claude-tag-troubleshoot).

This list feeds the checks used to recognize official categories across trust and gating logic.

Why

Plugins and skills tagged with these categories can now be recognized as legitimate, first-party integrations, which matters for how they're trusted, surfaced, and gated in the marketplace.

What

The OTLP (OpenTelemetry protocol) resource-attribute builder used for telemetry now adds a user.groups attribute, a comma-joined list of the session's group names, alongside the existing enduser.id and user.email attributes.

The attribute is only added if none of the group names contain a comma or an equals sign, and if the URL-encoded joined string is 255 characters or less; otherwise it's left out.

Why

This lets telemetry and observability tooling see which groups a user belongs to, while avoiding malformed or oversized attribute values.

What

• New "enable" tools were added for device/browser tool families that are already connected: enable__mcp__remote-devices__computer, enable__mcp__claude-in-chrome, and enable__mcp__remote-devices__Claude_Browser.
• These tools do nothing by design — their descriptions and results tell Claude that the underlying mcp__ tools (such as mcp__remote-devices__computer_*) are already available and should be called directly, instead of trying to "enable" them first. They also include guidance on what to tell the user if the remote computer's Claude app isn't responding.
• They are only registered as available tools when a remote/device session is actually active (a session config resolves).

Why

Without these no-op stand-ins, Claude could try to call a nonexistent "enable" step before using already-connected device or browser tools; now it's told directly to just use the real tools.

What

• Sources for the artifact publish tool's files parameter (and the root it's relative to) can now live in the session's scratchpad directory, not only the current working directory — the tool's parameter descriptions were updated to say so explicitly.
• The underlying trust check for the root parameter was reworked: instead of a manual string-prefix comparison against the working directory, it now calls a new helper pair to validate the path, and file-processing calls (both the general file-copy path and thumbnail generation) pass an extra options object from a new helper function.

Why

This lets Claude publish artifacts built from files it created in its scratchpad, not just files in the project's working directory, while keeping the same path-trust safety checks, now reworked to also cover the scratchpad case.