# Claude Code v2.1.273 > Claude Code v2.1.273, released 15 Sep 2026 (2026-09-15). 278 entries read out of the shipped bundle. Unofficial, and not affiliated with Anthropic. Web version: https://changelogs.core-directive.com/v/2.1.273 This build carries 15 gated additions, none of them reachable yet. A new OAuth scope, user:plugins, is requested only when PLUGINS_SCOPE_REGISTERED is set, and remote teleport sessions can seed their workspace from a git bundle once an unresolved flag opens up. Remote-control clients gain a wired-in fork_conversation call for branching a running session, and headless startup now has a gated "headless hearth mount" bridging in webagent MCP tools. A stricter "strict" lane for parked-permission answers exists in the code but is never selected, and a gated cleanup step (tengu_silly_waterfall) is ready to prune duplicate stray transcript messages once switched on. Of 101 shipped entries, tool presets can now exclude specific tools with a "!ToolName" syntax, and two new sandbox settings, isolation.required and isolation.persistHome, add VM-style isolation controls. The claude remote-control command and spawned sessions both gain --chrome / --no-chrome flags for controlling Claude in Chrome. Artifacts pick up two new file-based types, "slides" and "design", alongside the existing "design-system" type, and the parked-permission timeout is now a configurable value instead of a hardcoded constant. The session inbox can now render inbound messages relayed from Slack directly in the UI. Among 37 fixes, Claude Code now recovers gracefully when a safety classifier cuts off a response mid-tool-call, and the model catalog's "flag rows" feature is removed in favor of a new servedCatalogOffBeforeAsking field. The MCP server's webhook route now returns a proper 405 for the wrong HTTP method instead of a misleading 404, and session usage totals now take the higher of two token counts while task token accounting skips advisor and compaction iterations. On macOS, the Read tool now checks a file's actual disk identity against files already held open by a write, and publish requests are automatically retried once if the server never responds. ## What probably matters to you Anything you can use today, anything that visibly changes, and anything worth poking at. One line each, open for detail. ### New "strict" parked-permission answer lane defined but never selected A new stricter permission-answer matching path exists in the code but isn't yet used **What** Claude Code has a mechanism for "parking" a permission request (asking whether a tool can run) and later matching it up with the answer that comes back. A new, more conservative matching path called `routeStrictAnswer` has been added for this. It carefully re-checks the request ID, the specific tool call ID, the tool name, and that the tool call is still the most recent one before accepting an answer, rejecting mismatches for reasons like `not_the_park`, `decided`, `tool_name_mismatch`, or `not_queued`. This new path only runs when an internal setting is set to `"strict"`, and nothing in this change actually turns that setting on. **Why** This is groundwork for tighter, less error-prone matching of permission answers to the right tool call, guarding against stale or mismatched approvals slipping through. Since nothing currently selects the `"strict"` mode, it has no visible effect yet. - Area: Permissions - Tier: Nothing to try yet - Useful: 4/5 - Signal: 4/5 - Present in the build but not switched on ### Tool-preset exclusion syntax (`!ToolName`) gated by a new killswitch Tool presets can now exclude specific tools with a '!ToolName' syntax **Unclear.** The finding notes this exclusion parsing can be disabled by a killswitch flag, but whether it is active for this site's account is not established since the gate is unread. **What** When configuring a tool preset (a named list of tools), you can now exclude a specific tool by prefixing its name with `!`, for example `!Bash`, and it will be filtered out of the resolved tool set. **Why** This lets you build a tool preset by starting from a broader set and excluding specific tools you don't want, rather than having to list every tool you do want. - Flag `tengu_tools_exclusion_killswitch`: Not enough to say (read for one account on one subscription tier against v2.1.273; this account: no value returned, anonymous baseline: no value returned, 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. - Area: Tool Presets - Tier: Use it now - Useful: 4/5 - Signal: 3/5 ### New structured /usage response schema, explicitly marked experimental The /usage command gains a formally defined, still-experimental structured data schema **What** The data behind the `/usage` command (which shows session cost, plan usage limits, and activity stats) now has a formally defined structure covering: - session cost, duration, and lines-of-code totals - rate-limit rows, each with kind, group, percent used, reset time, scope, severity, and whether it's currently active, exactly as sent by the server - extra-usage (overage) spend details: whether it's enabled, the monthly limit, credits used, utilization, and currency This is explicitly marked as experimental, meaning the shape may still change. **Why** A well-defined structure for usage data makes it easier for tools built on top of Claude Code, such as the SDK, to reliably read cost and rate-limit information, though it isn't finalized yet. - Area: Usage - Names: `/usage` - Tier: Nothing to try yet - Useful: 4/5 - Signal: 3/5 - Present in the build but not switched on ### Remote-control conversation fork (fork_conversation) wired into the REPL bridge Remote clients can now fork a running Claude Code session mid-conversation **What** Claude Code's remote-control bridge (the connection that lets a remote client control a running session) now supports a `fork_conversation` request. A remote client can send this request with a target message and a title, and Claude Code will validate it and spawn a background fork (a branched copy) of the current conversation, letting the remote client branch off from a specific point in an active session. This is associated with a setting called `tengu_cozy_pixel`, but nothing has been read yet about how that setting is currently configured. **Why** This lets a remote client branch a conversation without having to end the current session first, which is useful for exploring an alternate path from partway through an ongoing conversation. - Flag `tengu_cozy_pixel`: Not enough to say (read for one account on one subscription tier against v2.1.273; this account: no value returned, anonymous baseline: no value returned, 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. - Area: Remote Control - Names: `fork_conversation` - Tier: Nothing to try yet - Useful: 4/5 - Signal: 3/5 - Present in the build but not switched on ### Inbox message rendering added (Slack-sourced messages) New UI shows inbound messages, including ones relayed from Slack, waiting in the session's inbox **What** Claude Code now has UI for rendering inbox messages that arrive in a session, including ones relayed from Slack. It shows: - who sent the message and how it's labelled (for example, 'via Slack') - a permalink and a received-at timestamp - a distinct state for when the message failed to load A notice appears in the transcript when a message from Slack or the API is waiting in the session's inbox, showing the sender's name, and in verbose or transcript mode, a preview of the raw message text. **Why** This points to a new way for messages from outside a Claude Code session, such as from Slack, to be routed in and surfaced to you directly in the transcript. - Area: Inbox - Tier: Use it now - Useful: 5/5 - Signal: 2/5 ### New "slides" artifact type (alongside design and design-system) Claude Code gains a new "slides" artifact type for building slide decks **What** Artifacts (files Claude Code can generate and manage as structured output, alongside the existing "design" and "design-system" types) now include a third type: "slides". Each slide is stored as its own HTML file at `project/slides/.html`, with a `project/deck.json` index file describing the order, sections, and fonts of the deck. **Why** This gives Claude Code a structured way to build and manage a slide presentation as an artifact, rather than as one large, unstructured file. - Area: Artifacts - Names: `slides` - Tier: Use it now - Useful: 5/5 - Signal: 2/5 ### New Artifact Types: 'slides' and 'design' with file-based storage Artifacts gain two new file-based types, 'slides' and 'design', alongside the existing 'design-system' type **What** Claude Code's artifact system (used for generating documents, code, and other structured outputs) now supports two new artifact types: - `slides` — a presentation deck, stored as an index file (`project/deck.json`) plus one HTML file per slide (`project/slides/.html`), following a defined outline/faces schema - `design` — a design canvas, stored as an index file (`project/canvas.json`) plus one file per artboard (`project/`) Both join the existing `design-system` artifact type. Rather than storing content as one big document the way older artifact types do, these two store their content as separate files on disk, marked internally with a `createdOnFiles` flag. **Why** This gives Claude Code structured, file-based formats for generating slide decks and design canvases, where each slide or artboard is its own file instead of being bundled into a single document. - Area: Artifacts - Names: `slides`, `design` - Tier: Use it now - Useful: 5/5 - Signal: 2/5 ### New gate for gateway hint headers on first-party surfaces A new internal check decides when Claude Code sends extra gateway hint headers on first-party requests **Unclear.** What the gateway hint headers are used for once sent is not stated. **What** Claude Code has a new internal helper that decides whether to attach gateway hint headers to outgoing requests. It turns them on automatically if the `CLAUDE_CODE_GATEWAY_HINT_HEADERS` environment variable is set, or under another internal condition, turns them off entirely outside of "first-party" surfaces, and otherwise follows a feature flag. **Why** This is an internal request-routing detail; it does not change anything a user needs to do. - Flag `tengu_splendid_sutton`: Not enough to say (read for one account on one subscription tier against v2.1.273; this account: no value returned, anonymous baseline: no value returned, 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. - Area: Internals - Names: `CLAUDE_CODE_GATEWAY_HINT_HEADERS` - Tier: Use it now - Useful: 3/5 - Signal: 3/5 ### New OAuth scope `user:plugins` gated by PLUGINS_SCOPE_REGISTERED A new OAuth scope, user:plugins, is requested for accounts with plugin access registered **What** When Claude Code logs in, it can now request an additional permission scope called `user:plugins` as part of OAuth (the login flow that grants Claude Code permission to act on your behalf). This scope is only added when a setting called `PLUGINS_SCOPE_REGISTERED` is turned on for the login configuration being used. The default and production login configurations now have this turned on, while configurations that use a custom client ID or an environment-variable override for the client ID do not. **Why** This lets most users' logins pick up permission for a plugins-related feature automatically, while custom or overridden login setups are left unaffected until they're updated too. - Area: Auth - Names: `user:plugins` - Tier: Nothing to try yet - Useful: 3/5 - Signal: 3/5 - Present in the build but not switched on ### New --chrome flag for spawned sessions New --chrome / --no-chrome flag lets spawned sessions control Claude in Chrome integration **What** The CLI help for spawning or reattaching to sessions now documents a `--[no-]chrome` flag, which controls whether `Claude in Chrome` (browser integration for web automation and testing) is enabled for that spawned session. By default it follows the machine's own `/chrome` setting. **Why** This lets a spawned or reattached session opt in or out of Claude in Chrome independently of the machine-wide `/chrome` configuration. - Area: Chrome - Names: `--chrome`, `--no-chrome` - Tier: Use it now - Useful: 4/5 - Signal: 2/5 ### New remote-control CLI flags --chrome / --no-chrome New --chrome and --no-chrome flags added to the claude remote-control command **What** The `claude remote-control` command now accepts two new flags, `--chrome` and `--no-chrome`, which enable or disable Chrome browser integration for that session. They sit alongside the existing `--sandbox`/`--no-sandbox` flags and `--enable-live-preview` handling. **Why** This gives users direct command-line control over whether a Remote Control session can use Chrome browser integration for web automation and testing. - Area: Chrome - Names: `--chrome`, `--no-chrome` - Tier: Use it now - Useful: 4/5 - Signal: 2/5 ### New sandbox isolation restrictions: isolation.required / isolation.persistHome Two new sandbox settings, isolation.required and isolation.persistHome, control VM-style isolation **What** Sandbox configuration (Claude Code's system for restricting what commands can access) gains two new settings: - `isolation.required` — marked as restrictive when turned on - `isolation.persistHome` — marked as not restrictive when turned off These come with a matching display surface for summarizing sandbox settings, and a new warning message specific to VM-based isolation. **Why** This adds finer control over sandbox isolation behavior, including whether isolation is mandatory and whether the home directory persists across isolated sessions, and surfaces that in the sandbox settings summary and warnings. - Area: Sandbox - Names: `isolation.required`, `isolation.persistHome` - Tier: Use it now - Useful: 4/5 - Signal: 2/5 ### New skill-registration call for a 'Create a new Cowork plugin' skill added to startup Startup now registers a built-in skill for creating or customizing a Cowork plugin **What** Claude Code's startup process now registers an additional built-in skill alongside its existing ones, for creating a Cowork plugin. Its description tells Claude it can create a new Cowork plugin from scratch, or customize an already-installed plugin for a specific organization. **Why** Registering the skill at startup makes this plugin-creation capability available to Claude automatically, without the user having to discover or invoke it manually. - Area: Cowork - Tier: Use it now - Useful: 4/5 - Signal: 2/5 ### Model selector / served-catalog fetch now supports org-less (token/api_key) credentials, not just org accounts The model list can now be fetched for accounts using an API key or token, not just full organization accounts **What** Claude Code's model selector, which fetches the list of available models from the server, previously only worked for full organization accounts. It now also works for accounts authenticated with a plain token or an API key, using a different server address built for that purpose. The client also now distinguishes between two reasons the model list might be unavailable: being not permitted, versus this new route not yet being enabled on the server side. **Why** This lets users who authenticate with a token or API key, rather than a full organization login, get an accurate list of available models instead of being limited to the organization-only path. - Area: Models - Tier: You'll notice - Useful: 4/5 - Signal: 2/5 ### Unknown slash commands can now fall back to sending the text to the model An unrecognized /command can now be sent to Claude as a normal prompt instead of always erroring **What** Previously, typing a `/command` that Claude Code didn't recognize always produced an "Unknown command" error. Now, in normal interactive use (not inside a subagent or non-interactive mode), Claude Code can instead fall back to treating your whole input as a regular message to Claude. **Why** This avoids a dead-end error for input that merely looks like a slash command but isn't, letting Claude try to make sense of it as a normal prompt instead. - Area: Slash Commands - Tier: You'll notice - Useful: 4/5 - Signal: 2/5 ### New tool: FetchInboxMessage (Remote Control session inbox) New FetchInboxMessage tool reads Remote Control inbox messages, marking only rc_owner-sourced ones as trusted **What** A new tool called `FetchInboxMessage` lets a Remote Control session (a session controlled from a linked chat, such as Slack or Teams, or the Claude Code project thread) fetch a single message from its 'inbox' by a `file_id`, in response to a `session-inbox` notification. The message comes back wrapped with trust markers. Only messages whose outer envelope is marked `from="rc_owner"` are treated as a genuine request from the user. Anything else is flagged as untrusted third-party text that must not be acted on without first confirming with the user. **Why** This lets Remote Control sessions pull in messages relayed from chat threads while still distinguishing the account owner's own instructions from text sent by other people, reducing the risk of Claude Code acting on someone else's message as if it were a command. - Area: Remote Control - Names: `FetchInboxMessage` - Tier: Nothing to try yet - Useful: 4/5 - Signal: 2/5 ### Bridge/CCR sessions gain active-subscriber stream flush tuning Remote Control's live streaming can now have its flush timing tuned remotely, not just its idle behavior **What** The transport client used for Remote Control (and Claude Code on the web) sessions already let the server configure how often data is flushed when nobody is watching a session, how long to hold uploads with no subscriber, and whether to drop unwatched events. It now also accepts two more runtime settings: `setStreamEventFlushIntervalMs`, controlling how often stream events are flushed while someone is actively watching, and `setStreamEventFirstFlushMs`, a delay before the very first flush. **Why** This gives Anthropic finer server-side control over streaming responsiveness for actively-watched remote sessions, separate from the tuning that already existed for idle ones. - Area: Remote Control - Names: `setStreamEventFlushIntervalMs`, `setStreamEventFirstFlushMs` - Tier: Use it now - Useful: 3/5 - Signal: 2/5 ### New gate for delaying the first CCR stream-event flush A new setting can make the first telemetry stream event flush immediately instead of waiting for the normal batching interval **Unclear.** Whether this is active for this site's account is not established; the related gate is unread. **What** A new `streamEventFirstFlushMs` setting controls how quickly the very first `stream_event` telemetry record is sent to Anthropic's backend. It defaults to 0 (no change), but when set above zero, the first event skips the normal batched flush-interval wait and is sent sooner. **Why** This is internal telemetry plumbing; when enabled it should make early session activity visible to Anthropic's systems faster, without changing anything else about how the client behaves. - Flag `tengu_ccr_stream_first_flush_ms`: Not enough to say (read for one account on one subscription tier against v2.1.273; this account: no value returned, anonymous baseline: no value returned, 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. - Area: Telemetry - Names: `streamEventFirstFlushMs` - Tier: Use it now - Useful: 3/5 - Signal: 2/5 ### Parked-permission timeout no longer a hardcoded constant The wait time before a parked permission prompt times out is now configurable, not fixed **What** When Claude Code "parks" a permission request (waiting for you to answer whether a tool can run) and no answer comes back in time, it falls back after a wait period. That wait period used to be a fixed number; it's now read per-request from a setting, which in turn comes from the environment variable `CLAUDE_CODE_PARKED_PERMISSION_WAIT_MS` (still defaulting to 2000 milliseconds). **Why** Making the timeout configurable per situation rather than one fixed value allows more flexibility in how long Claude Code waits for a permission answer before giving up. - Area: Permissions - Names: `CLAUDE_CODE_PARKED_PERMISSION_WAIT_MS` - Tier: Use it now - Useful: 3/5 - Signal: 2/5 ### Read tool's HTTP handler helper gains body_file support Read tool's HTTP handler settings now accept a body_file option alongside method, body, mode, and script **What** The `Read` tool's validator for HTTP-handler settings now recognizes a `body_file` key in addition to the existing `method`, `body`, `mode`, and `script` keys. **Why** This means an HTTP request body used by the handler can now be sourced from a file rather than only being supplied inline. - Area: Read Tool - Names: `body_file` - Tier: Use it now - Useful: 3/5 - Signal: 2/5 ### Cloud/bridge session bundle-seeding gated by tengu_ccr_bundle_seed_enabled Seeding a remote or bridged session from a local git bundle stays behind the tengu_ccr_bundle_seed_enabled gate **What** When starting a remote or teleported session, Claude Code can seed the remote environment from a local git bundle instead of doing a full sync. This path remains gated behind the `tengu_ccr_bundle_seed_enabled` flag, or forced on via the `CCR_ENABLE_BUNDLE` environment variable, and defaults off otherwise. **Why** Bundle seeding can be faster than a full sync when preparing a remote session, but it stays behind a gate so it can be rolled out gradually. For this site's account, the flag server currently returns this gate on, matching the anonymous baseline reading, though no reading has been taken under this specific release yet. - Flag `tengu_ccr_bundle_seed_enabled`: Gate removed from the code (read for one account on one subscription tier against v2.1.273; this account: on, anonymous baseline: on, 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. - Area: Remote Control - Names: `CCR_ENABLE_BUNDLE` - Tier: Nothing to try yet - Useful: 3/5 - Signal: 2/5 ### Bundle-seeding for remote teleport sessions, gated by an unresolved flag Remote teleport sessions can now seed the workspace with a git bundle, controlled by env vars and a flag **What** When starting a remote "teleport" session, Claude Code now decides whether to package the local workspace as a git bundle and upload it to seed the remote environment. This is controlled by: - `CCR_FORCE_BUNDLE`, an environment variable that forces bundling - `CCR_ENABLE_BUNDLE`, an environment variable that enables bundle seeding - `tengu_ccr_bundle_seed_enabled`, a feature flag that can also enable it These feed into an `allowBundle` decision that determines whether the bundle gets uploaded. **Why** This gives remote teleport sessions a way to start with the same repository state as the local machine by uploading a packaged git bundle, rather than relying solely on cloning from a remote. - Flag `tengu_ccr_bundle_seed_enabled`: Gate removed from the code (read for one account on one subscription tier against v2.1.273; this account: on, anonymous baseline: on, 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. - Area: Remote Control - Names: `CCR_ENABLE_BUNDLE` - Tier: Nothing to try yet - Useful: 2/5 - Signal: 2/5 - Present in the build but not switched on ### Artifact document tool: `__delete__` sentinel added for field removal in updates Artifact document tool can now delete a field by setting it to {"__delete__": true} **What** The tool Claude Code uses to write to artifact documents (files or documents it generates and edits) now documents a special value for its `data` parameter: setting a field to `{"__delete__": true}` during an update removes that field entirely, instead of just changing its value. **Why** This gives Claude a way to explicitly remove a field from an artifact's data during an update, rather than only being able to overwrite fields with new values. - Area: Artifacts - Names: `__delete__` - Tier: Use it now - Useful: 3/5 - Signal: 1/5 ### write_db 'update' now documents field deletion via __delete__ sentinel write_db's update operation now documents deleting a field with a __delete__ sentinel value **What** The `write_db` tool's documentation now explains how to delete a field when using the `update` database operation (`db_op`): setting a field's value to `{"__delete__": true}` removes that field from the document instead of just overwriting it. **Why** This gives artifacts (shareable pieces of content or apps Claude can create, backed by a small shared database) a documented way to actually remove a field from a stored document, rather than only being able to overwrite fields with new values. - Area: Artifacts - Names: `__delete__` - Tier: Use it now - Useful: 3/5 - Signal: 1/5 ### New CLI diagnostics for malformed --tools entries The --tools flag now gives specific warnings for common typos and formatting mistakes **What** The `--tools` flag, which restricts which built-in tools Claude Code can use, now parses its entries more carefully and warns about specific common mistakes: - an entry that doesn't match any recognized built-in tool name (possible typo) - a rule written with parentheses where a plain tool name was meant - an exclusion prefix (like `!`) separated from the tool name by a stray space - a bare exclusion prefix with nothing after it **Why** These warnings catch malformed `--tools` entries that would otherwise silently fail to do what was intended, such as a tool being unexpectedly withheld because of a typo, without any explanation. - Area: Elsewhere - Names: `--tools` - Tier: Use it now - Useful: 2/5 - Signal: 1/5 ## Improvements ### Artifact publish now pre-reserves a slug, but only when multi-file artifacts are enabled Publishing a brand-new artifact can now reserve its address in advance, when a related setting is enabled **What** When publishing a brand-new artifact (one with no existing slug or create path yet), Claude Code can now call a new step that reserves the artifact's address ahead of time, before the actual publish request is sent. This only happens under specific conditions: no slug or create path already exists, and multi-file artifacts are enabled while another related condition is not. **Why** Reserving the address in advance helps ensure the artifact's final location is settled before publishing begins, reducing the chance of conflicts during publish. - Flag `tengu_cobalt_plinth_bracken`: On for this account, and not off by default (read for one account on one subscription tier against v2.1.273; this account: on, anonymous baseline: on, 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. - Area: Artifacts - Tier: You'll notice - Useful: 3/5 - Signal: 2/5 ### PR-tracking regex replaced with a streaming scan supporting gh/glab head-branch extraction PR-detection from terminal output now also extracts and validates the target branch **What** Claude Code scans terminal output for `gh pr create` or `glab mr create` commands to link a session to the pull request or merge request it created. This scanning logic was rewritten as a streaming scan, and it now also extracts the target branch from the `--head`/`-H` (for `gh`) or `--source-branch`/`-s` (for `glab`) flags, validating that it's a safe git reference before using it. **Why** Capturing and validating the target branch gives Claude Code a more accurate record of where a pull or merge request was aimed, while the validation guards against unsafe input being used as a git reference. - Area: Git Integration - Tier: You'll notice - Useful: 3/5 - Signal: 2/5 ### Chat attachments now treated as 'staged' working-directory files for read/upload permission Chat attachments are now treated as part of the working directory for permission checks **What** Files that come from things like chat attachments live in a special "staged" directory tied to the session. Claude Code now recognizes that these staged files count as being inside your working directory (the folder Claude is operating in), so reading or uploading them no longer triggers the "ask permission" prompt that would otherwise apply to files outside that folder. This applies across the read, upload, and database-write permission checks. Unlike a normal approval, this staged-file allowance only covers that single action, it does not carry over and automatically approve the rest of the session. **Why** This avoids unnecessary permission prompts for files you've already handed to Claude directly (like a pasted or uploaded attachment), while still keeping the approval narrowly scoped rather than opening up broader access for the rest of the session. - Area: Permissions - Tier: You'll notice - Useful: 3/5 - Signal: 2/5 ### Teleport relay extended to forked (subagent) queries The teleport relay mechanism now also handles forked (subagent) queries, not just the main thread **Unclear.** What the teleport relay does for the user, and what leaving or staying off it changes in practice, is not stated in the finding. **What** Claude Code has a "teleport relay" dispatch mechanism that previously only served queries on the main conversation thread. It now has a dedicated branch for forked queries (used by subagents), which checks whether a fork's existing context and tools are unchanged since an earlier relay decision was made, and logs when a fork's request has to leave the relay or is deliberately kept off it. **Why** This extends the relay mechanism's reach to subagent queries, though the finding doesn't specify what the relay itself accomplishes for the user. - Flag `tengu_wild_tome`: On for this account, and not off by default (read for one account on one subscription tier against v2.1.273; this account: on, anonymous baseline: on, 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. - Area: Subagents - Tier: You'll notice - Useful: 3/5 - Signal: 2/5 ### Forked-agent relay eligibility gated by tengu_wild_tome (default off) A new flag decides if a forked agent's query is eligible for the teleport relay, based on the tengu_wild_tome setting **What** When a forked or background agent query runs, Claude Code now computes a `relayEligible` flag. It's only true when the fork has no separate agent ID of its own, has forked context messages, keeps the same set of tools as its parent, and the setting `tengu_wild_tome` is enabled. This flag is passed into the query as `relayFork` and recorded in telemetry as `relayEligible` once the fork completes. **Why** This determines, on a case-by-case basis, whether a subagent's query can use the teleport relay mechanism, restricting it to forks that haven't diverged from their parent's context and tools. - Flag `tengu_wild_tome`: On for this account, and not off by default (read for one account on one subscription tier against v2.1.273; this account: on, anonymous baseline: on, 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. - Area: Subagents - Tier: You'll notice - Useful: 3/5 - Signal: 2/5 ### /usage command result gains a structured payload The /usage command's reply can now carry structured data, not just the readable text report **What** When you run `/usage`, Claude Code shows session cost, plan usage limits, and activity stats. The message that delivers this report can now also carry a structured `usage_report` object, alongside the existing markdown text, containing session totals, plan usage rows, and extra-usage spend. **Why** This is for remote clients: instead of having to parse the markdown text, a client can read the structured data directly and render it as a card or custom view. - Area: Usage - Names: `/usage` - Tier: You'll notice - Useful: 3/5 - Signal: 2/5 ### New managed-only settings key: isolation The new 'isolation' settings key is now managed-only, like managedMcpServers, and gets stripped with a warning if set elsewhere **What** Claude Code already warned and removed `managedMcpServers` if it was set outside managed settings, since that key is meant to be provided by an administrator through managed settings only. A new key, `isolation`, now gets the same treatment: if it's found in a non-managed settings source, it's deleted from the loaded settings and a warning explains that it "is only honored from managed settings and was ignored here." Both keys are now marked to be preserved when settings are written back out. **Why** This keeps the `isolation` setting under administrator control, preventing it from being set or overridden in ordinary user or project settings files. - Area: Settings - Names: `isolation` - Tier: You'll notice - Useful: 3/5 - Signal: 2/5 ### tengu_bridge_child_auto_mode now defaults on The gate for defaulting bridge-spawned child sessions to Auto mode now compiles to true by default **What** When the Claude remote-control bridge (which connects the Claude mobile app to a Claude Code session on your computer) spawns a child session, it can default that session to Auto permission mode. The internal flag controlling this default, `tengu_bridge_child_auto_mode`, now compiles to true instead of false. This flag also decides whether the spawn path fetches session tags before starting, and feeds into whether a spawned bridge child receives the `CLAUDE_CODE_BRIDGE_CHILD_AUTO_DEFAULT` setting. **Why** This is a change to the compiled default of an internal flag, not a statement about whether it is switched on for any particular account; whether it actually takes effect depends on server-side rollout. - Flag `tengu_bridge_child_auto_mode`: Not enough to say (read for one account on one subscription tier against v2.1.273; 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. - Area: Remote Control - Names: `CLAUDE_CODE_BRIDGE_CHILD_AUTO_DEFAULT` - Tier: You'll notice - Useful: 3/5 - Signal: 2/5 ### Remote Control bridge inbox-message fetch is implemented (was a hard-coded stub) Remote Control's inbox-message fetch is now functional instead of always reporting the feature disabled **What** The Remote Control bridge (which lets a Claude Code session be driven from another device) has a handler for fetching an inbox message for a session. Previously this handler always returned a "feature disabled" response no matter what. It now performs a real fetch: it checks whether the session's owner has changed, refreshes the authentication token if needed, and retrieves the message using the session ID, file ID, base URL, and access/trusted-device tokens. **Why** This turns a previously stubbed-out, always-failing code path into working functionality, so inbox messages sent to a Remote Control session can actually be delivered. - Area: Remote Control - Tier: You'll notice - Useful: 3/5 - Signal: 2/5 ### Remote Control now enforces a minimum-version floor before accepting sessions started remotely Remote Control now checks your Claude Code version meets a minimum before accepting a remotely started session **Unclear.** Nothing has been read yet about whether the `tengu_bridge_min_version` gate is switched on for any account. **What** When a session is started remotely (via Remote Control), Claude Code now checks that the local installation meets a required minimum version, and distinguishes three ways that check can fail: - the required version couldn't be retrieved from the server at all - the value received from the server was malformed - the local installation is genuinely below the required version Each case now shows its own distinct message explaining what went wrong. **Why** This makes it clearer why a remotely started session was rejected, instead of showing one generic failure for what could be three different underlying problems. - Flag `tengu_bridge_min_version`: Not enough to say (read for one account on one subscription tier against v2.1.273; this account: no value returned, anonymous baseline: no value returned, 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. - Area: Remote Control - Tier: You'll notice - Useful: 2/5 - Signal: 2/5 ### Enterprise MCP-server-allowlist policy can now be inherited from lower-priority settings sources MCP server allowlist policies can now be inherited from lower-priority settings sources, with new diagnostics **What** The settings that control `allowManagedMcpServersOnly` (restricting MCP servers, which extend Claude Code with external tools, to only an admin-managed list) and `allowedMcpServers` (the allowlist itself) are now computed by combining the highest-priority settings source with a list of lower-priority admin policy sources, instead of reading from a single merged settings object. A new diagnostic also detects and reports when the actual lock or allowlist in effect is being supplied by one of those lower-priority sources rather than the top one, including how many settings and keys are being shadowed this way. **Why** This lets an MCP server policy set at a lower-priority level (for example, an organization-wide default) still take effect when a higher-priority source doesn't set it, and the new diagnostics make it possible to see exactly which settings source is actually controlling the policy. - Area: MCP - Names: `allowManagedMcpServersOnly`, `allowedMcpServers` - Tier: You'll notice - Useful: 2/5 - Signal: 2/5 ### Artifact template field no longer gated Setting a template on a new artifact no longer requires a feature flag to take effect **What** When Claude Code builds the request to create an artifact, the `template` field is now included whenever a template is specified. Previously, including it also required an internal feature check to pass; that check has been removed. **Why** Artifact templates now work consistently whenever one is specified, rather than depending on an additional gate. - Area: Artifacts - Tier: You'll notice - Useful: 2/5 - Signal: 2/5 ### Claude-in-Chrome default-enable now skipped when bridge child auto-reconnect is active Claude-in-Chrome no longer turns on by default when a bridge child is auto-reconnecting **What** The check that decides whether Claude-in-Chrome (a feature that lets Claude control a Chrome browser) turns on by default now also looks at whether the current session is a "bridge child" auto-reconnecting to another device, and skips defaulting it on in that case unless the session is specifically in "bridge-child machine-settings" mode. **Why** This prevents Claude-in-Chrome from being silently enabled in the middle of a remote/bridged session reconnect, which wasn't accounted for before. - Area: Chrome - Tier: You'll notice - Useful: 2/5 - Signal: 2/5 ### New version-floor check declines bridge sessions on outdated machines Bridge sessions now check the machine's Claude Code version before spawning, and refuse if it's too old **Unclear.** The gates named below (`tengu_bridge_min_version`, `tengu_bridge_rc_child_artifact`, `tengu_bridge_child_machine_settings`) are unread for this account, so whether they are switched on isn't known. **What** Before starting a "bridge worker" (a process that lets a session hand off or connect to another machine), Claude Code now checks whether that machine meets a minimum required version, advertised by the server. If the machine's Claude Code build is below that minimum, or the server's answer is missing or malformed, and the session was going to run in a particular remote-control role (a "project-thread-child"), the session is declined with an error instead of starting. A new telemetry gate, `bridge_machine_lane_floor`, fires when this happens, and new error messages explain that the session can't be taken over on a machine below the required version. **Why** This stops remote-control sessions from being handed to a machine running an outdated Claude Code build that might not support them properly, giving a clear error instead of a silent failure. - Flag `tengu_bridge_min_version`: Not enough to say (read for one account on one subscription tier against v2.1.273; this account: no value returned, anonymous baseline: no value returned, 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. - Flag `tengu_bridge_rc_child_artifact`: Not enough to say (read for one account on one subscription tier against v2.1.273; 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. - Flag `tengu_bridge_child_machine_settings`: Not enough to say (read for one account on one subscription tier against v2.1.273; 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. - Area: Remote Control - Tier: You'll notice - Useful: 2/5 - Signal: 2/5 ### HIPAA policy settings gain a 'hard block' tier HIPAA compliance settings gain a stricter 'hard block' tier alongside existing denial rules **Unclear.** What practical difference a hard block has from denial (e.g. whether it can be overridden) is not stated. **What** Several HIPAA compliance settings — Memory sync, Projects, Team onboarding, and Peer messaging — now carry a new `hardBlockUnder: ["hipaa"]` property in addition to their existing `deniedUnder` setting. **Why** This introduces a stricter enforcement tier for HIPAA-covered accounts, distinguishing a hard block from ordinary denial for these features. It matters mainly to organizations operating under HIPAA compliance requirements. - Area: Elsewhere - Names: `hardBlockUnder` - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### New session-wide lock message for restricted-policy orgs New message explains when a feature stays disabled for the rest of a session after a restricted-policy org signed in **What** A new message has been added alongside the existing "disabled by your organization's policy" message. It explains that once a session has seen a sign-in from an organization with a restricted policy, a feature stays disabled for the rest of that session, even if you later sign in with a different account. **Why** This clarifies a behavior that could otherwise be confusing: switching accounts mid-session doesn't necessarily re-enable a feature that a restricted-policy organization's sign-in had turned off, and now Claude Code tells you why. - Area: Auth - Tier: You'll notice - Useful: 2/5 - Signal: 2/5 ### New "machine lane floor" version check for Remote Control sessions Claude Code now refuses to spawn or attach to a Remote Control session that requires a newer client version **What** Before spawning or attaching to a bridge/Remote Control session, the client now checks a version floor against the session's requirements. If the session needs a newer version of Claude Code than the machine is currently running, the machine declines it instead of trying to serve it, logging a message like "Declined session ..." or "Remote Control could not attach: ...". This also fires a new telemetry event, `bridge_machine_lane_floor`, with a reason such as `below_floor`, `floor_malformed`, or `floor_unanswered`. **Why** This prevents an out-of-date Claude Code installation from trying to run a Remote Control session it isn't equipped to handle, failing clearly instead of behaving unpredictably. - Flag `tengu_bridge_min_version`: Not enough to say (read for one account on one subscription tier against v2.1.273; this account: no value returned, anonymous baseline: no value returned, 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. - Area: Remote Control - Tier: You'll notice - Useful: 2/5 - Signal: 2/5 ### MCP server allowlist can now be sourced from admin tiers even without an explicit slot override MCP server allowlist can now fall back to an org admin tier's setting when local settings don't override it **What** Settings resolution for the MCP (Model Context Protocol) server allowlist now checks whether `allowManagedMcpServersOnly` or `allowedMcpServers` are effectively set by an organization admin tier, rather than only by local settings. If the local settings slot doesn't explicitly set `allowManagedMcpServersOnly` to false, the resolution now falls back to whatever the admin tier's allowlist specifies. **Why** This lets an organization's admin-level MCP allowlist apply even when a user hasn't set anything locally, rather than requiring an explicit override at every level. - Area: MCP - Names: `allowManagedMcpServersOnly`, `allowedMcpServers` - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### GitHub App install now detects SAML SSO enforcement /install-github-app now recognizes SAML SSO enforcement and explains how to re-authorize **What** `/install-github-app`, which installs the Claude GitHub App for a repository, now recognizes when a repository access check fails because of SAML single sign-on (SSO) enforcement. Instead of showing a generic failure, it shows "Single sign-on authorization needed" with instructions to either re-authorize the GitHub CLI login and authorize the organization for SSO, or configure SSO on a personal access token. **Why** Organizations that enforce SAML SSO on GitHub previously got an unhelpful generic error during setup. Now the command tells the user exactly what's blocking access and how to fix it. - Area: GitHub - Names: `/install-github-app` - Tier: You'll notice - Useful: 3/5 - Signal: 1/5 ### Artifact publish: overhauled unservable-file-type error messages with new content-type taxonomy Artifact publish errors for unservable file types now explain what to do, grouped by category **What** When publishing an artifact fails because a file's content type isn't one Claude Code can serve, the error message is now far more detailed. It groups servable content types into categories such as pages, styles, scripts, data, images, fonts, media, and documents, lists which file extensions belong to each, and gives targeted advice, for example pointing out when a rejected type has a close servable alternative, or when the file extension is a recognized but unservable type. Claude Code also now records `refused_ext` and `refused_type` details in its `artifact_publish` / `file_not_servable` telemetry event. **Why** Instead of a bare rejection, users publishing an artifact now get concrete guidance on why a file's type isn't supported and what servable alternative to use instead. - Area: Artifacts - Tier: You'll notice - Useful: 3/5 - Signal: 1/5 ### Bedrock/Vertex/Foundry/Gateway auth errors get provider-specific guidance Login errors from Bedrock, Vertex, Foundry and Gateway now show provider-specific fix-it guidance instead of one generic message **What** When a request to a model provider fails with an authentication error (401/403), Claude Code now shows guidance tailored to which provider you're using, instead of one generic error for all of them: - Amazon Bedrock: including a new check for when a model simply isn't enabled for your account/region, with instructions to enable it in the Bedrock console - Google Vertex AI - Foundry: a new dedicated auth-failure message - Gateway: a special message for 403 errors **Why** Authentication failures have different causes and fixes depending on which backend you're connecting through, so pointing you at the right console or setting saves time compared to a one-size-fits-all error. - Area: Auth - Tier: You'll notice - Useful: 3/5 - Signal: 1/5 ### Memory-directory prefetch now respects blockReadsOutsideWorkingDirectories Memory-file prefetching now also respects the block-outside-directory-reads setting **What** When Claude Code warms up its memory context by prefetching files from a memory directory, it now checks the `blockReadsOutsideWorkingDirectories` setting (which makes file tools refuse reads outside your designated working directories) before reading a candidate file. If that setting is on, it verifies the file is actually inside the working directory first. If that check itself fails with an error, the read is blocked rather than allowed. **Why** This closes a gap where memory prefetching could have read files outside your working directory even with `blockReadsOutsideWorkingDirectories` turned on, and it errs on the side of blocking when it can't be sure. - Area: Memory - Names: `blockReadsOutsideWorkingDirectories` - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### SSL certificate errors now include a docs link and a plainer explanation SSL certificate errors now explain the likely corporate-proxy cause and link to setup docs **What** When Claude Code fails to connect because of a certificate verification error (such as an unverifiable or self-signed certificate), the error message now explains that this usually happens because of a corporate proxy that inspects TLS traffic, or a private certificate authority gateway. It points to the `NODE_EXTRA_CA_CERTS` environment variable as the fix, and links to the network configuration documentation page. **Why** This makes it much easier to understand and resolve a common cause of connection failures on corporate networks, instead of just seeing a cryptic certificate error. - Area: Internals - Names: `NODE_EXTRA_CA_CERTS` - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Sandbox/settings diff UI now surfaces 'isolationSettings' as its own category Settings-diff view adds a dedicated 'isolation settings' category alongside shell, env, and sandbox settings **Unclear.** The finding does not say what specifically counts as an 'isolation setting' as opposed to a 'sandbox setting'. **What** The screen that shows what's different between settings sources (used for sandboxing and permission configuration) now tracks `isolationSettings` as its own category, alongside the existing shell settings, environment variables, and sandbox settings categories. This is tracked both overall and per individual settings source, and the diff summary now includes a separate list of isolation-related rows. **Why** This lets isolation-related settings differences be reviewed on their own rather than being mixed in with other sandbox settings. - Area: Sandbox - Names: `isolationSettings` - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### agent-proxy CA can now also be written to an extra symlink path The agent proxy's trusted certificate can now also be linked to an extra file path during install **What** When Claude Code installs its certificate authority (CA) so the agent proxy is trusted by the system, each install method can now also specify an extra symlink location. If provided, Claude Code writes or updates a symlink pointing to the installed certificate record at that additional location, alongside the main certificate file. **Why** This lets install methods that expect the certificate at more than one filesystem path keep both locations in sync automatically. - Area: Elsewhere - Tier: Under the hood - Useful: 2/5 - Signal: 1/5 ### cd-before-git-hook warning now covers any version-control command, not just git The directory-change safety warning before a version-control command now covers more than just git **What** Claude Code warns when a compound terminal command changes directory and then runs a version-control tool, because that pattern can pick up untrusted hooks or repository settings from the new directory. This warning previously mentioned git specifically; it now applies its wording generally to any version-control command, not just git. **Why** This ensures the same protection and warning message applies consistently across different version-control tools, not just git. - Area: Bash Safety - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Artifact tool descriptions now flag "outside writer" edits Artifact tool prompts now warn when someone outside your organization may have edited the artifact **What** When Claude Code asks for permission to use an artifact tool action (such as reading, listing, or deleting files or assets), the description shown now includes a bracketed note reading "[outside writer: someone outside the user's organization may have written to this artifact]" whenever that's the case. **Why** This flags a potential trust concern before an action is approved, letting the user know the artifact may have been modified by someone outside their organization. - Area: Artifacts - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Design-system README lookup now supports a project-scoped README Artifact design-system guide lookup now also checks a project-level README file **What** When Claude Code fetches the design-system guide used for artifacts, it now also looks for a `project/README.md` file, in addition to the existing store or file-level README it already checked. The lookup also now distinguishes more specific failure reasons: being blocked by a rule, lacking consent, the file having moved, or the file being unreadable. **Why** Checking a project-scoped README gives artifacts a chance to pick up design guidance defined at the project level, and the more specific failure reasons make it clearer why a guide wasn't found when it isn't. - Area: Artifacts - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### New reminder when a user's slash command doesn't exist Claude Code now recognizes when a typed slash command doesn't exist and stops it faking a run **What** If you type a slash command (a shortcut command starting with `/`) that isn't actually available in your session, Claude Code now detects this and quietly injects a note for Claude explaining what happened. That note: - names the command you typed, if it's safe to show - suggests the closest matching command that is actually available - lists the commands that are available in the session - tells Claude to treat your message as a plain request instead **Why** Previously an unrecognized slash command could lead Claude to make things up, such as claiming the command ran or inventing installation steps. Now Claude is explicitly steered to just do what you asked as a normal request, and to point you toward the right command if one exists. - Area: Slash Commands - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Artifact type listing now includes types "shared with" the user Listing artifact types now distinguishes types shared with you from your own and your organization's **What** When Claude lists artifact meta-types (such as design systems) using the `list` action, the instructions now describe three categories instead of two: types you own, types belonging to your organization, and types specifically shared with you. The formatter behind this listing now labels shared rows more precisely, distinguishing shared-with-you from shared-within-the-organization rather than lumping both under a generic "shared" label. **Why** This gives a clearer picture of where a listed artifact type actually comes from, so it's less confusing when browsing types that aren't your own. - Area: Artifacts - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Task status can now report a worker-restart reason Background tasks can now report they stopped because the worker process restarted **What** The status information for a background task now supports a `reason` field with the value `worker_restart`. It's used when a task is automatically stopped because the underlying worker process restarted and found the task orphaned (left without a running process to resume it) when it came back up. This always appears together with a status of `stopped`, and the same value appears in task stop notifications. **Why** This gives a specific, documented explanation when a background task stops unexpectedly due to the worker restarting, rather than leaving it unclear why the task ended. - Area: Background Tasks - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Bash subshell/cd checks: new content scan for unparsed command substitutions Bash cd checks now scan command substitutions inside unparsed subshells for risky commands like rm **What** When Claude Code can't fully analyze a bash subshell (an 'unparsed command substitution') that also contains a `cd`, it now separately scans the command and process substitutions inside it, looking for risky commands such as `rm` or `rmdir` hidden within them. If there are more than 64 such substitutions to check, Claude Code now denies the command outright with the message 'too many command substitutions to analyze', rather than trying to analyze all of them. **Why** This closes a gap where a destructive command like `rm` could be tucked inside a subshell that changes directory, and it makes Claude Code refuse rather than guess when there's too much nested substitution to safely check. - Area: Bash Safety - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### New provenance warning for artifacts with outside contributions Artifacts with HTML content from outside contributors now get an explicit warning to treat it as data, not instructions **What** When an artifact (a generated piece of content, like a document or app) includes HTML content that was published by writers outside the user's organization, Claude Code now wraps it with an explicit warning telling the model to treat that content as untrusted data rather than as instructions, and forbidding it from changing permissions or configuration based on anything in it. **Why** This defends against prompt injection, where text embedded in content tries to trick the model into taking unintended actions. Outside contributors can no longer smuggle instructions into an artifact that Claude would otherwise follow. - Area: Artifacts - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### New startup warning for MCP policy keys shadowed across managed settings sources Claude Code now warns at startup if MCP policy settings are being silently overridden by another managed settings file **What** Claude Code now checks, at startup, whether any MCP-related policy keys are set in a managed settings source that gets overridden by a higher-precedence one. If so, it logs a warning listing those keys and points to `/status` (the Settings interface's Status tab) to see which ones are affected. **Why** Administrators who set MCP policy in the wrong settings file previously had no indication their settings were being silently ignored. This warning surfaces the conflict so it can be fixed. - Area: MCP - Names: `/status` - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### New 'isolation setting' category in sandbox permission summaries Permission prompts for sandbox settings now include a distinct 'isolation setting' count **What** When Claude Code shows a permission prompt summarizing sandbox-related settings (for example, "3 sandbox settings"), it now includes a new category alongside the existing ones, shown as "`` isolation setting." **Why** This lets a permission summary call out isolation-related settings specifically, rather than lumping them into a generic sandbox count. - Area: Sandbox - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### New outright-deny path for permission rules on code-running tools Permission rules can now flatly deny tools that run code as another denied tool would **What** When Claude Code checks whether a tool is allowed to run because it "runs code as" another tool would, it previously only checked for a matching "ask" permission rule. It now also checks first for a matching "deny" rule (not counting rules that come from tool-narrowing). If one is found, the action is flatly refused with the message: "Permission to use `` has been denied: it runs code as `` does, and a rule denies ``." **Why** Previously, a rule that denied one tool could be bypassed by using a different tool that runs code the same way, since only "ask" rules were checked in that path. Now a deny rule on the underlying capability blocks it outright. - Area: Permissions - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### OSC 11 theme query skipped when terminal reports its own theme via a 'surface' push Claude Code skips asking the terminal for its background color when the terminal already pushed its own light/dark setting **What** Claude Code can detect whether your terminal is using a light or dark theme by sending a query (OSC 11) that asks for the terminal's background color. Now, if the terminal has already told Claude Code its theme directly through a 'surface' push notification, Claude Code trusts that notification and skips sending the OSC 11 query, logging 'surface override active, skipping OSC 11 query'. **Why** This avoids an unnecessary and potentially redundant terminal query when the terminal is already actively reporting its theme, relying on the more direct signal instead. - Area: Elsewhere - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### gerrit/created 'branch' field now also carries branch info for newly-created changes The `branch` field reported for VCS changes now also carries the source branch for newly-created changes on any provider, not just Gerrit **What** When Claude Code reports version-control changes to a host application, it includes a `branch` field. This used to be sent only for providers without their own head-branch concept, such as Gerrit. Now it's also sent for any provider when the change kind is 'created': in that case it carries the branch the create was opened from, taken from a `--head`/`--source-branch` flag or the working branch. **Why** This lets a host display the newly created change right away, using the branch Claude Code already knows, instead of waiting for its own lookup against the forge (the hosting service) to come back. - Area: Elsewhere - Tier: Under the hood - Useful: 2/5 - Signal: 1/5 ### Settings 'not applied' warning now names the source file and lists all affected keys Claude Code now warns by name when settings keys are set in a managed-settings file that doesn't actually apply to them **What** Claude Code can now detect when settings keys are configured in a managed-settings file whose source doesn't apply for those particular keys. When this happens, it shows a new warning that names the specific source file, lists every offending key, and tells the user to either remove them or move them to a settings source that does apply, pointing to `/status` (the Settings interface, on the Status tab) to see the list of settings sources. **Why** This surfaces settings that are silently being ignored because they're defined in the wrong place, so users can find and fix misconfigured settings instead of wondering why a setting isn't taking effect. - Area: Settings - Names: `/status` - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### New GitHub-app-check 403 detector for IP allowlist / app suspended / SAML SSO GitHub app installation checks now detect and explain 403 errors caused by IP allowlists, app suspension, or required SAML SSO **What** Claude Code's check for whether its GitHub app is installed now has a new helper that parses a 403 error response body. When the error is marked as user-facing and its code is one of `github_ip_allowlist`, `github_app_suspended`, or `github_saml_sso_required`, Claude Code now surfaces GitHub's own error message to the user, truncated to 300 characters. This runs alongside the existing rate-limit detection in the same error handler. **Why** This gives users a clear, specific explanation when a GitHub app check fails for one of these access-restriction reasons, instead of a generic error. - Area: GitHub - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Chat attachments now treated as inside working directories for reads Claude can now read chat attachments even when they sit outside the session's working directory **What** A new permission rule lets Claude read files that were attached directly to the chat, even if those files live outside the session's working directories. The file is treated as "inside" the working directories for permission purposes as long as the working-directory access check can resolve its path. **Why** Previously, a file attached to the conversation but stored outside the working directory could otherwise be blocked from reading despite being something the user explicitly shared in the chat. This closes that gap. - Area: Permissions - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Deny/ask permission messages now append the matched rule's own text Permission deny/ask messages now show the exact rule text that triggered the block **What** When a tool call is denied or requires confirmation ('ask') because it matched a specific permission rule, the message shown to the user now appends that rule's own associated hint text, including in cases where the match happened on a nested subcommand. **Why** This makes it clear which permission rule caused a block or prompt, and shows any custom message attached to that rule, instead of leaving the user to guess which rule fired. - Area: Permissions - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### New restricted-region/auth error codes recognized Claude Code now recognizes three new account/auth restriction error codes **What** Claude Code's list of recognized API restriction reasons gained three new codes: - `organization_on_hold` - `oauth_scope_insufficient` - `token_expired` **Why** This lets Claude Code recognize and presumably respond appropriately to more specific account and authentication problems reported by the server, rather than treating them as unrecognized errors. - Area: Auth - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Session-inbox 'wake' messages get a dedicated render component Session wake-up messages from external events now get their own display instead of a generic system message **What** When a session's transcript contains a message that starts with `` · Run `/login`, then try again", using "Claude login not accepted" as the reason when none is otherwise given. **Why** This makes it clearer what to do when authentication fails, pointing directly at the `/login` command instead of leaving you to figure out the fix yourself. - Area: Auth - Names: `/login` - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Message-list scroll 'reveal' rewritten as a cancellable, promise-based landing check Scrolling to a message in the chat view now waits for confirmation it actually landed, instead of retrying a fixed number of times **What** The mechanism that scrolls the message list to reveal a specific message was reworked. It now returns a promise that resolves once the target message has actually settled into place — matching height and position across re-renders — rather than retrying a fixed number of times regardless of whether the scroll succeeded. It also includes a give-up timeout and a way to cancel the operation early. **Why** This should make jumping to a message in the transcript more reliable, since Claude Code now waits for confirmation the scroll actually completed instead of guessing based on a retry count. - Area: UI - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### --chrome flag for Remote Control now blocked by enterprise MCP policy Remote Control's --chrome flag is now blocked when enterprise MCP policy denies the Chrome MCP server **What** Starting Remote Control with `--chrome` now checks whether an enterprise MCP (Model Context Protocol, a standard for connecting external tools) policy exists, and whether the Claude-in-Chrome MCP server is listed in `deniedMcpServers`. If either would block it, Claude Code now exits with an error explaining that `--chrome` is blocked by the organization's MCP policy, telling the user to start Remote Control without it. Previously it proceeded without this check. **Why** This stops `--chrome` from silently starting a browser integration that an organization's MCP policy is meant to prevent, surfacing the block as a clear error instead. - Area: MCP - Names: `--chrome` - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Waiting/spinner status line rewritten with terminal-width-aware truncation The waiting/spinner status line was rewritten to truncate based on available terminal width **What** The header components that show the idle spinner message, the "Reconnecting"/"Disconnected" banner, and the count of background tasks were rewritten around a shared calculator that works out how much horizontal space the status text and the " in background" suffix should each get. If there isn't enough room, the background-task suffix is now dropped entirely rather than being awkwardly truncated. **Why** This keeps the status line readable in narrower terminal windows, instead of letting the background-task count get cut off mid-text. - Area: UI - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### autofix PR: better gh CLI failure messages Autofix PR errors now include the actual gh CLI failure output, not just a generic message **What** When the automatic pull-request-fixing flow runs `gh pr view` (a GitHub command-line tool call) and it fails with an error message but not because the `gh` tool itself is missing, Claude Code now includes the last 3 lines of GitHub's actual error output in the reported error, instead of just a generic error object. **Why** This makes it much easier to diagnose why an autofix pull-request operation failed, since the real error text from GitHub is now visible instead of a vague failure. - Area: GitHub - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Richer PR-webhook subscription failure detail in autofix flow Autofix PR webhook failures now show the specific reason instead of a generic message **What** When the automatic pull-request-fixing flow can't subscribe a session to GitHub pull-request webhooks (notifications GitHub sends about PR activity), and the reason isn't simply that the GitHub app isn't installed, Claude Code now shows the specific `detail` explaining why, trimmed to 300 characters, in both the flow itself and its warning banner. Previously it only showed the generic message "Couldn't subscribe this session to PR webhooks." **Why** This gives users a concrete reason when webhook subscription fails, instead of an unhelpful generic message that gave no clue about what went wrong. - Area: GitHub - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Prompt-suggestion generation now tries multiple candidate replies Prompt-suggestion generation now tries several candidate replies instead of just the first one **What** When Claude Code asks the model to suggest a follow-up prompt, it used to stop at the very first assistant text reply it found and clean it up with a set of regex rules. Now it first collects all of the assistant's candidate text replies, then runs the same cleanup rules over each candidate in order, stopping only once a candidate actually produces a usable, non-empty suggestion. **Why** This makes prompt suggestions more reliable: if the first candidate reply turns out empty or unusable after cleanup, Claude Code now falls through to try the next one instead of giving up. - Area: UI - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Policy-limits fetch cycle gains accelerated retry and 'network kick' recovery Claude Code now retries faster and recovers sooner when it can't fetch your policy limits **Unclear.** Whether this behavior is active for this site's account is not established; the related gates are unread. **What** When Claude Code can't fetch your account's policy limits (usage/permission rules from your organization) and has no recent valid result to fall back on, it now recovers more aggressively: - It arms a faster, randomized-timing retry instead of waiting for the normal poll interval - It also watches for any other successful network call and immediately re-tries the policy-limits fetch when one happens (a "network kick") - It now tracks how long it went without a valid result, and records that when a result is finally recovered **Why** This should shorten the window where Claude Code is operating without confirmed policy limits, particularly after a temporary network hiccup, by recovering as soon as the network shows signs of life again rather than waiting out a fixed timer. - Area: Elsewhere - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Session-create errors get a dedicated 401 message pointing at /login Failing to create a remote session now shows a specific message telling you to run /login on a 401 error **What** When creating a remote (teleport) session fails, Claude Code now checks the HTTP status code before showing an error. If the failure is a 401 (unauthorized), it now shows a specific message telling you to run `/login` and try again, instead of just the raw server error or generic status text. **Why** A 401 during session creation almost always means you need to sign back in, so pointing directly at `/login` saves you from having to interpret a generic error message. - Area: Auth - Names: `/login` - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Bash 'too complex' command handling reworked with a per-reason-kind table gating the outside-working-directory read block Bash's 'too complex to check' read-block guard now applies via a general table covering more refusal reasons, not just one hardcoded case **Unclear.** Whether this behavior is active for this site's account is not established; the related gate is unread. **What** When `permissions.blockReadsOutsideWorkingDirectories` is turned on (which makes file tools refuse reads outside your designated working directories), Bash commands that can't be reliably checked against that rule are refused. Previously this only applied to commands flagged as "too complex." Now a table of refusal reasons decides which ones trigger the same refusal, including: `too-complex`, `semantics`, `multi-cd`, `shell-operators`, `cd-git-compound`, and `process-substitution`. Other reasons, like `dangerous-path`, `flag-validation`, `net-redirect`, and `sed-dangerous`, are explicitly excluded. **Why** This broadens the read-block safety net to more kinds of Bash commands that are hard to statically verify, closing gaps where a command could previously slip past the outside-working-directory read restriction just because it wasn't classified as "too complex." - Area: Bash Safety - Names: `blockReadsOutsideWorkingDirectories` - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### MCP OAuth/auth failure messages split into four specific cases MCP authentication failure messages now split into four specific cases instead of two generic ones **What** When an MCP (Model Context Protocol, used to connect Claude Code to external tool servers) tool call fails because of invalid or expired credentials, the error message now distinguishes four situations instead of two: - A claude.ai connection needs to be reconnected - A credential was rejected by the server's `headersHelper` (with guidance to check the helper and run `/mcp` to reconnect or authenticate) - A statically configured `Authorization` header was rejected - A generic prompt to re-authenticate **Why** More specific error messages help you fix the actual problem, for example checking a custom `headersHelper` versus simply running `/mcp` to reconnect, rather than getting the same vague re-authorization prompt regardless of cause. - Area: MCP - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Artifact tool prefetches stored-declaration data while reading Artifact tool now fetches the stored type declaration in parallel with content, for owner/writer reads **What** The internal artifact-read function gained a `storedDeclaration` parameter (on by default). When an owner or writer reads an entire artifact page (not a single file), the tool now starts fetching the stored type declaration at the same time as the main content, instead of waiting until afterward. **Why** Running both fetches concurrently is meant to hide the extra latency of the stored-declaration lookup for owner/writer reads of artifacts that have a declared type. - Area: Artifacts - Tier: Under the hood - Useful: 2/5 - Signal: 1/5 ### Artifact tool results now distinguish outside-organization writers from co-writers Artifact tool results now separately flag content written by someone outside your organization, distinct from co-writer content **What** When Claude Code reads or lists artifact files (`asset_list`, `asset_read`, `file_list`, `file_read`, `files_read`), the results already flagged content as "co-written" when another collaborator had contributed to it. There's now a separate `outside_writer` field, and when it's set, the tool result shows a distinct warning that content may have been written by someone outside your organization, rather than the generic co-writer message. **Why** This lets you tell apart edits from a trusted co-writer on the same artifact from edits by someone outside your organization entirely, which is useful context when deciding how much to trust content you didn't write yourself. - Area: Artifacts - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Remote Control (bridge) child sessions now inherit the --chrome flag Remote Control child sessions now inherit the --chrome flag for Claude in Chrome integration **What** When `claude remote-control` spawns child sessions, the spawn configuration now passes through a `chrome` field, wiring the CLI's `--chrome` flag (which enables Chrome browser integration for web automation and testing) into sessions spawned by the bridge. **Why** This lets Chrome browser integration carry over to sessions started through Remote Control, rather than only being available when starting a session directly from the CLI. - Area: Remote Control - Names: `--chrome` - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### New toast when MCP server reconnection is exhausted Claude Code now shows a persistent notification when an MCP server's automatic reconnection attempts run out **What** Claude Code connects to MCP servers (external tool providers that plug into Claude Code) and tries to reconnect automatically if a server disconnects. If those automatic reconnection attempts run out without success, a persistent notification now appears telling you to reconnect manually by running `/mcp`. The notification clears on its own once the server successfully connects again. **Why** Previously a server could sit disconnected without a clear signal that automatic retries had given up. This notification makes it obvious when manual action is needed, and points directly at `/mcp` to fix it. - Area: MCP - Names: `/mcp` - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Scheduled tasks/cron gains project scoping via createdInProject Scheduled tasks now also track which project they were created in, not just which session **What** Scheduled tasks (Claude Code's cron-like feature) now record a `createdInProject` field showing which project a task was created in. The scheduler compares this against the current project's path, in addition to the existing check based on which session or process created the task, when deciding whether a task 'belongs' to the current project for missed-task handling and firing. **Why** This makes it more reliable to tell whether a scheduled task is associated with the project you're currently in, rather than relying solely on which session created it. - Area: Elsewhere - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Bash commands too complex for AST analysis now get blocked outright under the read-block setting Bash commands too complicated to analyze are now blocked outright when reads are locked to the working directory **What** When the `permissions.blockReadsOutsideWorkingDirectories` setting is turned on (which makes Claude Code's file tools refuse reads outside the working directory), Bash commands that are too structurally complex for Claude Code to analyze are now refused outright with a hard "ask" prompt, unless a specific exemption applies. Previously, these overly complex commands fell through to the normal complexity-based approval flow instead. **Why** Commands too complex to analyze can't be reliably checked against the read-location block, so Claude Code now asks for explicit approval on them rather than risking one slipping through unchecked. - Area: Bash Safety - Names: `blockReadsOutsideWorkingDirectories` - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### New "isolation" managed-settings category tracked in the approval dialog The org-managed-settings approval dialog now tracks a new 'isolation' settings category **What** When an organization pushes managed settings changes that Claude Code prompts the user to approve, the approval system now tracks a dedicated `isolationSettings` bucket alongside the existing shell, environment, and sandbox settings buckets. It reads an `isolation` block containing `required` and `egress` keys, and the approval dialog shows an `elidedIsolationCount` count alongside the existing elided command and sandbox counts when there are too many changes to list individually. **Why** This lets organizations manage isolation-related settings (such as required isolation and network egress rules) through the same approval flow as other managed settings, so changes to them are surfaced to the user rather than applied silently. - Area: Sandbox - Names: `isolationSettings` - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Shell static-analysis tightened for declare/typeset/local operands Claude Code's shell command checker now catches trickier declare/typeset/local arguments **What** Claude Code has a step that decides whether a shell command is simple enough to run without fully re-parsing it the way a real shell would. That step now rejects `declare`, `typeset`, and `local` commands (used to declare shell variables) whenever their argument isn't a plain, simple variable name with a harmless value. Cases like array subscripts, expanded names, or compound assignments are now flagged as too complex to handle safely, and marked internally with a `differential: true` label. **Why** Those trickier argument forms can be interpreted differently by the real shell than by Claude Code's simplified check, so treating them as "too complex" avoids a command being approved based on a misunderstanding of what it actually does. - Area: Bash Safety - Names: `declare`, `typeset`, `local` - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### Bash permission checks: new fallback path when a classifier-based 'ask' isn't overridable Bash safety checks gained a subcommand-based fallback when an 'ask' decision from the classifier can't be overridden **What** When Claude Code's safety-check classifier decides a bash command should prompt you with 'ask' and that decision isn't one that can simply be approved by the classifier, Claude Code now runs an extra check on the decision's reason and, where applicable, tries a new fallback that looks at the command's individual subcommands before falling back to the original 'ask' decision. The separate logic for always asking about certain subcommands was also consolidated into one shared piece of code. **Why** This adds another layer of analysis before Claude Code settles on asking you for permission to run a bash command, aiming to make that decision more precise. - Area: Bash Safety - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### MCP prewait now distinguishes first command from later 'wakes' Claude Code now waits differently for MCP servers on the first command versus later ones in a session **What** Before running a command, Claude Code can wait for MCP servers (Model Context Protocol servers, which connect Claude to external tools and data) that are still starting up. This wait logic now behaves differently depending on timing: - On the very first command in a session, it uses the existing deadline and local-only settings. - On later commands (once a first command has already run), it can instead use a separate `mcpPrewait.laterWakes` configuration for its deadline and local-only behavior, with the deadline calculated differently depending on whether the session is "relay marked." **Why** Separating the first-command wait from later waits lets Claude Code tune how long it pauses for MCP servers at different points in a session, rather than applying one fixed wait everywhere. - Area: MCP - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### New safety-classifier interruption message text for tool calls New message tells the model not to repeat content stopped by a safety classifier, except for already-running tool calls **What** A new piece of text is shown when a response is stopped by a safety classifier (an automated system that flags unsafe content), explicitly telling the model not to reproduce that content. An exception is carved out for tool calls that were already running when the stop happened; those are instead marked as "Interrupted." **Why** This prevents the model from retrying or repeating content that was blocked for safety reasons, while still letting already-in-flight tool calls end cleanly rather than being treated as if they repeated the blocked content. - Area: Elsewhere - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### GitHub-app-not-installed error now prefers server-supplied message GitHub-app-missing error message now shows the server's own wording when available **What** When Claude Code reports that the Claude GitHub app isn't installed, it now checks for a message sent by the server (`serverMessage`) and shows that exact text first, only falling back to its generic built-in instructions if the server didn't provide one. **Why** This lets the server give more specific or up-to-date instructions for fixing a missing GitHub app installation, instead of users always seeing the same generic message. - Area: GitHub - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### Bash static analyzer: new 'differential' escape hatch for too-complex shell constructs Bash safety checker gets a new 'differential' fallback for complex shell syntax it can't fully parse **Unclear.** The finding doesn't say what practical difference the differential label makes to how the command is handled. **What** Claude Code's built-in checker for whether a bash command is safe to run now has a new escape hatch for certain complex constructs it flags as too complex to analyze fully, such as split-quoted variable declarations and tracking which variables get unset. Previously these cases were labeled with a fixed `declaration_command` type; now they can instead be marked `differential`, with some cases choosing between the two based on a new check. **Why** This changes how the safety checker categorizes shell constructs it can't confidently parse, which affects how those commands are handled rather than what commands are allowed. - Area: Bash Safety - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### New early bail-out for over-complex bash commands before prefix-rule matching Overly complex bash commands now skip permission-rule matching entirely instead of being reasoned about **What** Before Claude Code splits a bash command into subcommands to match it against permission rules, it now runs a new complexity-and-length check first. If the command trips this check, Claude Code stops and declines to reason about it further, rather than attempting to split and match it. **Why** This avoids Claude Code trying to apply permission logic to bash commands too complex to analyze reliably, likely reducing the chance of a permission rule being matched incorrectly against a convoluted command. - Area: Bash Safety - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Default spinner message changed to fall back to "Working" The loading spinner now shows "Working" when it has no other status message to display **What** The short status message Claude Code shows next to its spinner while it's processing now falls back to the plain word "Working" when no other message is available. Previously this fallback text was different. Also, the code no longer adds a trailing "..." to the message if the text already ends with one. **Why** This avoids showing an awkward or duplicated ellipsis ("...") after the status text, and gives a clearer default label when Claude Code has nothing more specific to say about what it's doing. - Area: UI - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### Design-system token card paths get a 'project/' prefix when applicable Design-system token card file paths can now be prefixed with 'project/' under certain conditions **What** When Claude Code reads a design system's token cards (files like `api/tokens.md` and `tokens.json`) for a file-backed artifact, it can now look for those files under a `project/` prefix, if the design system's own documentation lists a path matching a specific marker. **Why** This lets token-card lookups match design systems that organize their files under a `project/` folder, mirroring similar prefix handling already used elsewhere for card-reading. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Auto-memory loading now skipped when reads are fenced outside the working directory Auto-memory loading is now skipped when a permissions setting fences reads outside the working directory **What** Claude Code's auto-memory feature (which automatically loads memory files) now checks an additional condition before running. If a permissions setting blocks reads outside the current working directory, auto-memory loading is skipped entirely. A new telemetry field, `read_block_fenced`, is recorded when this happens. **Why** Auto-memory files can live outside the working directory, so this keeps that read-restriction setting from being silently bypassed by the auto-memory feature. - Area: Memory - Names: `blockReadsOutsideWorkingDirectories` - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### New AutoMem path-allowlist gate restricting which files can be scanned as pinned memory AutoMem file scanning now filters candidate files against an allowed-paths list before reading them **What** A new function filters the files AutoMem and AutoMemPinned would scan as pinned memory, keeping only those within the workspace root's allowed paths. This filter runs before file headers are scanned, and is used both when building the AutoMem index and when identifying pinned memory candidates. **Why** This prevents AutoMem from scanning memory files outside the paths it's permitted to read. - Area: Memory - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Feedback-prompt flow now short-circuits under HIPAA/ZDR feedback policy Feedback prompts now close immediately when an org's policy disallows product feedback **What** The interactive feedback prompt now checks the `allow_product_feedback` policy setting before doing anything beyond letting you dismiss it. If an organization's policy (such as under HIPAA or ZDR - zero data retention - requirements) has feedback turned off, the prompt closes right away instead of proceeding. **Why** This keeps the feedback flow from running in organizations whose data-handling policies don't permit collecting product feedback. - Area: Elsewhere - Names: `allow_product_feedback` - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### Bash differential-execution checker gains new too-complex guards for declare/typeset/local Bash safety checker now flags declare/typeset/local commands with complex operands as too complex to pre-check **What** Claude Code's bash command checker, which uses tree-sitter (a code-parsing tool) to decide whether a command is safe to run without extra confirmation, now bails out and marks commands as `too-complex` when they use `declare`, `typeset`, or `local` with operands that aren't a plain variable name and a fixed value. Such operands could be reinterpreted by the real shell as array subscripts, expanded variable names, or compound assignments, which the checker can't safely reason about. These new too-complex results also carry a `differential: true` marker not seen before. **Why** This avoids letting the checker mistakenly treat a `declare`/`typeset`/`local` command as safe when the shell might actually interpret it in a more complex, potentially unexpected way. - Area: Bash Safety - Names: `declare`, `typeset`, `local` - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Background memory extraction now skips when reads are locked to the working directory Background memory extraction now skips entirely when reads are locked to the working directory **What** Claude Code periodically runs a background pass that extracts things worth remembering into auto memory files. That pass now stops immediately, before doing any work, in two new cases: - auto memory is disabled, via the `CLAUDE_CODE_DISABLE_AUTO_MEMORY` environment variable or the `autoMemoryEnabled` setting - the `permissions.blockReadsOutsideWorkingDirectories` setting is turned on together with a sandboxed mode, which locks file reads to the working directory **Why** When reads are locked to the working directory, the background memory pass can no longer safely gather the information it needs, so Claude Code now skips it outright rather than running it in a restricted state. - Flag `tengu_passport_quail`: Off in both readings (read for one account on one subscription tier against v2.1.273; 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. - Area: Memory - Names: `blockReadsOutsideWorkingDirectories` - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### gh CLI failures now surface real stderr in autofix-PR errors Autofix-PR errors now show the actual gh CLI stderr text instead of a generic error **What** When the `gh pr view` command fails for a reason other than the command simply not being found (`ENOENT`), the error message Claude Code shows now includes the last 3 non-empty lines of `gh`'s actual error output (stderr), instead of just a generic error message. **Why** This gives whoever is debugging a failed autofix-PR attempt the real reason the `gh` command failed, rather than an unhelpful generic message. - Area: GitHub - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### Artifacts list default scope wording tightened for type-scoped listings Artifacts list tool now describes the default listing scope as owned, org-owned, and shared-with-you separately **What** The `list` tool's description of its default scope, when filtering artifacts by `type` or `type_url`, now spells out three categories instead of two: artifacts the user owns, artifacts their organization owns, and artifacts shared with them. Previously the wording lumped the latter two together as everything "shared across their organization." **Why** The change clarifies, in the tool's own documentation, that organization-owned artifacts and artifacts merely shared with the user are distinct categories, which affects how Claude reasons about what a default listing will include. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ## Bug Fixes ### New safety-classifier refusal recovery path (tengu_ochre_kite) Claude Code now recovers gracefully when a safety filter cuts off a response mid-tool-call **Unclear.** Whether this behavior is enabled for any accounts is unknown, since both related gates are unread. **What** When an assistant's response is stopped partway through by a safety classifier (an automated check that can halt a reply), Claude Code now detects this specific case, identified by a 'refusal' stop reason. For any tool calls that were left not run or were interrupted by the stop, it now generates proper error results explaining what happened: - A 'Not run' message for tool calls that never started - An 'Interrupted' message for tool calls that were cut off partway through After recording these results, Claude Code issues a retry nudge that notes a safeguard was triggered. **Why** Previously, an interrupted safety stop could leave tool calls in a confusing, undocumented state. This change makes the interruption visible and gives the conversation a clear path to retry instead of stalling. - Flag `tengu_ochre_kite`: Not enough to say (read for one account on one subscription tier against v2.1.273; this account: no value returned, anonymous baseline: no value returned, 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. - Area: Elsewhere - Tier: You'll notice - Useful: 2/5 - Signal: 2/5 ### Publish requests are now safely re-sent once if the response never arrives Publish requests are now automatically retried once if the server never responds **What** Claude Code now has a retry wrapper that automatically re-sends a publish request exactly once if the original request was interrupted and never got a response. The retried request is marked so the server can recognize it as a resend. **Why** This prevents a publish from silently failing, or being duplicated, when a network interruption cuts off the response to an already-successful publish. - Area: Artifacts - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### New 'publish is still settling' retry path for artifact deploys Artifact publishing now recognizes a "still settling" server state and retries instead of failing **Unclear.** Whether this behavior is enabled for any accounts is unknown, since the related gate `tengu_artifact_ask` is unread. **What** Claude Code now recognizes a new server response, `publish_settling`, which means the first publish attempt reached the server and its content is still being stored. Instead of treating this as a plain failure, the same retry mechanism re-sends the deploy request once, marked as a resend with an attempt ID. **Why** This avoids showing a failure to the user when an artifact publish actually succeeded but the server just hadn't finished storing it yet. - Area: Artifacts - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Read tool gains a device/inode identity check against writes (macOS) On macOS, the Read tool now checks a file's actual disk identity against files already held open by a write **What** When Claude reads a file, Claude Code now checks a per-session record of files already 'held' from an earlier write to that same path. On macOS specifically, it goes further and computes the file's real on-disk identity (its device and inode numbers, the operating system's way of uniquely identifying a file even if the path changes) for the resolved path and for a fallback path used when a file isn't found, and passes that identity along with the read. **Why** This guards against subtle mixups where a path read from disk isn't actually the same file that was just written, for example if something was moved, replaced, or symlinked in between, keeping Claude's view of a file's contents consistent with what it just wrote on macOS. - Area: File Tools - Tier: Under the hood - Useful: 2/5 - Signal: 1/5 ### Sub-agent/task token accounting now skips advisor and compaction iterations Task token-usage totals now skip advisor and compaction iterations when picking the latest usable one **What** The function that computes a sub-agent task's token usage, used for cost and usage display, now skips iterations of type `advisor_message` or `compaction` when looking for the most recent usable iteration to report on. If no valid message iteration is found, it falls back to the running totals instead. Numeric validation on each token field is also stricter than before. **Why** This avoids showing token counts drawn from an advisor message or a compaction step (where the model condenses conversation history) as if they were a normal turn's usage, keeping the reported token numbers more accurate. - Area: Subagents - Tier: Under the hood - Useful: 2/5 - Signal: 1/5 ### Better error messages for GitHub token import failures GitHub token import now shows more specific errors for network and invalid-token failures **What** When importing a GitHub token fails, Claude Code now surfaces more detail: - Network errors are classified, including a new hint for TLS-tunnel connection failures. - Invalid-token responses (HTTP 400) now parse and display the server's actual error message, shown as "`` Add the repo scope..." **Why** Users troubleshooting a failed token import now get a specific reason for the failure instead of a generic error, making it easier to fix. - Area: GitHub - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Proxy/network error messages made more specific Proxy and network error messages during GitHub setup are now more specific **What** Two error-message spots involved in GitHub setup now give more actionable text: a failed proxy tunnel connection (`ERR_PROXY_TUNNEL`) now explains that "the proxy refused the tunnel: check its credentials and that it allows this host," and generic network errors during GitHub token import now show a connection hint and/or which proxy environment variable is in effect. **Why** This helps users behind a proxy figure out whether a failure during GitHub setup is a proxy credential or configuration problem, rather than seeing an unexplained network error. - Area: Internals - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Webhook route now returns proper 405 instead of conflating bad method with not-found The webhook route for Claude Code's MCP server now returns a proper 405 'method not allowed' instead of a misleading 404 for wrong HTTP methods **What** Claude Code's Web Standard Streamable HTTP MCP (Model Context Protocol) server route handles incoming requests. Previously, if a request used the wrong HTTP method, it was treated the same as a request to a route that doesn't exist at all, both returning a 404 'not found' response. Now the handler checks whether the route and session are valid first, and if the only problem is the method (i.e. it isn't `POST`), it returns a proper 405 'method not allowed' response with an `Allow: POST` header. **Why** This gives callers a more accurate error: a 405 correctly signals that the route exists but the method is wrong, rather than implying the route itself is missing. - Area: MCP - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Differential-testing detector now flags glued subshell groups too Claude Code's bash/zsh compatibility checker now flags parentheses glued directly onto a preceding word as a shell-specific risk **What** Claude Code's detector for shell commands that might behave differently across bash and zsh has a new case: a `(...)` group that appears directly attached to the end of a preceding word or statement, on the same line. Bash rejects this kind of command outright, but zsh instead reads the glued parentheses as a glob-group word and expands whatever follows it. Previously, this specific pattern only triggered a generic 'statement follows statement' message. **Why** This gives a clearer, more specific warning for a command shape where bash and zsh genuinely diverge in behavior, instead of a generic catch-all message. - Area: Bash Safety - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Plugin sync list-fetch now retries once on failure instead of always erroring immediately Plugin marketplace sync now returns a structured error instead of crashing when a later page of results fails to load **What** When Claude Code syncs a plugin marketplace's list of plugins page by page, a failure on a later page (after at least one page already loaded successfully) is now handled differently: instead of letting the raw error propagate, it returns a structured result containing `success: false`, an `error`, and a `kind`. **Why** This lets the caller handle a partial list (some pages fetched, a later one failed) more gracefully instead of the whole sync failing with an unstructured error. - Area: Plugins - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Forking now requires the fork point to be durably recorded Forking a session now fails outright if the fork point can't be saved, instead of silently continuing **What** When Claude Code creates a forked or background session, it now treats writing the fork point (a marker recording where the fork branched off, along with the last prompt) as required, separate from the fork briefing text, which stays optional. If the required fork-point marker fails to write, forking now fails with an explicit error. Previously, a failed write here only logged a warning and the fork went ahead anyway. **Why** This stops a fork from silently proceeding without a properly recorded starting point, which could otherwise lead to a forked session that doesn't know exactly where it branched from. - Area: Sessions - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### New fork-failure notice posted into the forked session A forked remote session now posts a clear warning message if the fork couldn't start **What** When you fork a conversation (branch off a copy of it) in a remote-control session and the fork fails to start, Claude Code now posts a warning message directly into the new session saying: "This forked session could not be started. Fork the conversation again to retry." Underneath, the helper that uploads conversation history to a remote session now takes a telemetry-group name as a parameter instead of always logging under `rc_fork_conversation`, so the same code can also log under `rc_repl_fork_conversation`. **Why** Instead of a fork silently failing or leaving a confusing blank session, users now get a clear explanation and a concrete next step (retry the fork). - Area: Remote Control - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### New guard against scheduled tasks copied from another checkout Claude Code now detects and skips scheduled tasks copied in from another project checkout **What** Claude Code now checks each pending scheduled or cron task to see which session originally created it (other than the current session), and verifies whether a transcript file for that creator session still exists on disk. If a task's creator has no matching transcript, the task is excluded from the set this session will actually run, and a warning is logged noting that the `scheduled_tasks.json` file looks like it was copied from another checkout. **Why** This prevents Claude Code from trying to run scheduled tasks that don't actually belong to the current project checkout, for example after `scheduled_tasks.json` was copied along with files from a different clone of the repository, avoiding confusing or broken task runs. - Area: Elsewhere - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Background spawn / fork now supports resuming at a specific leaf message Forking a background session can now resume at a specific earlier message **What** The internal function used to spawn a background agent or fork a conversation now accepts a `resumeAtLeaf` option, letting it resume from a specific message rather than the latest one. If the conversation no longer actually contains that message as a valid fork point, it now returns a clear error: "Couldn't fork - the conversation no longer contains the fork point," instead of proceeding incorrectly. **Why** This lets background forks branch from a precise earlier point in a conversation, and fails clearly and safely if that point has since disappeared (for example, after history was pruned). - Area: Sessions - Tier: Under the hood - Useful: 2/5 - Signal: 1/5 ### Plugin-list and skill-list now also degrade gracefully on a 404 not-found error, not just 403/no_scope Plugin and skill listing now also degrade to an empty list on a 404 'not found' error, not just permission errors **What** When Claude Code fetches your list of plugins or skills and the request fails, it now falls back to showing an empty list (with a warning logged) instead of throwing an error in one more case: a 404 "not found" server response. Previously this graceful fallback only applied to 403 (forbidden) or "no scope" permission errors, and skill listing specifically only handled the 403 case. Both plugin and skill listing now share the same check, including the new 404 case. **Why** This prevents a 404 from a plugin or skill listing request from surfacing as a hard error, keeping Claude Code usable even when that endpoint can't find anything to return. - Area: Plugins - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Session usage totals now take the max of two token counts Session usage totals now use whichever of two token counts is higher **What** The total token count reported at the end of a run (shown in the run summary as `usage.total_tokens` / `usage.totalTokens`) is now calculated by comparing two separate token totals and taking the larger of the two, instead of relying on a single calculation. **Why** This should make the reported usage number more reliable when the two underlying counting methods disagree, since the higher figure is used rather than potentially undercounting. - Area: Usage - Names: `usage.total_tokens` - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### Bridge child now told about permission-mode changes, even before it's mounted Permission-mode changes are now buffered and delivered to the remote-control bridge even before it's connected **What** When the permission mode changes during a session, a new helper now forwards that change to the bridge child session (used for remote control / mirroring) via `noteModeChoice`. If the bridge child isn't mounted yet at the time of the change, the mode choice is now held onto and delivered once the bridge child does mount, instead of being lost. **Why** This prevents a permission-mode change from being silently dropped when it happens before a remote-control connection is fully set up, so remote sessions stay in sync with the actual permission mode. - Flag `tengu_bridge_child_auto_mode`: Not enough to say (read for one account on one subscription tier against v2.1.273; 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. - Area: Remote Control - Tier: Under the hood - Useful: 2/5 - Signal: 1/5 ### Headless plugin/MCP startup: first-command and first-turn mount joins now actually wait, instead of being no-ops Headless startup now actually waits for plugin/MCP mounts before the first command and first turn **What** Two points in headless session startup, `firstCommandMountJoin` and `turnMountJoin`, previously did nothing. They now, when a 'projects mount' is still pending, actually wait for it to finish via `joinProjectsMountBeforeFirstCommand`, bounded by timeout settings (`PROJECTS_MOUNT_FIRST_COMMAND_WAIT_MS` and a related floor value). `turnMountJoin` additionally waits for any pending 'grants' before letting the first turn proceed. **Why** This should prevent headless sessions from running commands or turns before required plugin/MCP project mounts and permission grants are actually ready, avoiding race conditions where a headless session acts before its environment is fully set up. - Area: Elsewhere - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### HTTP method handling tightened for a webhook-style MCP transport route A webhook-style connection route now replies 'method not allowed' instead of 'not found' for wrong HTTP methods **What** Claude Code has an internal route used to look up a live MCP (Model Context Protocol, the system that lets Claude use external tools) transport connection by secret and ID. If a request to a valid, known connection used the wrong HTTP method (anything other than `POST`), it used to get the same generic "not found" response as a request to a connection that doesn't exist at all. Now it gets a proper "method not allowed" response, with an `Allow: POST` header telling the caller what method it should have used. **Why** This makes it possible to tell the difference between "this connection doesn't exist" and "this connection exists but you called it the wrong way," which is clearer for anything talking to this route programmatically. - Area: MCP - Tier: You'll notice - Useful: 2/5 - Signal: 1/5 ### /update and /restart messages drop the artifact-comment-monitor special casing /update and /restart no longer mention artifact comment monitoring in their refusal messages **Unclear.** Nothing has been read yet about the `tengu_update_refused` or `tengu_update_bg_respawn` gates mentioned alongside this change. **What** When `/update` or a restart is refused, for example because the session was resumed from a different project directory or a background task is running, the message no longer checks whether an artifact 'comment monitor' task is active and no longer adjusts its wording for that case. The messages for transcript-path drift and for background tasks running are now fixed text, without the earlier note that restarting would stop auto-replies to artifact comments. **Why** The refusal messages are simpler and no longer vary based on whether artifact comment monitoring happens to be running, so the caveat about losing auto-replies to comments is no longer shown even if that monitoring is active. - Area: Elsewhere - Names: `/update` - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### Design system attachment no longer hardcoded to README.md Attaching a design system's documentation no longer assumes the file is named README.md **What** The tool that attaches a design system's documentation file to the conversation used to always assume that file was called `README.md`. It now reads and reports the actual file path instead. **Why** Design systems whose documentation lives in a differently-named file can now be attached correctly, instead of the tool assuming a fixed filename. - Area: Artifacts - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### Shell-safety analyzer: new differential detection for array-assignment-shaped flags Shell-safety checker now flags export/readonly commands whose flags look like an array assignment **What** Claude Code's bash safety checker, which decides whether a command is safe to run automatically, has a new rule: an `export` or `readonly` command whose operand's flags match an array-assignment pattern is now flagged as "too-complex," with the reason that bash would evaluate it as a compound array assignment. The existing similar check for `declare`, `typeset`, and `local` was refactored to share the same underlying pattern-matching logic. **Why** Commands that look like simple variable exports but that bash would actually interpret as array assignments behave differently than expected; flagging them as too complex avoids auto-running a command whose real effect isn't obvious. - Area: Bash Safety - Names: `export`, `readonly` - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### Shell-safety analyzer: new subshell and array-literal detectors Shell-safety checker gains new detectors for hidden subshells and array-literal syntax **What** Claude Code's bash safety checker gained two new internal helpers: - One recursively checks whether a command or variable assignment contains a nested subshell (a command run in its own sub-process, e.g. via parentheses). - Another walks a parsed command looking for `=(` array-literal syntax hidden inside words, regular expressions, or expansions, falling back to treating the command as unsafe by default if parsing fails or the input is too long. **Why** These detectors help the safety checker catch commands that use subshells or array-literal syntax to do something other than what they appear to on the surface, before deciding whether a command is safe to auto-run. - Area: Bash Safety - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### Unset with a plain-variable-name check made stricter, with an unrestricted differential fallback The `unset` shell command's safety check now accepts a second pattern and gives a clearer reason when it still refuses an operand **What** Claude Code checks shell commands before running them to catch ones that might behave differently between shells. The check for the `unset` command (used to remove a variable) used to only accept operands that looked like a plain variable name. It now also accepts a second, related pattern when a particular flag is set. If an operand still doesn't match either pattern, Claude Code no longer just rejects it outright. Instead it flags the command as too complex to safely analyze, with the explanation that 'the shell may expand or evaluate it'. **Why** This lets more legitimate `unset` operands pass the check while still catching and explaining, rather than silently rejecting, the cases where the shell might do something unexpected. - Area: Bash Safety - Names: `unset` - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### REPL bridge ignores fork display frames at ingress Claude Code's internal message bridge now ignores certain 'fork display frame' messages before processing them **Unclear.** What a 'fork display frame' is and what user-visible situation triggers one isn't stated; a related gate, `tengu_bridge_message_received`, hasn't been read for this site's account. **What** Claude Code has an internal bridge that receives messages for its interactive session (REPL). It now checks incoming messages early and, if a message is identified as a 'fork display frame', logs 'Ignoring fork display frame at ingress' and drops it immediately, before the usual de-duplication and telemetry logic runs. **Why** This stops a particular kind of internal display message from being processed as if it were a regular user message. - Area: REPL - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Artifact design-system README fetch failure handling refined Fetching a design-system README for Artifacts now treats a plain 404 as 'file not present' instead of a fetch failure, in one new mode **What** When Claude Code fetches a design-system guide README for use with Artifacts, it can now distinguish between a real fetch failure and a 404 response that carries no specific error code. When a new parameter is set and the response is such a plain 404, Claude Code now silently treats the document as simply absent, rather than reporting it as 'could not be fetched'. The function also now returns a `failed` field alongside the existing `why` field. **Why** This avoids surfacing a misleading failure message for what is really just a missing optional file, in the cases where that distinction applies. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Plugin-skill-search degrades gracefully on 404 not_found_error too Plugin skill search now handles a 404 'not_found_error' the same graceful way it already handled 403s **What** When Claude Code searches for plugin skills, a response of HTTP 404 with error type `not_found_error` is now treated the same as an HTTP 403: both cases degrade to an empty result and log an entitlement-denied event, instead of only the 403 case being handled that way before. **Why** This avoids surfacing an error to the user when the skill search endpoint reports either a permissions problem or a not-found condition, keeping the search degrading quietly in both cases. - Area: Plugins - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### TUI-switch refusal message drops the artifact-comment-monitor case The /tui refusal message no longer calls out artifact-comment auto-replies as a separate case from other background work **What** When `/tui` (which sets the terminal UI renderer and relaunches) is refused because background work is running, it used to give a distinct message and telemetry label when the background work was specifically an artifact-comment monitor auto-replying to comments. That distinction is now gone: any active background work is reported the same way, with a single generic message telling you to wait or stop it via `/tasks` before running `/tui` again. **Why** This simplifies the refusal handling to one consistent message, at the cost of no longer telling you specifically that a comment monitor was the thing blocking the switch. - Area: UI - Names: `/tui` - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### Token-usage accumulation in agent execution now validates usage shape before summing Token usage totals for an agent turn are now validated before being added up, to avoid bad data corrupting the count **What** When Claude Code tallies up token usage during an agent's turn, it now checks the shape of the usage data first: it requires `input_tokens` to be a number, and treats a missing or null `output_tokens` as 0. Only after this check does it sum input, cache-creation, cache-read, and output tokens, instead of summing the raw values directly. **Why** This guards against malformed or incomplete usage data silently corrupting token counts or causing errors, keeping usage totals reliable. - Area: Telemetry - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### upload_asset size-limit error now reports the actual file size upload_asset size-limit errors now include the actual file size in bytes **What** When the Artifact tool's `upload_asset` rejects a file for being too large, the error it throws now includes a `sizeBytes` field carrying the exact byte size of the file that was rejected, in addition to the existing error message. **Why** This gives more precise information about why an upload failed, useful for understanding exactly how far over the limit a file was rather than just seeing a generic size-limit message. - Area: Artifacts - Tier: You'll notice - Useful: 1/5 - Signal: 1/5 ### Skills sync now recognizes a 404/not-entitled response and treats it as a soft no-op instead of a failure Skills sync no longer treats a 404/not-entitled response from the server as a failure **What** Claude Code periodically syncs the list of available Skills (packaged instruction sets) in the background. If that sync now gets a 404 "not found" error indicating the account isn't entitled to the feature, it logs `skills_sync_list_refused`, treats the round as if zero skills were returned, and records the outcome as `not_entitled` instead of counting it as a failed sync round. **Why** Previously this kind of response would have been counted among consecutive failed sync rounds and triggered generic failure telemetry, even though it's an expected "not entitled" response rather than an actual error. This avoids noisy failure signals and repeated retries for accounts that simply don't have access to Skills syncing. - Area: Elsewhere - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Plugin sync now tolerates an entitlement-refused server list instead of failing the whole sync Plugin sync no longer fails entirely when the server refuses the plugin list for entitlement reasons **What** When Claude Code syncs your installed plugins, it asks the server for the current plugin list. If that request is refused because the account isn't entitled to it, the sync used to fail outright. Now it logs a warning, falls back to the plugin entries it already knew about, and reports a distinct `not_entitled` outcome instead of the old generic `list_failed` error. **Why** This keeps plugin sync usable even when entitlement checks block the server's plugin list, instead of breaking the whole sync process over a permissions issue. - Area: Plugins - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Scroll handler now also releases a hold indicator alongside disarming search Scrolling a viewport now also releases a hold indicator, not just dismisses search **Unclear.** The finding doesn't identify what the released "hold" indicator represents on screen. **What** Scrolling a viewport in Claude Code used to only disarm (turn off) an active search. It now also releases a separate "hold" indicator at the same time, and the app now watches that indicator so this happens reliably. **Why** This is an internal UI fix; the finding doesn't say which visible indicator this affects, so its user-facing effect isn't clear from the evidence. - Area: UI - Tier: You'll notice - Useful: 1/5 - Signal: 0/5 ### AWS error parsing now also reads details.error_code AWS server error parsing now also reads error codes nested under `details.error_code` **What** Claude Code's normalizer for AWS server errors now checks `details?.error_code` on the error response before falling back to the older `error_code`/`code` fields. This means error payloads that nest their error code inside a `details` object are now correctly recognized and mapped to a known server error code. **Why** This lets Claude Code correctly identify and handle a wider range of AWS error response shapes instead of missing the ones with a nested error code. - Area: Elsewhere - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Cowork file-read denial message now names the failed field generically The 'cannot read file' permission-denial message can now name a different failed field, not just file_path **What** The internal message shown when Claude is denied permission to read a file ("cannot read file ... the file could not be examined") used to always refer to a hardcoded `file_path` field. It now accepts a parameter name, defaulting to `file_path`, so the same message can be reused when a different parameter is the one that failed. **Why** This is a small internal cleanup that lets one deny-message helper serve tools or parameters other than `file_path`, rather than duplicating the message text for each one. - Area: Cowork - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### MCP tool-call auth-error telemetry no longer thrown as an exception A bug that could crash MCP auth-error logging with a stray exception has been fixed **What** When Claude Code logs telemetry for an MCP tool call that failed with a 401 authentication error, the logging call was accidentally wrapped in a `throw`, which meant it threw an undefined value instead of just recording the telemetry and letting normal error handling continue. That stray `throw` has been removed. **Why** This fixes a bug where recording an MCP authentication-error telemetry event could itself throw an unexpected error, potentially interfering with the normal handling of that error. - Area: MCP - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ## In Development ### Hearthbot bridge auto-allowed action list greatly expanded The hearthbot chat bridge can now auto-allow many more read-only actions without a permission prompt **What** The hearthbot bridge, which lets Claude operate in chat and project channels, can now auto-allow a much larger set of actions without asking for permission first: the list grew from about 11 entries to 25. New auto-allowed actions include: - `fetch_thread`, `fetch_project_timeline`, `fetch_messages` - `search_channels` - `list_thread_sessions`, `list_project_members`, `list_project_artifacts`, `list_project_prs` - `react`, `unreact` - `get_channel_session_id`, `get_project_session_id` - `read_memory` A new project-level mount path for the underlying MCP (Model Context Protocol, which lets Claude connect to external tools and data) server, and a new gating flag `tengu_webagent_mcp_bridge`, were also added. **Why** Auto-allowing read/fetch/list-style actions means Claude can look up threads, messages, and project details in chat without interrupting the conversation for a permission prompt each time. - Flag `tengu_webagent_mcp_bridge`: Off in both readings (read for one account on one subscription tier against v2.1.273; 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. - Area: Hearthbot - Tier: Nothing to try yet - Useful: 3/5 - Signal: 3/5 - Present in the build but not switched on ### New gated "headless hearth mount" (webagent MCP bridge) wired into headless session startup New gated 'headless hearth mount' wires a webagent MCP bridge into headless session startup **Unclear.** The `tengu_webagent_mcp_bridge` gate returned off for this site's account and for the anonymous baseline; no reading has been taken under this release yet, so its rollout status here is unknown. **What** Headless sessions (used for print mode or the SDK) can now, when a bridge SDK URL is present and parseable, set up something called a 'headless hearth mount' via `createHeadlessHearthMount`. It's wired up with storage, credentials, the session's bearer token, and configuration for reading the projects binding. This is controlled by a feature gate. **Why** This lays groundwork for connecting headless sessions to a webagent MCP bridge, though it isn't enabled for general use yet. - Flag `tengu_webagent_mcp_bridge`: Off in both readings (read for one account on one subscription tier against v2.1.273; 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. - Area: Remote Control - Tier: Nothing to try yet - Useful: 3/5 - Signal: 3/5 - Present in the build but not switched on ### Diff panel prototyped as a plugin pane The /diff panel is now prototyped internally as a plugin pane rather than built-in UI **Unclear.** Whether the `tengu_quiet_dolphin` gate that guards this plugin form of the diff panel is enabled has not been read for this release. **What** A new internal plugin now describes the `/diff` panel, the view showing changed files and their edited sections (hunks) beside the transcript, as a plugin-based pane that refreshes as Claude makes edits, rather than being wired in as fixed built-in UI. **Why** This is a structural change in how the `/diff` panel is implemented internally; it doesn't change what `/diff` shows you. - Area: UI - Names: `/diff` - Tier: Nothing to try yet - Useful: 2/5 - Signal: 3/5 - Present in the build but not switched on ### Cowork worker prompt gains guidance about non-HTML 'Cowork types' (slide decks etc), behind an unresolved gate Cowork worker prompt can now tell workers to check for existing 'Cowork types' before authoring plain HTML **Unclear.** Whether this guidance is switched on could not be traced; the condition controlling it is not resolved by the evidence. **What** When a session includes the Cowork publish tool, the prompt given to a delegated worker can now include extra guidance that things like slide decks, presentations, or visual designs are not just plain `.html` pages. In that case, the worker is instructed to first list the published Cowork types available and start from a matching type before falling back to authoring plain HTML. **Why** This steers delegated workers toward using purpose-built Cowork formats for things like presentations, instead of defaulting to generic HTML, when that guidance is in effect. - Area: Cowork - Tier: Nothing to try yet - Useful: 2/5 - Signal: 3/5 - Present in the build but not switched on ### Session external-event wake parsing added (parseExternalEventWake / isSessionInboxWake) New internal logic parses and detects session-inbox external-event wake messages **What** A new internal function detects and parses "session-inbox wake" events from a message string, using two new helpers, `parseExternalEventWake` and `isSessionInboxWake`, loaded on demand and gated behind an additional check. **Why** This is the underlying detection logic that powers the new dedicated display for external-event wake-up messages in the session transcript. - Area: Inbox - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 - Present in the build but not switched on ### CCR client gains a 'first flush' delay for streamed events CCR client can now delay the very first streamed event separately from later ones, via a new first-flush timing setting **Unclear.** Whether `tengu_ccr_stream_first_flush_ms` is enabled for any account is unread, so nothing can be said about whether this behavior is active. **What** The client responsible for uploading streamed events gained two new timing controls, `setStreamEventFlushIntervalMs` and `setStreamEventFirstFlushMs`. When a first-flush time is set, the very first part of a response (from the start of a content block through its first incremental update) can now be held and sent on its own faster schedule, separate from the regular flush interval used for the rest of the stream. **Why** This lets the very first piece of a streamed response be flushed sooner (or held with different timing) than the rest, independent of the normal batching interval. - Flag `tengu_ccr_stream_first_flush_ms`: Not enough to say (read for one account on one subscription tier against v2.1.273; this account: no value returned, anonymous baseline: no value returned, 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. - Area: Telemetry - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 - Present in the build but not switched on ### Duplicate 'waterfall' assistant/system messages pruned from transcript, gated by tengu_silly_waterfall A gated cleanup step now removes stray duplicate 'waterfall' messages from the conversation transcript **What** Claude Code can now strip out certain junk entries from the conversation transcript: a stray empty assistant message that appears right after a given point, and a message that is immediately followed only by system messages and matches a specific pattern. This is a new, more general cleanup step than the one covered before, and it only runs when a setting called `tengu_silly_waterfall` is turned on for the account. The flag was off for both this site's account and the general population, and no reading has been taken under this release yet. **Why** When enabled, this keeps the visible conversation history free of leftover or duplicated entries that don't belong, so the transcript reads cleanly. - Flag `tengu_silly_waterfall`: Off in both readings (read for one account on one subscription tier against v2.1.273; 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. - Area: Transcript - Tier: Nothing to try yet - Useful: 2/5 - Signal: 2/5 - Present in the build but not switched on ### AutoMem file scanning gated off in a new 'LU' mode and restricted by directory allow-list AutoMem file scanning now checks a new mode condition and restricts which files it can scan **Unclear.** The finding does not say what the new mode condition represents or when it evaluates to false. **What** AutoMem (Claude Code's automatic memory-file handling) now runs an extra condition check before scanning for pinned or automatic memory files, in addition to its existing checks. It also now filters candidate files against a computed list of allowed directories, so only files whose path falls under that allowed set can be scanned as memory headers. **Why** This narrows where AutoMem will look for memory files, reducing the chance it picks up files outside the intended locations. - Area: Memory - Tier: Nothing to try yet - Useful: 1/5 - Signal: 2/5 - Present in the build but not switched on ### Policy-limits verdict-changed emission now gated by Lft() Policy-limits change notifications can now be skipped under an experiment flag **Unclear.** Nothing has been read yet about whether `tengu_lovely_umbrella` is switched on for this account. **What** The function that emits a "verdict changed" event when policy limits change now checks a new condition first and, if it's true, returns early without emitting the event at all. This is controlled by an experiment flag called `tengu_lovely_umbrella`. **Why** This lets Anthropic suppress policy-limit-change notifications for some accounts via an experiment, without changing the underlying policy logic itself. - Area: Permissions - Tier: Under the hood - Useful: 1/5 - Signal: 2/5 - Present in the build but not switched on ## Internal Changes ### New per-child capability flags for Remote Control: artifact and machine-settings inheritance Remote Control child sessions gain two new optional capabilities: artifact behavior and inherited machine settings **Unclear.** Nothing has been read yet about whether `tengu_bridge_rc_child_artifact` or `tengu_bridge_child_machine_settings` are switched on for any account. **What** For sessions spawned as a 'project thread child' under Remote Control, two new capabilities can now be granted: - `artifact` behavior, controlled by a new check - inheriting machine-level settings, controlled by a separate new check Both are added alongside the existing auto-mode-default and auto-over-settings capabilities that this kind of child session could already be given. **Why** This gives Remote Control finer control over what a spawned child session can do and what settings it starts with, beyond just its permission mode. - Flag `tengu_bridge_rc_child_artifact`: Not enough to say (read for one account on one subscription tier against v2.1.273; 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. - Flag `tengu_bridge_child_machine_settings`: Not enough to say (read for one account on one subscription tier against v2.1.273; 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. - Area: Remote Control - Tier: Under the hood - Useful: 3/5 - Signal: 3/5 ### Bridge child sessions get a new CLAUDE_CODE_BRIDGE_CHILD_MACHINE_SETTINGS env var Bridge child sessions now get a new CLAUDE_CODE_BRIDGE_CHILD_MACHINE_SETTINGS environment variable **Unclear.** Whether this is enabled for any accounts is unknown, since the related gate `tengu_bridge_child_machine_settings` is unread. **What** When Claude Code's Remote Control feature spawns a bridge worker child process, it can now set a new environment variable, `CLAUDE_CODE_BRIDGE_CHILD_MACHINE_SETTINGS="1"`, alongside the existing bridge child environment variables. This is set when a new "machine settings" role flag is true for that child. Downstream, this variable is checked together with another condition to decide whether to suppress Claude-in-Chrome's automatic reconnect behavior for that child session. **Why** This lets a spawned bridge child session be marked to skip automatic browser reconnect behavior, which is useful when that child should not independently manage its own browser connection. - Flag `tengu_bridge_child_machine_settings`: Not enough to say (read for one account on one subscription tier against v2.1.273; 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. - Area: Remote Control - Names: `CLAUDE_CODE_BRIDGE_CHILD_MACHINE_SETTINGS` - Tier: Under the hood - Useful: 3/5 - Signal: 3/5 ### Bridge/remote-control child sessions default to auto-granting 'auto' permission mode A new grants module can auto-switch Remote Control child sessions into auto-approval permission mode **Unclear.** Whether this behavior is switched on for any account is unknown; nothing has been read yet about the `tengu_bridge_child_auto_mode` or `tengu_bridge_child_auto_over_settings` gates that control it. **What** Claude Code has a large new internal module for managing sessions started as children of a Remote Control 'bridge' connection (a remote-control link that can spawn sessions on your machine). This module can: - automatically switch a bridged child session's permission mode to `auto` (which skips normal approval prompts) - merge or undo a list of related environment facts for that session - mount a special `meta` MCP server (a helper tool server) for a bridged session This logic is checked from several new decision points when a bridge child session starts. **Why** This is plumbing for how Remote Control decides whether a session it spawns on your machine starts out able to act without asking for approval each time. - Flag `tengu_bridge_child_auto_mode`: Not enough to say (read for one account on one subscription tier against v2.1.273; 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. - Flag `tengu_bridge_child_auto_over_settings`: Not enough to say (read for one account on one subscription tier against v2.1.273; 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. - Area: Remote Control - Tier: Under the hood - Useful: 2/5 - Signal: 3/5 ### Metric attribution fields (agent/skill/plugin/mcp names) can be redacted before emission Attribution fields like agent, skill, plugin, and MCP names can now be redacted from emitted metrics **Unclear.** The `tengu_teal_corbel_newel` gate that allows unredacted emission read off for this site's account and off for the anonymous baseline, with no reading yet taken under this release. **What** Claude Code can now redact certain attribution fields before sending out metrics: `agent.name`, `skill.name`, `plugin.name`, `mcp_server.name`, and `mcp_tool.name`. The first time one of these values would differ from a shared baseline, it gets replaced with a common placeholder value instead, unless a setting allows the real, unredacted values to be sent. **Why** This limits how much identifying detail about which agents, skills, plugins, or MCP tools you use gets included in emitted metrics, when the corresponding setting isn't enabled. - Flag `tengu_teal_corbel_newel`: Off in both readings (read for one account on one subscription tier against v2.1.273; 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. - Area: Telemetry - Tier: Under the hood - Useful: 2/5 - Signal: 3/5 - Present in the build but not switched on ### Spinner tips reworked into a plugin architecture The spinner tip line shown while Claude works was rebuilt as an internal 'tips' plugin **Unclear.** Whether the `tengu_tips_mod` gate that guards this plugin is enabled has not been read for this release. **What** The short tip line that appears under the spinner while Claude is working has been rebuilt internally as its own plugin, called `tips`. It now has its own pipeline for picking a relevant tip once per turn, including tips sourced from an organization or from marketplace plugins, along with cooldowns and lifetime caps so the same tip doesn't repeat too often, and a priority order for choosing among candidates. The REPL (the interactive command loop) now defers to this plugin to pick the tip, instead of picking it directly itself. **Why** This is an internal restructuring of how tip text is chosen; nothing here says whether the tips shown to you will look or feel different day to day. - Area: UI - Tier: Under the hood - Useful: 2/5 - Signal: 3/5 ### Tool-execution hook context object substantially reworked The context object passed to tool-execution hooks was substantially reworked with many new fields **What** The context object handed to tool-execution hooks (code that runs around a tool call) was rebuilt. It no longer includes credentials, `isNonInteractiveSession`, `persistedToolResultFiles`, `artifactRead`, or `signal`. In their place it now carries a much larger set of fields, including `agentId`, `agentWorktree`, `taskRegistry`, `readFileState`, `getFileHistoryState`, `applyFileHistoryOp`, `sessionEnvVars`, `markPrResolvedThisSession`, `userTypedShellDispatch`, `emitToolProgress`, `shellPermission` (bundled with `abortController` and `toolUseId`), `mainLoopModel`, `effort`, `effortLayerOverride`, `unlayeredPermissions`, `abortController`, `remoteCall`, and `innerCall`. **Why** This substantially expands what internal hooks and tool-execution code can see and do around a tool call, covering things like agent identity, file-history tracking, and per-call permissions and effort settings, rather than the narrower context passed before. - Area: Hooks - Tier: Under the hood - Useful: 2/5 - Signal: 3/5 ### Interrupted-turn resume and parked-permission-hold behavior moved from env vars to a 'lane' config object Turn-resume and parked-permission behavior now comes from a 'lane' config object instead of direct env var reads **What** Several behaviors that were previously controlled by reading environment variables directly, resuming interrupted turns, holding unanswered 'parked' permissions, retiring parked stops, adopting underivable parked permissions, and tolerating context appends on resume, are now read from a single `lane` configuration object (`this.lane.resumeInterruptedTurn`, `this.lane.holdUnanswered`, `this.lane.parkedStopRetires`, `this.lane.retireUnanswered`, `this.lane.adoptUnderivable`) and a `toleratesContextAppends` value, instead of reading `CLAUDE_CODE_RESUME_INTERRUPTED_TURN`, `CLAUDE_CODE_HOLD_UNANSWERED_PARKED_PERMISSION`, `CLAUDE_CODE_RETIRE_UNANSWERED_PARKED_PERMISSION`, `CLAUDE_CODE_ADOPT_UNDERIVABLE_PARKED_PERMISSION`, `CLAUDE_CODE_PARKED_STOP_RETIRES`, and `CLAUDE_CODE_RESUME_TOLERATES_CONTEXT_APPENDS` inline each time. A single function now captures all of these env vars once into the `lane` object, which is what's checked at decision time. **Why** This consolidates a scattered set of environment-variable checks around resuming interrupted turns and parked permissions into one place, making that logic easier to reason about without changing what the individual settings control. - Area: Permissions - Tier: Under the hood - Useful: 2/5 - Signal: 3/5 ### New prompt-attachment extraction step inserted into user message pipeline A new step can extract prompt attachments and insert them as extra messages right after the first message **Unclear.** What triggers `extractPromptAttachments` to be set, and what kind of attachments this applies to, isn't stated. **What** When a new flag, `extractPromptAttachments`, is set on parsed input, Claude Code now runs an additional processing step that builds extra messages from the input and inserts them into the message list immediately after the first message. **Why** This adds a way for attachments carried in a prompt to be pulled out and turned into their own messages, when this flag is enabled. - Area: Agents - Tier: Under the hood - Useful: 2/5 - Signal: 3/5 ### Bridge child auto-mode gate flips its own default this release, and one caller gets swapped to a different, off-by-default flag Bridge child auto-mode logic re-plumbed to a new flag, while the old flag moves to a different caller and defaults on **What** The function that gates auto permission mode for bridge-spawned child sessions (sessions launched by the `claude` remote-control bridge) used to read the flag `tengu_bridge_child_auto_mode`, defaulting to off. It now reads a different flag, `tengu_shimmying_stardust`, still defaulting to off. Meanwhile, the original flag `tengu_bridge_child_auto_mode` is now read by a separate new function, but with its default raised from off to on. In effect, the specific behavior this function used to control is now governed by a new, separately-off flag, while the old flag has been repurposed elsewhere and now defaults to on. **Why** This re-routes which flag controls bridge child auto-mode behavior. No reading of either flag's current state on this site's account is available yet. - Flag `tengu_shimmying_stardust`: Off in both readings (read for one account on one subscription tier against v2.1.273; 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_bridge_child_auto_mode`: Not enough to say (read for one account on one subscription tier against v2.1.273; 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. - Area: Remote Control - Tier: Under the hood - Useful: 2/5 - Signal: 3/5 ### tengu_bridge_child_tool_diff now defaults on for bridge sessions Tool-call diffs are now sent for Remote Control bridge sessions, and always for remote ones **Unclear.** Nothing has been read yet about whether the `tengu_bridge_child_tool_diff` setting is switched on for any account. **What** A new check decides whether tool-call diffs (a summary of what a tool call changed) get included when a session is running as a Remote Control 'bridge' session. When the session's environment is a bridge session, this is now controlled by a setting; when the session is running via `CLAUDE_CODE_REMOTE`, the diffs are always sent regardless of that setting. **Why** This lets the client controlling a bridged or remote session see what a tool call actually changed. - Flag `tengu_bridge_child_tool_diff`: Not enough to say (read for one account on one subscription tier against v2.1.273; 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. - Area: Remote Control - Names: `CLAUDE_CODE_REMOTE` - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### New HTTP headers report tool-call durations and compaction state on bridge requests New HTTP headers report recent tool-call durations and compaction status on bridge requests **What** Claude Code now sends three new HTTP headers on some requests: `x-claude-code-compaction`, `x-claude-code-context-compacted`, and `x-claude-code-prev-tool-durations`. The last one carries a compact, size-limited list of recent tool names and how long each took to run. These headers are only attached when the connection is related to a Remote Control bridge session. **Why** This lets the server side of a bridge connection see timing and compaction (conversation-history trimming) information about the session without the client having to be asked for it separately. - Area: Remote Control - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### Artifact publish gains an 'outside writer' role alongside 'cowritten' Artifacts gain a new 'outside writer' role separate from 'cowritten' **Unclear.** The finding does not say how 'outside writer' differs in practical effect from 'cowritten', or what the new `stored` field is used for. **What** Artifacts (files Claude publishes as shareable outputs) now track a new concept called `outside_writer`, distinct from the existing `cowritten` status. It's computed from the artifact's permission role and other factors, and the data format for artifacts now also includes a `stored` field with `contract` and `capabilities` information. **Why** This distinguishes artifacts that someone outside the original author wrote to from ones that were jointly authored (cowritten), which is groundwork for more precise tracking of who contributed to a published artifact. - Area: Artifacts - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### Session naming now tracks how a name was set and can be set aside per-conversation Session names now record how they were set and can be temporarily set aside per conversation **Unclear.** The finding does not say what triggers a name being set aside or where the set-aside names are surfaced to the user. **What** When Claude Code registers a name for a session, it now also records whether that name was given at launch. A new capability lets the current registered name be set aside into a per-conversation list, capped at a fixed number of entries (the oldest one is dropped once the list is full), which clears the session's active name. **Why** This lays groundwork for switching a session between different names across a conversation without losing track of earlier ones, up to a limit. - Area: Sessions - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### New per-context token-budget rollover tracker with threshold telemetry Claude Code now tracks token-budget usage per conversation and logs when it crosses key thresholds **What** Claude Code now has a tracker that follows cumulative token usage separately for the main conversation and for subagents (helper conversations spun off from the main one). It supports "rolling over" unused budget and re-anchoring the tracker, and it logs an event each time the remaining budget crosses 75%, 50%, 25%, 10%, or 0% of the total, along with how many rollovers have happened and how long since the tracker was last anchored. **Why** This gives finer-grained visibility into how token budgets are consumed over a session, which can help identify when context is running low before it becomes a problem. - Area: Elsewhere - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### New marker-based transcript relay/hand-off refusal codes and checks for cross-version updates The mechanism that hands off a session transcript during /update now has more precise failure checks **What** Claude Code has an internal relay mechanism, using markers embedded in a transcript, that hands off session state (including prompt cache data) during an `/update`. It now has specific, named refusal reasons for when this hand-off can't proceed, such as a marker not being in an inactive state, a missing marker line, an unexpected marker line format, or an anchor point not being in view. It also now checks that a "thinking strip" isn't owed, and checks that the resuming session hasn't already answered a turn of its own before arming the relay. **Why** These added checks make the hand-off between old and new versions during an update more reliable, catching mismatched or stale states before they cause problems rather than after. - Area: Elsewhere - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### Remote-control/bridge process now initializes GrowthBook feature gates at startup The Remote Control bridge process now loads its feature-gate settings at startup **What** The background process that powers Remote Control (letting Claude Code be controlled from elsewhere) now initializes its GrowthBook feature gates as part of startup, running this in parallel with the rest of its startup work. If this initialization fails, it logs an error but keeps running, falling back to a cached copy of feature gates stored on disk. **Why** This ensures the bridge process has an up-to-date view of which features are enabled, while still working reliably (via the disk cache) if the feature-gate service can't be reached. - Area: Remote Control - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### Database reads can now flag 'outside_writer' in tool results Database read results now include an outside_writer flag alongside the existing foreign flag **What** When Claude Code reads from an artifact's shared database using the `read_db` action, the result now includes a new `outside_writer` true/false field, computed from a new check, in addition to the existing `foreign` flag that already detects when a document was authored by someone else. **Why** This gives Claude more specific information about database records, letting it tell apart documents genuinely owned and written by the current account from ones that also had a writer from outside, on top of the existing general foreign-document detection. - Area: Artifacts - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### Synthetic MCP-bridge tool context gains a runQuery function MCP-exposed tool context for Claude Code's own tools gains a runQuery function **Unclear.** What runQuery is actually used for and what capability it unlocks is not stated in the finding. **What** Claude Code can expose its own tools over an MCP connection (a protocol for connecting external tools and data sources to Claude). The isolated context built for that exposure now includes a `runQuery` function that wasn't there before, along with an alternate way of looking up tools that applies specifically when the connection uses HTTP as its transport. **Why** The finding doesn't say what capability this newly enables, but it suggests tools exposed over MCP via HTTP can now do more, such as running queries, than they could before. - Area: MCP - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### Artifact publish gains a reserved/pre-assigned slug path Publishing an artifact can now target a slug that was reserved ahead of time **What** The function that publishes an artifact now accepts a pre-reserved slug (the short identifier used in an artifact's URL), letting a publish attach to that slug specifically. Its telemetry also now records `is_redeploy`, `has_base_version`, and a `reserved` flag when this path is used. **Why** This supports publishing to a slug that was set aside in advance, such as for a redeploy of an existing artifact, rather than always generating a fresh one, and lets Anthropic track how often that happens. - Area: Artifacts - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### Published/served model catalog fetch logic reworked with richer telemetry (lane/route/resolution) Model catalog fetching was restructured with more detailed logging of lane, route and credential source **What** The logic that fetches Claude Code's published and served model catalogs (the lists of models offered to you) was restructured. The served-catalog path now tracks a 'lane' and a resolution result, and records route and credential information in its logs and telemetry. A new fetch reason called `lane_unavailable` is now handled explicitly by discarding a stale cached catalog entry. A background tab that isn't the primary one now explicitly resets its state instead of silently doing nothing. - New helper functions record whether a model catalog came from being 'served', a 'fallback', or 'published', along with its route, credentials, organization ID, and the reason for any fallback. **Why** This is mostly internal bookkeeping that gives Claude Code (and its developers) clearer visibility into why a given model list was shown and where it came from, rather than changing which models you see. - Area: Models - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### Agent-intent forwarding simplified; new 'contextOnly' and 'resumed' handling Agent-intent forwarding for queued commands simplified, adding explicit 'resumed' and 'contextOnly' handling **What** The internal logic that forwards agent intent for queued commands no longer checks a feature-enabled config or a separate owner check. Instead it now takes explicit `resumed` and `contextOnly` flags: when `contextOnly` is set, forwarded turns are relabeled with source `unattributed`. The `agent_intent_forward` telemetry event also gained a new `resumed` field. **Why** This simplifies how Claude Code decides whether to forward a queued command's intent, replacing indirect gating checks with explicit flags and adding clearer tracking of when a forwarded turn was a resume. - Area: Elsewhere - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### Auth-type detection now reports whether the API key came from an apiKeyHelper Auth-type detection now reports separately whether the active API key came from an `apiKeyHelper` command **What** The internal function that determines which authentication method is active now returns an object with both the auth type and a new `apiKeyFromHelper` flag, instead of just a plain auth-type string. A key sourced from an `apiKeyHelper` (a command you configure to generate an API credential) now counts as an API key being present, even if the key value it returns is empty or otherwise falsy. **Why** This lets Claude Code recognize an `apiKeyHelper`-sourced key as valid on its own terms, rather than checking it the same way as a directly-configured key value. - Area: Auth - Names: `apiKeyHelper` - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### MCP connector prewait/local-only logic reworked with relay marking MCP connector's wait/local-only logic reworked with a new relay-marked flag and deferred wake payload **Unclear.** What effect this has on observable connection behavior is not stated. **What** The internal logic that decides how long to wait and whether to treat an MCP (Model Context Protocol) server connection as local-only, for coordinator-mode connections, was restructured. It now uses a `relayMarked` flag and a `laterWakes` deferred-wake payload, replacing the previous single `waitRemoteServerNames` field. **Why** This is an internal restructuring of connection-timing logic for MCP servers in coordinator mode; the finding doesn't specify what user-visible behavior, if any, changes as a result. - Area: MCP - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### Bridge child sessions now default to computing tool-use diffs Bridge-hosted child sessions now default to computing a git diff for Write and Edit tool calls **Unclear.** Nothing has been read about whether `tengu_bridge_child_tool_diff` or `tengu_tool_use_diff_computed` is enabled for any account, so it's unclear whether this default is active for any given user. **What** When Claude Code runs as a child session inside a "bridge" host (indicated by the `CLAUDE_CODE_ENVIRONMENT_KIND` environment variable being set to `bridge`), it now defaults to computing a git diff for `Write` and `Edit` tool calls, so that the change can be reported back over the bridge. **Why** This lets a bridge-hosting application see what a file edit actually changed by default, rather than needing separate configuration to turn diff computation on. - Flag `tengu_bridge_child_tool_diff`: Not enough to say (read for one account on one subscription tier against v2.1.273; 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. - Area: Remote Control - Names: `CLAUDE_CODE_ENVIRONMENT_KIND` - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### SessionStart hook execution now receives an agentContext parameter SessionStart hooks now receive an extra agentContext parameter when they run **Unclear.** What information agentContext carries or what new capability it gives to SessionStart hooks is not stated. **What** A hook is a script you configure to run automatically at certain points in a session. The internal function that runs `SessionStart` hooks (which fire when a session begins or resumes) and loads plugin hooks now also accepts and passes along a new `agentContext` parameter, alongside existing options like credentials, the cancellation signal, and whether the session is orphaned. **Why** This gives the hook-running machinery more context about the agent it's running for, though the finding doesn't specify what new behavior this enables for hook authors. - Area: Hooks - Names: `SessionStart` - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### Session auto-naming rework: 'setAsideRegisteredName' and adoption counters Session auto-naming logic reworked to avoid races when multiple resume/restore operations happen at once **What** When Claude Code automatically names a session and the session's id changes mid-conversation, the logic that decides whether to adopt the new derived name has been reworked: - It now tracks an `adoptions` counter - It can set aside a previously-registered name and restore it later (`setAsideRegisteredName` / `restoreSetAsideName`) - It passes a new `givenAtLaunch` flag when registering a session name This is meant to prevent multiple concurrent resume/restore operations from overwriting each other's session name. **Why** Without this, running multiple resume or restore operations on overlapping sessions could cause the wrong auto-generated name to stick, or a session's intended name to get lost. - Area: Sessions - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### Bridge server-config gains an explicit 'drop auto mode environment' knob and user-configured tracking Bridge configuration can now explicitly drop the 'auto mode environment' setting, and tracks if you'd configured your own **Unclear.** What 'auto mode environment' configures in practice is still not explained by the evidence available. **What** When Claude Code applies configuration from a bridge server, it can now be told to explicitly strip out the `auto_mode_environment` setting from the incoming config via a new `dropAutoModeEnvironment` option. Separately, it now tracks and records whether you had already configured your own auto-mode environment before the bridge's config was applied. **Why** This prevents a bridge server's configuration from silently overriding an auto-mode environment setting you'd already chosen yourself, and gives visibility into how often that situation happens. - Area: Remote Control - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### New per-tool `hardBlockUnder` config drives a hard-block lookup table Tools can now declare a `hardBlockUnder` threshold list used to build a hard-block lookup table **Unclear.** What conditions or values `hardBlockUnder` actually enforces isn't given in the finding. **What** Each tool's configuration can now include a `hardBlockUnder` array of named thresholds. These are collected across all tools into a single lookup table that pairs each threshold with the tool it belongs to. A related table that decides which tools get denied on a cache miss was also simplified, now being built entirely from each tool's own configuration instead of starting from a fixed base list. **Why** This centralizes per-tool blocking rules into configuration rather than hardcoded lists, making it more consistent to determine when a tool should be hard-blocked or denied. - Area: Elsewhere - Names: `hardBlockUnder` - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### New auth-scope hashing helper for account/token identity New hashing helper computes an auth-identity 'scope' for accounts and tokens **Unclear.** The finding doesn't say what this scope value is used for or why part of the logic is currently disabled. **What** New internal functions compute a hashed 'scope' value that identifies the current login. For logins backed by a stored account (or the `CLAUDE_CODE_ACCOUNT_UUID` source), the scope combines the organization's UUID with a lowercased, hashed, and truncated account UUID. For logins based on an environment variable or file-descriptor auth source, the scope is a hash of the access token instead. A related companion function currently always returns `{scope: null, reason: "not_claude_ai_auth"}` because the code path that would compute something else is disabled (guarded by a permanently-false condition). **Why** This groups authentication identities into a consistent hashed form, likely for internal tracking or attribution, though the companion function's dead code means one code path currently never produces a real scope. - Area: Auth - Names: `CLAUDE_CODE_ACCOUNT_UUID` - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### REPL bridge child auto-revive/reconnect flow renamed/reworked; new onForkConversation control op Remote-control bridge session gains an onForkConversation control op, plus a reworked reconnect flow **What** The code handling the remote-control mirror session (the "bridge" that lets a remote session shadow a local one) was substantially reshuffled internally, mostly renaming variables from a rebuild. It also gained a new `onForkConversation` control operation: a remote bridge session can now request forking the conversation, using a snapshot of the messages, the current turn-activity state, and the length of any queued commands, and the resulting child bridge session is then recorded. **Why** This lets a remote-control session trigger a conversation fork remotely, extending what remote sessions can do to a locally-running Claude Code session. - Area: Remote Control - Names: `onForkConversation` - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### Agent resume can now forward owner interjections in 'live' vs 'snapshot' mode Resuming a background agent can now forward owner interjections live or as a snapshot **What** `resumeAgentBackground` now takes a `liveTranscript` parameter that chooses between 'live' and 'snapshot' delivery mode when forwarding owner interjections (messages queued in from the owning session) to a resumed background agent. Whichever mode is used, the resulting forwarded attachments (`copies`) are spliced into the resumed agent's prompt messages and recorded before delivery. **Why** This gives more control over how queued owner input is carried over when a background agent resumes, letting it be delivered either as an up-to-date live transcript or as a fixed snapshot. - Area: Subagents - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### Remote-bridge REPL sessions gain fork-conversation and pending-prompt-count hooks Remote-bridge REPL sessions gain hooks for forking a conversation and checking for pending prompts **Unclear.** What feature uses these hooks, and what effect they have for someone using Remote Control, isn't established by the evidence. **What** The session builder used for remote and headless REPL sessions (the Remote Control v2 transport handler) now passes two new items into each connection's configuration: an `onForkConversation` callback, and a `hasPendingPrompts()` function that reports whether there are prompts still waiting to be handled. These sit alongside the existing `onMcpSetServers`, `outboundOnly`, and `writeFrame` fields. **Why** The finding doesn't say what calls these new hooks or what user-facing feature they support, only that the plumbing for forking a conversation and checking pending-prompt state is now in place for remote sessions. - Area: Remote Control - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### New auth-error liveness classifier and proxy-usage telemetry helpers New helper classifies auth errors as dead, live, or unknown, plus telemetry for proxy usage **What** A new function classifies authentication or network errors into three states: `dead` (the credential is truly no longer valid), `live` (the error is likely transient), or `unknown`, based on error codes, HTTP status, and the outcome of OAuth token refresh attempts. A companion helper reports whether a proxy is being used and whether that proxy is a loopback (local machine) proxy. **Why** Distinguishing genuinely dead credentials from transient failures should let Claude Code avoid treating temporary network hiccups as a reason to force re-authentication. - Area: Auth - Tier: Under the hood - Useful: 2/5 - Signal: 2/5 ### New, separate gate for background-hint/auto-mode timing: tengu_shimmying_stardust Background-hint timing for sync subagents now uses its own separate, oddly-named gate **Unclear.** Nothing has been read yet about whether `tengu_shimmying_stardust` is switched on for any account. **What** A timing check that schedules background-hint timeouts for the synchronous subagent path (a helper task Claude runs alongside the main conversation) used to read the same setting as bridge child auto-mode. It now reads a completely separate, unusually named setting called `tengu_shimmying_stardust` instead. **Why** Splitting this into its own setting means background-hint timing and Remote Control's auto-mode behavior can now be turned on or off independently of each other. - Flag `tengu_shimmying_stardust`: Off in both readings (read for one account on one subscription tier against v2.1.273; 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_bridge_child_auto_mode`: Not enough to say (read for one account on one subscription tier against v2.1.273; 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. - Area: Remote Control - Tier: Under the hood - Useful: 1/5 - Signal: 2/5 ### New egress permission scope constant added A new 'egress' entry was added to an internal permission scope list **Unclear.** What this `["required", "egress"]` list is used for, and which feature or permission check it belongs to, is not shown by the evidence. **What** A new small list was added internally pairing the values `required` and `egress`. There's no surrounding context showing exactly where this list is used. **Why** This looks like it relates to network egress (outbound connection) permission scoping, but what it controls or when it takes effect isn't shown. - Area: Permissions - Tier: Under the hood - Useful: 1/5 - Signal: 2/5 ### New notification: experiment_gates sent over VSCode bridge Claude Code now sends experiment gate settings to the VS Code extension **What** A new function sends an `experiment_gates` message, carrying a set of experiment flags ("gates"), over the connection Claude Code uses to talk to its VS Code extension. If sending fails, it logs a warning rather than failing silently. **Why** This lets the VS Code extension know which experimental features are turned on for the session, keeping it in sync with the underlying Claude Code process. - Area: Elsewhere - Tier: Under the hood - Useful: 1/5 - Signal: 2/5 ### 'Teleport relay' fork-safety refinements: forkDirectLines and tools-baseline fingerprint The prompt-cache "teleport relay" path for forked sessions gains new bookkeeping to track fork safety **What** Claude Code has an internal "teleport relay" mechanism related to prompt caching (a way of reusing previously processed prompt content to save time and cost) that comes into play when a session is forked. New bookkeeping was added to it: - A boot-time check arms or disables the relay based on whether a cache marker is present, logging a message like "prompt-cache relay stays off: boot had no marker" and firing telemetry events `upgrade_teleport_cache` and `cli_teleport_arm_verdict`. - Tracking of which forked request lines went "direct" (bypassing the relay), so later requests on the same fork skip the relay too. - A comparison of a captured tools baseline's model and fingerprint, to determine whether a forked request's tool set is still "intact" or has "changed". **Why** These are internal safety checks that help Claude Code decide when it's safe to reuse cached prompt state across a forked session versus when the tools or setup have changed enough that it needs to start fresh. - Area: Sessions - Tier: Under the hood - Useful: 1/5 - Signal: 2/5 ### New availability checks for internal 'diff' and 'tips' modules New internal checks gate the 'diff' and 'tips' plugin modules behind readiness and enablement conditions **Unclear.** What the 'diff' and 'tips' modules actually do for the user isn't stated in the finding. **What** Two new internal helper functions each decide whether a plugin-style feature is available before it runs. One covers a module called 'diff', the other a module called 'tips'. Each check requires that the session isn't remote, that the module itself reports it's ready (`isAvailable()`), that a second internal readiness check passes, and that the module is listed among the currently enabled plugins. **Why** This is internal plumbing that ensures these two features only activate when all their prerequisites are actually met, reducing the chance of them running in a broken or unsupported state. - Area: UI - Tier: Under the hood - Useful: 1/5 - Signal: 2/5 ### Artifact publish flow adds a bypass path around the 'copy source unverified' approval check Publishing copied artifact files can now skip the unverified-copy-source approval check under certain conditions **Unclear.** What specifically triggers the bypass condition, and how it differs from the existing approval check, isn't established by the evidence. **What** When publishing files that were copied from another artifact, Claude Code normally requires prior approval to read the copy source, and otherwise throws a `copy_source_unverified` error and records a `copies_unpinned` telemetry event. There is now an additional condition, checked with a permission function called with `copySource: true` and action `ask`, that when true skips both the error and the telemetry event. **Why** The finding doesn't say what triggers this bypass condition in practice, so it's unclear when publishing will now proceed without the usual unverified-copy-source check. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 2/5 ### OTLP metric datapoints are now aggregated by attribute set OTLP metric exports now merge datapoints that share the same attributes instead of sending one row each **What** When Claude Code exports metrics using OTLP (OpenTelemetry Protocol, a standard format for sending metrics to monitoring systems), datapoints that share the same set of attributes are now grouped together and their numeric values summed into a single row, using the most recent timestamp among them. Previously, each raw datapoint was emitted as its own separate row. **Why** This reduces the number of redundant rows sent to monitoring systems and gives a cleaner, aggregated view of metrics that share the same attributes. - Area: Telemetry - Tier: Under the hood - Useful: 2/5 - Signal: 1/5 ### New per-request headers naming the caller's agent type and request class API requests now carry two new headers identifying the request's class and the calling agent type **What** Requests the CLI sends to Anthropic's API now include two additional headers: `x-claude-code-request-class` and `x-claude-code-agent-type`. Both are computed by helper functions that classify the request, for example as `compaction`, `workflow`, `teammate`, or `custom`, and are added to the default headers sent with every model call. **Why** This lets requests be tagged with what kind of request they are and what kind of agent made them, which is metadata rather than something that changes what a user sees. - Area: Internals - Tier: Under the hood - Useful: 2/5 - Signal: 1/5 ### api_key_helper now routed through model-catalog policy check api_key_helper auth method now checked against the same model-catalog policy as before **What** A new case for `api_key_helper` (a way of authenticating using a custom script that supplies an API key) was added to the logic that decides whether the model catalog is reachable. It now goes through the same `allow_model_catalog` policy check that previously only applied to the `not_claude_ai_auth` case. The case for having no authentication method configured also gained specific handling for served-catalog behavior when using an API key. **Why** This extends the existing model-catalog access policy, which lets organizations in HIPAA compliance mode restrict catalog access, to also cover accounts authenticating through a custom API key helper script. - Area: Models - Names: `api_key_helper` - Tier: Under the hood - Useful: 2/5 - Signal: 1/5 ### Sandbox/isolation settings tracking extended to a new 'isolationSettings' bucket Sandbox settings tracking gains a new separate 'isolationSettings' category **What** Claude Code's internal tracking of sandbox (isolated execution environment) settings now includes a new category called `isolationSettings`, tracked alongside the existing shell settings, environment variables, and sandbox settings. This produces a new `isolationRows` output and is factored into the counts of unchanged and removed settings. **Why** This separates isolation-related settings out from general sandbox settings for clearer tracking and display, likely as groundwork for showing isolation settings distinctly in configuration diffs or listings. - Area: Sandbox - Names: `isolationSettings` - Tier: Under the hood - Useful: 2/5 - Signal: 1/5 ### Connector-disable check now also consults a second source (e4) Whether claude.ai connectors are disabled is now checked against a second settings source too **What** The check that decides whether claude.ai connectors (MCP integrations fetched from claude.ai) are disabled previously looked at only one settings source. It now also checks a second, new source, and connectors are treated as disabled if either source sets `disableClaudeAiConnectors` to true. **Why** This closes a gap where a `disableClaudeAiConnectors` setting from the second source would have been ignored, so the connector-disable policy is now enforced more consistently. - Area: MCP - Names: `disableClaudeAiConnectors` - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Per-tool CPU accounting now split by phase via a dedicated file Claude Code now tracks CPU usage per phase for individual shell tool calls **What** Claude Code has a new helper that computes a file path used to track CPU usage broken down by phase for shell tool calls, skipping session IDs that look like sub-paths or start with "cc-". This is used to log a `tengu_tool_cpu_by_phase` telemetry event, and it fails gracefully with a fallback message if the tracking file can't be created. **Why** This gives more detailed CPU usage data for shell commands, broken down by phase, which can help diagnose performance issues in specific stages of command execution. - Area: Telemetry - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### New telemetry pair for artifact publish permission asks, caller not confirmed Claude Code now logs telemetry when it asks for, and receives, permission to publish an artifact **Unclear.** Whether this logging is enabled for any accounts is unknown, since both related gates are unread. **What** Claude Code now logs a `tengu_artifact_ask` event whenever it asks for permission to perform an artifact-publish-style action, and a `tengu_artifact_ask_granted` event when that permission is approved. The granted event also records how it was approved: by the user temporarily, by the user permanently, by a hook (an automated script that runs on certain events), by configuration, or by another method. **Why** This telemetry helps track how often artifact publishing requires explicit permission and how users typically respond, without changing what the user sees or has to do. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### New relayEligible field on fork-agent query telemetry Fork-agent query telemetry now records whether a query was eligible for the teleport relay **Unclear.** The finding does not say what the relay is used for beyond eligibility tracking, and no reading has been taken of any related gate yet. **What** The telemetry event `tengu_fork_agent_query`, which records performance and token usage for a forked (subagent) query, now includes a new `relayEligible` field. **Why** This gives Anthropic visibility into which forked-agent queries were eligible for a relay mechanism, helping them measure how a related feature is being used or rolled out. - Area: Subagents - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Artifact 'foreign document' detection now also checks for an outside writer Artifact database reads now also flag documents as foreign when an outside writer has touched them **What** When Claude Code reads an artifact's shared database, it checks whether the artifact is a "foreign" document, meaning someone other than your account wrote it. That check now also treats a document as foreign if your account is the owner but a new signal shows an "outside writer" has been involved, alongside the existing checks for documents co-written by others. **Why** This closes a gap where a document could look like it belongs entirely to you even though someone outside had written to it, so Claude Code can flag it appropriately. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Tool cancellation now reports which tools had already started running Cancelling a batch of tool calls now records which ones had already started running **What** When a batch of tool calls is cancelled partway through, Claude Code's internal accounting now also collects a list of `startedToolUseIds`, the IDs of tools that had actually begun running (whether they finished or were still in progress), alongside the existing counts of aborted, completed, and never-started tool calls. **Why** This gives Claude Code more precise bookkeeping about interrupted work, distinguishing tool calls that never got a chance to run from ones that were cut off mid-execution. - Area: Background Tasks - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Artifact type-instructions now describe files under project/ with createdOnFiles/filesInBrief Artifact instructions now describe adding files under a project/ folder instead of a publish/store-document flow **What** When Claude creates an artifact of a type that expects a certain manifest structure, the automatic instructions appended after the type's own instructions have changed. They now tell Claude to add the new content as files under a `project/` folder (referencing a `createdOnFiles` object and a brief file summary) in a single publish step, rather than the previous text about reading and publishing files and following store-document steps that only sometimes applied. **Why** This simplifies and clarifies how Claude is told to add files to certain artifact types, replacing conditional, more roundabout guidance with a single clear file-placement convention. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Session startup computes a relay-admission flag from transcript persistence and shared backend Session startup now computes a relay-admission flag from transcript persistence and backend sharing **Unclear.** What effect being admitted to or excluded from the relay has on the session is not stated in the finding. **What** When a session starts, Claude Code now builds an admission object that records whether the teleport relay is configured, whether the session keeps a persistent transcript (a saved record of the conversation), and whether it uses a shared backend. This is passed into the session's transport setup alongside the existing worker-relay admission data. **Why** This lets the session's setup account for relay eligibility from the very start, based on how the session is configured to store and share its data, though the finding doesn't specify what using or not using the relay changes for the user. - Area: Sessions - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Resume-interrupted-turn logic can now be overridden per call The internal resume-interrupted-turn check can now be overridden per call instead of always reading an env var **What** The internal function that reads and processes messages when resuming an interrupted conversation turn now accepts an extra override value. Previously it always checked the `CLAUDE_CODE_RESUME_INTERRUPTED_TURN` environment variable directly; now a caller can pass in a value that takes precedence over that environment variable for that particular call. **Why** This is plumbing that gives other parts of Claude Code finer control over resume behavior on a per-call basis, rather than being locked to one global environment setting. - Area: Sessions - Names: `CLAUDE_CODE_RESUME_INTERRUPTED_TURN` - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Model-picker list building drops a 'flag'-sourced model-merge branch Model picker no longer merges in extra models just because the catalog source was 'flag' **What** The code that builds the list of models shown in the model picker used to pull in extra models whenever the active model catalog's source was specifically `flag`. That branch has been removed. Now the fallback, built-in model list is only added when there is no resolved catalog at all, regardless of what source the catalog came from. **Why** This narrows when Claude Code falls back to its built-in model list, tying it only to a missing catalog rather than to how the catalog was sourced. - Area: Models - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Collection document reads now carry 'outside_writer' awareness Reading a collection document now also passes along whether its writer is outside your organization **Unclear.** It isn't clear what visible effect this has for the reader, beyond passing the extra flag internally. **What** When Claude Code reads a document that lives inside a collection, the internal code that formats ownership information now also passes along whether the document's writer is from outside the user's organization, in addition to the existing check for whether the document itself is "foreign." **Why** This is an internal formatting change; the finding doesn't show what, if anything, becomes visible to a user as a result. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Artifact metadata gains an outsideWriter flag Artifact metadata now includes an `outsideWriter` flag and an `outsideOrg` flag alongside existing ownership fields **What** Metadata for Artifacts (and similar shared pages) now includes an `outsideWriter` field, computed by a new check, alongside the existing `cowritten` field. Telemetry for grant-related events now also records `outside_writer: true` when that same check is true. Separately, the metadata computation now also derives an `outsideOrg` flag, which is folded into the existing determination of whether something counts as 'foreign' content, alongside factors like `authoredByOthers`, non-owner role, `cowritten`, and `typeLocked`. **Why** These additions let Claude Code more precisely track and report when an artifact was written or is owned by someone outside the expected writer or organization, which feeds into how it treats and labels that content. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### New guidance text on learning connector-tool schemas before publishing New model guidance tells Claude to learn connector tool argument and result shapes carefully before publishing a page that uses them **What** A new block of instructions was added guiding the model on how to handle connector tools (external tools reached through a connection, like a document or database integration) when publishing an Artifact or Claude Doc-style page. The guidance says to: - Take argument names directly from a loaded connector tool's own input schema, rather than guessing them - Learn a tool's result shape only from a safe, real call, never from a write action, since 'you should never run a write only to learn its result' - Use `describeTool(server, tool)` to read a tool's schema at viewer time when the current session can't see it directly - Tell the user, rather than embedding it silently in the page, whenever a tool's shape had to be guessed **Why** This reduces the risk of a published page silently guessing at how a connector tool works, and makes sure the user is told when Claude wasn't able to verify a tool's actual inputs or outputs. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Artifact comment tool description now points to Claude Doc's own connector tools Artifact comment tool now tells Claude to use a Claude Doc's own connector tools for leaving comments on it **What** The description Claude Code shows itself for the artifact-comments tool (used to add comments to an Artifact) now includes a new instruction: when the Artifact tool identifies a page as a Claude Doc, new comments should be left through that document's own connector tools instead, and Claude should search the available tools to find them. **Why** This routes commenting on Claude Docs through the document's native tooling rather than the generic artifact-comments mechanism, so comments end up in the right place for that document type. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Unverified-tool-call warning now checks argument schema, not just call history Warning about calling untested connector tools from an Artifact page now tells Claude to check the tool's argument schema too **What** When an Artifact page calls a connector tool that hasn't had a successful call observed during the current session, Claude Code shows a warning about that. The warning message now adds a new instruction: check the page's argument names against each tool's input schema, if the session has access to that tool, and treat the result fields the page reads as unverified unless a real, safe call can confirm them. **Why** This gives Claude a concrete way to partially verify an untested tool call, by checking argument names against the schema, rather than treating every unverified call the same way. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Task/agent liveness check gains new exclusions Claude Code's check for whether a running task counts as 'live' now excludes more cases, including certain in-process teammate tasks **What** Claude Code has an internal function that decides whether a running or pending task should still be treated as 'live' (active). It now also treats a task as not-live when a new condition is true, and specifically for tasks of type `in_process_teammate` where `evictAfter` is `0`, there's no `currentWorkAbortController`, and another new condition holds. The handling of the 'ambient'/`monitor_ws` case was also simplified to always report not-live, instead of delegating that decision elsewhere. **Why** This tightens up which tasks Claude Code considers still active, which affects things like whether a task shows as running or gets treated as finished/evicted. - Area: Background Tasks - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### New spinner-tip 'seat/vacate' handoff object on TurnController Session spinner tips now use a shared 'seat/vacate' handoff object instead of setting state directly **Unclear.** The finding does not say what problem this restructuring fixes or enables for the user. **What** The internal component that tracks a session's turn (`TurnController`) now manages the small status message shown next to the loading spinner (the "spinner tip") through a dedicated handoff object holding its context, display content, and version info. This object is "seated" into and "vacated" from a shared registry, replacing the previous approach of setting the spinner tip's app state directly. **Why** This is an internal restructuring of how the spinner tip's state is coordinated; it does not change what a reader sees, but it changes how that display is managed under the hood. - Area: UI - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Command/link listing drops curated/hidden/listed flags, adds audience Command and link listings drop curated/hidden/listed fields in favor of a new per-item audience field **Unclear.** What the audience field's possible values are or where its output is displayed is not stated. **What** Two internal functions that format lists of commands and links no longer include `curated`, `hidden`, or per-item `listed` fields in their output. Instead, they now include a per-item `audience` field when one is present. **Why** This changes the shape of the data these listing functions produce, replacing several separate flags with a single `audience` field, though the finding doesn't specify what values `audience` can take or how it's used downstream. - Area: Elsewhere - Names: `audience` - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Artifact publish telemetry now flags redeploys and base-version presence Artifact publish telemetry now records whether a publish was a redeploy and whether it had a base version **What** The `artifact_publish` telemetry event now includes two new fields: `is_redeploy`, indicating whether the publish was a redeploy of an existing artifact, and `has_base_version`, indicating whether a base version was present. **Why** This is internal telemetry that gives more detail about artifact publish events; it doesn't change publish behavior itself. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### New 'outside_writer' / outsideWriter attribution field across artifact schemas New 'outside_writer' field marks artifact and asset content as authored by someone outside the org **What** Artifact and asset save/fetch data now carries a new boolean field, `outside_writer` (called `outsideWriter`/`outsideOrg` in the JavaScript-side code), alongside the existing `cowritten`, `foreign`, and `authoredByOthers` fields. It is now checked as an additional condition when deciding whether to treat content as authored by someone else. **Why** This adds a more specific signal, distinguishing content written by someone outside the user's organization, that feeds into existing checks for content authored by other people. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### New artifact field outsideOrg complements outsideWriter Artifacts now carry an outsideOrg flag alongside the existing outsideWriter/foreign fields **Unclear.** The finding shows the field exists but not what behavior it drives. **What** Artifact metadata (the details Claude Code tracks about a generated artifact, like a document or file) now includes a new `outsideOrg` flag, returned alongside the existing `foreign` and `typeLocked` fields. **Why** This gives Claude Code another signal to distinguish artifacts that belong to a different organization from ones that are simply foreign or type-locked, though the finding doesn't say how this flag is used yet. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### servedCatalogNotPermitted boolean replaced with richer servedCatalogRefusal object Model-catalog refusal state changed from a plain flag to a richer object **What** The internal state tracking whether the model catalog was refused changed from a simple `servedCatalogNotPermitted` true/false flag to a `servedCatalogRefusal` value that can hold more information. The related check for whether the catalog is currently active was simplified to use a plain internal call instead of passing along a source value. **Why** This is an internal change to how Claude Code tracks and checks model-catalog refusals; it doesn't change what users see, but it lets the refusal state carry more detail than a plain yes/no. - Area: Models - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### firstParty catalog check no longer requires matching release Model-catalog readiness check no longer requires the release to match **Unclear.** The finding doesn't say why the release-matching requirement was removed or what effect this has in practice. **What** A check for whether the model catalog is from Anthropic itself ("first party") used to also require that the catalog's release matched a specific expected release. That release-matching requirement was removed, so now only the first-party flag is checked. **Why** This loosens the readiness check for the first-party model catalog, meaning it can now be considered ready without also matching a specific release, though the finding doesn't say what problem this fixes. - Area: Models - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### hostCarrier check special-cases webagent and claude-code-remote carriers Carrier eligibility check now special-cases webagent and claude-code-remote carriers **What** A function that checks whether a "carrier" (an internal identifier for how a session is running) is eligible now handles `webagent` and `claude-code-remote` carriers as a special case: for these two, it only returns true if the carrier matches exactly, before falling back to the general set-based check used for other carriers. **Why** This makes the eligibility check stricter and more precise for webagent and claude-code-remote sessions specifically, avoiding them being matched by the more permissive general logic. - Area: Sessions - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Model-selector unserved-spelling telemetry distinguishes family vs persisted spelling Startup telemetry now distinguishes an unserved model family spelling from an unserved persisted spelling **What** The `startup_resolve_model` telemetry, which previously always recorded `family_spelling_unserved` when a model name couldn't be resolved but a raw request was present, now checks an additional condition and instead records `persisted_spelling_unserved` in that case. **Why** This gives a more precise signal about why a model name failed to resolve at startup: whether it was an unserved model-family spelling or an unserved previously-saved spelling. It does not change what users see. - Area: Models - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### New telemetry event names added/removed Several new internal telemetry event names added; the old model_catalog_flag_rows event removed **Unclear.** What specific behaviors these new telemetry events measure is not stated beyond their names. **What** The list of recognized telemetry event names gained several new entries: `upgrade_relay_fork_direct`, `refusal_same_model_retry`, `rc_repl_fork_conversation`, `mcp_serve_file_call`, and `publish_settling`. The `model_catalog_flag_rows` event was removed. **Why** These are internal telemetry changes with no direct user-facing effect, though the new names hint at tracking for things like relay-based upgrades, same-model refusal retries, REPL conversation forking, MCP file-serving calls, and publish settling. - Area: Telemetry - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### wpn model-resolution helper drops an early-return guard Standard default model resolution no longer short-circuits under a certain guard condition **Unclear.** What condition the removed guard checked for, and which users or scenarios it applied to, is not stated. **What** The internal function that determines the standard default model kind used to return early with no model (`null`) when a particular guard condition held. That early return has been removed, so the function now always falls through to the standard-model branch when there's no recognized organization default. **Why** This means a case that previously resulted in no standard model being selected will now fall through to picking the standard default model instead, when there's no recognized org-level default. - Area: Models - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Artifact capability-declaration read-back and rendering Artifacts now read back their stored capability declaration and show it to the model after publishing **What** After an artifact is published, Claude Code now reads back its stored declaration — the contract and capabilities the artifact service holds for it — and inserts it into the prompt in a labeled block, worded like "Stored for the live version, as the artifact service holds it: contract ... capabilities ...". Capability names are sanitized and escaped before being shown to the model, so they're treated as plain data rather than instructions. **Why** This lets the model see exactly what capabilities and contract are actually recorded for the live version of an artifact, rather than relying on what it assumed it had set. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Bridge session spawn: session-tag prefetch broadened to more triggers More conditions now trigger a session-tag prefetch before spawning a Remote Control bridge worker **What** Before spawning a bridge worker for a Remote Control session, Claude Code decides whether to first fetch the session's tags. This decision now checks a wider set of conditions than before: whether spawning is enabled, whether a positive idle-exit timeout is configured (via `tengu_bridge_rc_child_idle_exit_ms`, and only when not in single-session spawn mode), whether restart-resume is enabled (via `tengu_bridge_rc_child_restart_resume`), or whether an auto-mode environment is configured. Previously this used a narrower, inline check. **Why** Broadening the check means the session-tag prefetch happens whenever any of these bridge features that depend on it are active, rather than only in the one case the old inline check covered. - Flag `tengu_bridge_rc_child_restart_resume`: Not enough to say (read for one account on one subscription tier against v2.1.273; 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. - Area: Remote Control - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Dropped auto-mode-environment now records a reason when tags are missing/unread Dropping a bridge child's inherited auto-mode environment now records why, instead of a plain yes/no **What** When a bridge-spawned child session would normally inherit the user's configured Auto mode environment but isn't tagged as a project-thread child, Claude Code now records a specific reason for dropping it: `session_tags_unread` if fetching the session's tags itself failed, or `session_untagged` if the tags were fetched but the session simply wasn't tagged. This reason is passed along as `dropAutoModeEnvironment` to the child spawn call, replacing what used to be a plain true/false value. **Why** Recording the specific reason makes it possible to tell, when a bridge child unexpectedly doesn't inherit its auto-mode environment, whether that was because the tag lookup failed or because the session genuinely wasn't tagged. - Area: Remote Control - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Dangerous-rm check gains a pluggable extra-deny hook The dangerous-rm safety check for bash commands can now be extended with an extra custom check **What** The function that screens bash commands for dangerous `rm`/`rmdir` patterns (like recursive deletes) now accepts an extra callback function as a parameter. This callback runs early, and if it returns a denial, that denial is used immediately. **Why** This makes the dangerous-`rm` check pluggable, allowing additional deny rules to be layered in without changing the core check itself. - Area: Bash Safety - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Auto-memory extraction gains an extra bail condition Automatic memory extraction now has an extra condition that can skip it **Unclear.** What real-world condition the new check (a combination of two internal helpers) actually detects is not stated. **What** Before Claude Code automatically extracts information to remember from a conversation, it now checks one more condition (a combination of two existing internal checks) in addition to the existing `tengu_passport_quail` setting and the prior auto-memory-disable check. If this new condition is true, memory extraction is skipped. The `tengu_passport_quail` setting was off for both this site's account and the general population, and no reading has been taken under this release yet. **Why** This adds another situation in which Claude Code will avoid running automatic memory extraction, though the finding doesn't specify exactly what that situation is. - Flag `tengu_passport_quail`: Off in both readings (read for one account on one subscription tier against v2.1.273; 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. - Area: Memory - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### History-upload telemetry event name generalized for reuse beyond forking History-upload telemetry can now log under different event names, not just fork_conversation **What** The internal helper that uploads a session's transcript history to a remote session, and reports telemetry when events get dropped in the process, used to always log under the fixed name `rc_fork_conversation`. It now takes the event name and a caller-supplied label as parameters instead, so different callers can report under different names. **Why** This lets other features besides conversation forking reuse the same history-upload code while still getting accurate, correctly-labeled telemetry. - Area: Remote Control - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### relayAwaitsHandoff flag threaded through resume/fork startup and teleport-boot telemetry A new relayAwaitsHandoff signal is now tracked through session resume/fork startup **Unclear.** What relayAwaitsHandoff represents and what behavior change it produces beyond the telemetry annotation is not stated. **What** A new value called `relayAwaitsHandoff` is now passed into the configuration used when a session starts up during resume or fork, and it's used to annotate a teleport-boot telemetry event (recording when a "teleport boot" doesn't get reached) as well as a check for empty hydration (loading of prior session state). **Why** This gives Claude Code's telemetry and startup logic more precise information about when a session is waiting on a handoff during resume or fork, though the finding doesn't specify the exact effect for users. - Area: Sessions - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Assistant tool-result messages now carry a toolDuration field Tool-result messages now record how long each tool call took, as toolDuration **What** The message Claude Code builds after a tool call completes now includes a `toolDuration` value, taken from the matching entry recorded for that tool call. This value feeds into a `toolDurations` array used elsewhere for aggregation and reporting. **Why** This lays groundwork for measuring and reporting how long individual tool calls take, which can help with performance analysis and diagnostics. - Area: Telemetry - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Non-interactive query harness gets a runQuery override Non-interactive query setup now accepts a caller-supplied runQuery override **Unclear.** What runQuery does differently from the default query execution, or which caller supplies it, is not stated. **What** The internal function that builds options for a non-interactive analysis query now accepts a `runQuery` parameter from its caller, and passes it into the options given to the agent context, alongside existing options like commands, tools, and MCP clients (connections to Model Context Protocol servers). **Why** This lets callers of the non-interactive query system override how the query itself is run, though the finding doesn't specify what particular use case this enables. - Area: Elsewhere - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Session-memory-rating telemetry now gated by allow_product_feedback Session-memory rating telemetry now also requires the allow_product_feedback setting **What** The `tengu_session_memory_rated` telemetry event, sent when a user marks a remembered session-memory entry as good or bad, is now only sent when `allow_product_feedback` is true, on top of the guard conditions it already checked. This matches the org policy that suppresses feedback-derived telemetry for accounts under zero-data-retention or HIPAA agreements. Nothing has been read yet about how `tengu_session_memory_rated` itself is currently configured. **Why** This ensures accounts whose organization policy blocks product-feedback telemetry don't have their session-memory ratings sent either, keeping telemetry behavior consistent with those data-handling agreements. - Area: Telemetry - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Artifact 'call_endpoint' action gets its own working-directory resolution via body_file The artifact tool's call_endpoint action now figures out its working directory from body_file instead of file_path **What** When the artifact tool runs a `call_endpoint` action, it now determines the working directory from a `body_file` field, rather than from `file_path` as other artifact actions do. **Why** This is a targeted fix so `call_endpoint` resolves its working directory from the field that's actually relevant to it, rather than one meant for other action types. - Area: Artifacts - Names: `body_file` - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Policy-limits credential/principal check now threads a reason through polling Policy-limits re-checks now record why they were triggered, such as a credential change or the hourly poll **Unclear.** The finding doesn't confirm what the reason is used for beyond being passed through the polling calls. **What** The internal checks that re-fetch your account's policy limits now carry an explicit reason label through the process, for example `credential_change` (the default when credentials change) or `hourly_poll` (the default for the regular scheduled check). **Why** This is likely for internal logging or telemetry, to distinguish why a policy-limits re-check happened, rather than changing what happens for the reader directly. - Area: Elsewhere - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Artifact 'read' action can now suppress the stored type declaration for live pages Artifact reads can now suppress the stored type declaration when reading a live probed page **What** Reading an artifact can now pass a `storedDeclaration` option. It's set to false automatically when the page being read is a live page that was probed dynamically (unless the read is specifically for the type-declaration page itself), which suppresses including the artifact's stored type declaration in the result. **Why** This avoids showing a possibly stale or irrelevant stored type declaration when the content being read is actually live-probed, keeping the returned data more accurate for that case. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Local-command transcript messages now carry a usage_report field Local slash-command transcript entries can now carry a usage_report field **What** When a locally-run slash command's output is turned into a synthetic assistant message in the conversation transcript, it can now include a `usage_report` field, sourced from the command's own usage report, alongside the existing `context_usage` and `local_command_run` fields. **Why** This lets local slash-command output carry its own usage reporting data through the transcript, alongside the context-usage tracking already used to power usage indicators. - Area: Slash Commands - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### New telemetry event tags unconfirmed observer resumes A new telemetry event fires when Claude Code can't confirm observer status during an agent resume **What** When Claude Code resumes an agent that is flagged as an "observer" but cannot confirm that status (neither the resume's activity kind nor a stored `isObserver` flag confirms it), and the `CLAUDE_CODE_FORWARD_USER_INTENT` environment variable is active, it now fires a telemetry event called `unconfirmed_observer`. **Why** This gives Anthropic visibility into cases where observer-mode resumes happen without clear confirmation, which can help track down bugs in how observer agents are resumed. - Area: Subagents - Names: `CLAUDE_CODE_FORWARD_USER_INTENT` - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Artifact publish tracks whether copied source files survive a resume Publishing an artifact now records whether copied source files still match what was approved **What** When publishing an artifact, Claude Code's publish tool can include "copies" — files copied into the artifact from another source. On resuming a publish, it now compares a hash of each copy's path, slug, path, and version against what was originally approved. The result, a true/false value, is attached to the `artifact_publish_resume` telemetry event as `copies_carried`. **Why** This lets Anthropic detect when copied source files have changed or gone missing between when a publish was approved and when it actually resumes, which matters for keeping published artifacts consistent with what a user agreed to. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Headless/SDK session init now threads a handoff relay marker Headless and SDK session setup now carries an internal handoff relay marker **Unclear.** What `handoffRelay` is used for, or what user-facing effect it has, isn't established by the evidence. **What** When Claude Code starts a headless session (used by the SDK or CLI harness), the internal options object built for it — which already includes things like `thinkingConfig`, `jsonSchema`, `initialMessages`, and `agents` — now also includes a `handoffRelay` field. It's only set when both an internal value and a matching internal flag are present; otherwise it's left unset. **Why** The finding doesn't say what consumes `handoffRelay` or what user-visible behavior it enables, so it's not clear yet what this changes in practice. - Area: Elsewhere - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### New telemetry event for publish rejected due to an unrecognized/not-served file path A new telemetry event reports the specific file path when a publish is rejected for an unrecognized path **What** When publishing files fails because a file's path isn't recognized as served (an internal check returns `notServedPath`), Claude Code now fires a `files_invalid` telemetry event carrying the specific rejected path, in addition to throwing the existing error. **Why** This gives more detail for diagnosing publish failures caused by unrecognized file paths, since the exact path involved is now captured rather than just the fact that an error occurred. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Tool call duration now attached to PostToolUse-produced messages Tool call duration is now recorded on messages produced after PostToolUse hooks run **What** After a `PostToolUse` hook (a script that runs after a tool call succeeds) finishes and Claude Code builds the resulting tool-result message, that message now carries a `toolDuration` object recording the tool's name and how long it took in milliseconds. These get collected into a `toolDurations` array that appears to feed into broader session statistics. **Why** This adds per-tool timing data that can be used for aggregated stats on how long tool calls take within a session, useful for spotting slow tools or hooks. - Area: Hooks - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Interactive REPL tool-use context now exposes a runQuery hook Interactive terminal tool-use context gains an internal runQuery hook **What - Area: REPL - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Artifacts distinguish content from writers outside your organization from generic 'foreign'/co-written content Artifacts now flag content from writers outside your organization separately from generic co-authored content **What** Artifacts (files Claude Code can read, publish, or query) now carry a new `outside_writer` flag on their read, publish, and database-read tool outputs. This is separate from the existing `foreign` flag that was already used to mark content written by someone else. When this new flag is set, the message shown to Claude when reading an artifact now specifically says the file 'may include content from a writer outside your organization,' replacing the older, more generic wording that just said it was another person's page or might include contributions from other writers. **Why** This gives Claude a clearer, more specific signal when working with an artifact: it can now distinguish content written by someone outside your organization from content that's simply co-written or foreign in a more general sense. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### 'Human sender' check generalized to any hearth_* prefix Internal 'is this a human sender' check now matches any sender kind starting with 'hearth' **Unclear.** What the 'hearth' prefix refers to or where such sender kinds come from is not stated. **What** An internal helper that decides whether a message sender counts as human previously matched only two exact sender-kind values. It now also treats any sender kind beginning with the prefix `hearth` as human. **Why** This broadens which sender types are recognized as human rather than automated, though the finding doesn't say what `hearth`-prefixed senders are. - Area: Inbox - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### Auto-mem and related project features gain a new 'is remote thread child' bypass Auto-mem warm-up and scanning now skip entirely for remote-thread-child sessions **Unclear.** What exactly 'remote thread child' sessions are, and why auto-mem should be skipped for them, is not stated. **What** Several call sites that trigger auto-mem warm-up and scanning now add a check that skips this work entirely when the current session is a 'remote thread child' (as determined by a function referred to here as `LU()`). **Why** This avoids running auto-mem warm-up and scanning in sessions spawned as children of a remote thread, where the finding implies it isn't appropriate or needed. - Area: Memory - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### New sandbox lane identity tracking (stashIdentity/takeIdentity) with no caller visible in this slice New sandbox internals track per-file identity for lanes, with no visible caller yet **Unclear.** No caller of stashIdentity/takeIdentity is visible, so what feature this supports is not established. **What** A sandbox file-lane class gains two new methods, `stashIdentity` and `takeIdentity`, which track a per-path device/inode identity using an LRU-style (least-recently-used) eviction cache. If the eviction-tracking set overflows, the lane enters a 'poisoned' state. **Why** No code calling these new methods is visible in this change, so it's unclear what feature this identity tracking supports yet. - Area: Sandbox - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### New `unknown_command_fallback` system-reminder template New unknown_command_fallback system reminder added for handling unrecognized commands **Unclear.** The exact trigger and purpose of the unknown_command_fallback reminder is not stated beyond its name and plumbing. **What** A new system-reminder template called `unknown_command_fallback` has been added. It renders content and is emitted as an event elsewhere in the system, where it is also filtered out of some other reminder aggregation logic. **Why** System reminders are internal messages Claude Code injects to give the model extra context. This one appears related to handling a command that isn't recognized, though the finding doesn't say exactly when or why it's triggered. - Area: Slash Commands - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### New MCP connector schema-reading guidance for Claude Docs/Artifacts New guidance tells Claude to read MCP connector tool schemas rather than guess argument names or result shapes **What** A new guidance string instructs Claude to look up argument names for MCP connector tools from the tool's own input schema, rather than guessing them, and never to guess a result's shape from a write call. It also notes that a published Claude Docs or Artifacts page can call `describeTool(server, tool)` at the time someone views it to read a tool's schema directly, but the session that authors the page cannot see that answer before publishing. **Why** This should reduce mistakes where Claude assumes incorrect argument names or result formats for MCP connector tools, and clarifies a timing limitation: schema lookups via `describeTool` only resolve at view time, not while the content is being authored. - Area: MCP - Names: `describeTool` - Tier: Under the hood - Useful: 1/5 - Signal: 1/5 ### MCP server allow/deny-list computation refactored into named helpers Internal code for computing which MCP servers are allowed or blocked was reorganized into separate functions **What** The logic that determines which MCP servers (external tool integrations) are allowed or denied based on policy settings was split into three separate internal functions: one for computing allowed servers (respecting managed-hooks-only style policy), one for computing denied servers (deduplicated across managed settings sources), and one for combining all these inputs into a single hash. **Why** This is an internal refactor of how the `allowedMcpServers` allowlist setting, which controls which MCP servers users can add, is computed. It does not change the setting's behavior for users. - Area: MCP - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Artifact/'publish' permission and result-building refactor Internal refactor of artifact-publish permission checks and result assembly, no visible behavior change **What** The code behind publishing artifacts was reworked internally in two areas: the read-permission checks that guard against reading from under a symlinked or redirected base path, and the assembly of deploy results (warnings, embedded content, manifest and live file paths, and lists of newly-live or reseeded files). The visible messages, such as 'root: reading from under ... is blocked by a Read permission rule' and 'plus N file(s) copied server side from ...', are unchanged. **Why** This appears to be a behind-the-scenes cleanup, largely variable renaming from code minification, rather than a change to how artifact publishing behaves or what you see. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Remote bridge (repl v2) transport handling refactor Internal refactor of the remote bridge's transport handling, no behavior change apparent **What** The code handling the remote bridge's transport layer (connection, incoming data, closing, presence and history syncing, and owner-changed handling) was refactored with renamed internal variables. The core behaviors, such as flushing history and reporting bridge connection and presence telemetry, appear to be preserved. **Why** This looks like an internal cleanup of the remote bridge's transport code rather than a change you would notice while using it. - Area: Remote Control - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### AWS credential env var forwarding — no functional change found No functional change found in sandboxed AWS credential detection and masking **What** The sandbox's detection and masking of an implicit AWS credential pair (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_SESSION_TOKEN`) is still present with the same messaging; the underlying code appears to have only been renamed internally. **Why** This is an internal cleanup with no expected effect on how AWS credentials are handled inside the sandbox. - Area: Sandbox - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### REPL two-step note lookup simplified, drops keptAsFiles logic The REPL's 'two-step' note lookup was simplified and no longer computes a `keptAsFiles` value **Unclear.** What the removed `keptAsFiles` value was used for, and whether anything downstream relied on it, isn't stated. **What** The internal function that provides 'two-step' notes for Claude Code's interactive session (REPL) was renamed and simplified. It now takes one fewer parameter and just returns the matching entry directly, instead of also computing and returning a `keptAsFiles` value alongside it. **Why** This is an internal simplification of how these notes are looked up; the removed `keptAsFiles` computation is no longer part of the result. - Area: REPL - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Frame-file listing response drops raw `paths` field Frame-file listing response for artifact consent checks no longer includes a raw paths field **What** An internal helper that lists frame or page files for artifact consent checks used to return both a `paths` array and a `pages` array (filtered markdown page paths). It now returns only `pages`. The failure branches for "no files consent" and "listing failed" also dropped the empty `paths: []` field they used to include. **Why** This is an internal cleanup of the data returned by a consent-checking helper, removing a redundant field rather than changing what consent checks actually do. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### apply_flag_settings control response strips an internal key apply_flag_settings control response handler now explicitly strips one internal key before returning settings **Unclear.** What the stripped internal key represents or why it needed excluding is not stated. **What** The handler that reads `apply_flag_settings` settings out of a control response was rewritten. It now explicitly pulls out one specific internal key and returns the rest, instead of the previous approach of rebuilding the settings object generically from `setting`/`name` pairs. **Why** This is an internal implementation change to how flag settings are extracted from a control response; the finding doesn't indicate a user-facing effect. - Area: Settings - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Catalog fetch-retry state now carries explicit disposition instead of a boolean Model-catalog fetch retry logic now uses named outcomes instead of a true/false flag **What** The internal function that decides what to do after fetching the model catalog fails or succeeds now takes one of three explicit outcomes — `retry_soon`, `back_off`, or `clear` — instead of a plain true/false value. It's used to handle error, ok, not-modified, and empty results from the catalog fetch. **Why** This is an internal refinement to how Claude Code schedules retries after a failed or unusual model-catalog fetch, replacing a simple flag with more descriptive states. - Area: Models - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Session storage: read-cache now also evicts an 'identities' map on invalidation Session storage's read cache now also clears a matching identities map when entries are invalidated **Unclear.** What the identities map is used for and what user-visible effect stale entries would have is not stated. **What** An internal caching component used for session storage now tracks an additional `identities` map. When cached entries are invalidated on the "read" path, matching keys are now also removed from this `identities` map, not just from the main cache. **Why** This keeps identity-related cache data from going stale alongside the rest of the invalidated cache, avoiding a case where stale identity data could linger after a read invalidation. - Area: Sessions - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Notebook and PDF read tool result humanization changed function name only Internal rename of the byte-size formatter used when reporting PDF and notebook file reads, no behavior change **What** The internal functions that format the human-readable summary for PDF and notebook file reads (things like the file size shown after a read) were renamed. The output shown to users is unchanged. **Why** This is a code cleanup with no effect on what you see when reading a PDF or notebook file. - Area: File Tools - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Session-resume: findUnresolvedToolUse now used directly instead of storageV5 field Session resume in print mode now finds unresolved tool calls directly instead of via a stored storageV5 field **What** When resuming a session in print mode, Claude Code now looks up any unresolved tool call (a tool invocation that never got a result recorded) by calling a dedicated `findUnresolvedToolUse` lookup directly, instead of reading it from a `storageV5` field that was passed through. **Why** This is an internal implementation change to how session resume locates unfinished tool calls; it should not change what you experience when resuming a session. - Area: Sessions - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Model catalog signing metadata bumped (version/date only, routine) Routine update to the signed model catalog's version and issue date, no functional change noted **What - Area: Models - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### CA cert entry gains a symlink target for the CCR agent proxy cert CCR agent proxy's CA certificate install now also creates a symlink at /etc/ssl/certs/ccr-agent-proxy.pem **What** The certificate-installation configuration for `ccr-agent-proxy.crt` now also specifies a symlink target at `/etc/ssl/certs/ccr-agent-proxy.pem`. **Why** This ensures the CCR agent proxy's certificate is also discoverable under the `.pem` name and path that some tools expect, alongside the original `.crt` file. - Area: Elsewhere - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Model source resolution now tracks explicit vs. persisted origin Model resolution now tags whether a model choice was explicit or persisted from a previous setting **Unclear.** What user-visible difference this distinction produces is not stated. **What** Internal model-resolution logic now passes an explicit `"explicit"` or `"persisted"` tag into a renamed helper function, and a companion helper checks whether a model is valid or counts as "persisted". **Why** This lets Claude Code's internal logic distinguish a model you explicitly chose from one carried over from a previously saved setting, which can affect how model-resolution decisions and related telemetry are made. - Area: Models - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Auto-mode-environment check factored into a reusable async helper The auto-mode-environment check was pulled out into a reusable helper checked at more points **What** The logic that decides whether an environment is configured for Auto permission mode was rewritten as a standalone function that reads the auto-mode config schema and checks it against user settings, then policy settings. Previously this check was inline and only ran at the moment a bridge session was spawned. **Why** Making this a reusable function lets Claude Code check for a configured auto-mode environment from more than one place in the code, rather than only at spawn time. - Area: Remote Control - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Transcript/progress message indexing rewritten as incremental classes Transcript indexing was rewritten to update incrementally instead of recomputing from scratch each time **What** The internal functions that build lookup maps from a conversation transcript — matching sibling tool uses, tool results, and hook progress counts — were rewritten. They used to be one-shot functions that recomputed everything from scratch each time; they're now stateful classes (an accumulator, an incremental builder, a tool-use-id tracker, and a transcript/progress splitter) that reuse prior work instead. **Why** This is an internal performance change: as a transcript grows, Claude Code no longer has to redo all of the previous indexing work every time it needs updated lookup data. - Area: Transcript - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### cd-tracking helper simplified, dropping the 'capped directory set' telemetry path The working-directory tracker for cd/pushd/popd chains was simplified, dropping its telemetry-reporting branch **What** The internal helper that tracks the current working directory through a chain of `cd`, `pushd`, and `popd` commands (used to check permissions on subsequent commands) was simplified. It no longer takes an optional fourth parameter, and no longer reports whether it hit a "capped" directory-tracking limit or ended up in an "unresolved" state through a telemetry-adjacent callback. It now simply returns a deny result or nothing. **Why** This is an internal cleanup that removes a reporting path Claude Code no longer needs, without changing what a command chain that uses `cd`/`pushd`/`popd` is allowed or denied to do. - Area: Bash Safety - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### file_path content-type check refactored to share the new unservable-file messaging The error message shown when a file_path points to an unservable file type now shares common wording **Unclear.** The finding doesn't say whether the actual wording shown to users changed, only that it now routes through a shared builder. **What** When you give an artifact tool a `file_path` whose content type isn't recognized or servable, the error message is now built from a shared message helper instead of its own separate text. **Why** This is an internal cleanup so the unservable-file error stays consistent wherever `file_path` is used, rather than drifting between separately maintained copies. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Model-tier/entitlement attribution logic refactored Internal logic for choosing model-access tier and entitlement was simplified and renamed **Unclear.** The finding does not state whether this changes any observable behavior around model access or entitlement. **What** The internal functions that decide which model-access setting applies to a session had an explicit early-return check removed; that check and a related one are now folded into a single combined condition. Several related helper functions used for looking up enforcement, entitlement, and tier were also renamed internally. **Why** This appears to be an internal refactor of how model access and entitlement decisions are computed, without a stated change in what the outcome is for users. - Area: Models - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Tool-list composition restructured to append a separate tool group Tool list building now appends one tool group separately instead of merging it in **Unclear.** Which tool category is now appended separately, and why, isn't identified in the finding. **What** The internal lists that assemble the full set of available tools now build the main list first, then append one additional tool group onto the end, rather than merging all tool groups together in one step as before. **Why** This is an internal restructuring of how the tool list is composed; the finding doesn't indicate any resulting change in which tools are available or how they behave. - Area: Elsewhere - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Bundled release-notes text (in-app changelog viewer) present but unchanged content shown In-app changelog viewer's bundled release notes are present but show no confirmed content change **Unclear.** Whether the bundled release-notes content actually changed could not be confirmed from the evidence. **What** The function that supplies the embedded release notes text for the in-app "What's new" viewer exists in both the old and new builds, including an entry for version 2.1.270. No actual content difference could be confirmed from the diff. **Why** Nothing to report here for users; this reflects the changelog text bundled with the app rather than a functional change. - Area: Elsewhere - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Internal refactor of `rewind_conversation` target validation in the remote/headless bridge rewind_conversation's target-validation logic pulled into a single shared helper **What** The code behind `rewind_conversation` (which lets a remote or headless connection jump the conversation back to an earlier message) has had its target-validation logic consolidated into one helper function. That helper now handles finding the target message, checking for stale or unseen targets, handling poll-tool-result targets, and checking delivered poll events within range, returning either a refusal or a description of what to cut. Other nearby code for re-homing the working directory over MCP and for handling messages/poll events was renamed but not otherwise changed. **Why** This further consolidates rewind's target-finding logic into a single, more maintainable helper, continuing earlier work to share this logic rather than adding new capability for users. - Area: Remote Control - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Named constant for the `!` negation prefix in `--tools` flag parsing The `!` negation prefix used in `--tools` rules is now a named constant **What** The `--tools` flag's parsing and validation logic, which resolves entries like `!Bash` into deny rules, now references a single named constant for the `"!"` negation prefix, used both in the parsing logic itself and in the warning/error messages about unmatched or malformed tool entries. **Why** This is an internal cleanup with no described change in how `--tools` behaves for users. - Area: Elsewhere - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Transcript rendering internals reworked (progress tracking, lookups renamed) Internal rework of how the conversation transcript view computes progress and message lookups **What** The internal function that renders the conversation transcript view now computes its transcript and progress data via a separate split step, and merges a separately-computed progress object into what used to be called `lookups` (now renamed `transcriptLookups`). **Why** This is an internal restructuring of how transcript data is computed and named, with no described change to what appears on screen. - Area: Transcript - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Refactor of the 'ask' decision-reason lookup for sub-command permission results Internal refactor of how Claude Code picks which sub-command permission result to surface as an 'ask' prompt **What** When Claude Code checks permissions across several sub-commands and needs to decide which result is worth surfacing as an "ask" prompt, this logic was previously two separate passes (one excluding a certain reason, one including it). It's now a single reusable function that takes a boolean flag for whether to exclude that reason, and this function is now called from multiple places. **Why** This is an internal code cleanup consolidating duplicated logic; the finding describes no change in what prompts are shown to users. - Area: Permissions - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Bridge REPL session-pull/teleport bookkeeping — heavy rename, no clear behavior change found Internal rename-only rewrite of bridge REPL session-pull and /teleport bookkeeping code **Unclear.** Whether this rewrite changes any actual behavior of `/teleport` or bridge session pulling isn't established by the evidence. **What** The internal function that manages Remote Control bridge REPL session state — including pulled rows, `/teleport` windows, bound-conversation tracking, and retrying after init failures — was rewritten, but the change appears to be mostly variable renaming rather than a change in logic. The same control flow, retry thresholds, and log messages are preserved. **Why** No behavior change is evident from this finding; it looks like internal code churn rather than something that affects `/teleport` usage. - Area: Remote Control - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Internal renames only: artifact publish/type tool refactors No functional change: artifact publish/type tool code was just renamed by the minifier **What** Two large sections of the artifact publish/type tool were rewritten, but the changes appear to be variable renaming from the build's minifier rather than a behavior change. The same logic paths remain: resolving shim URLs, summarizing file diffs, handling capability/room grants, and validating contracts. **Why** Nothing for users to act on; this is a cosmetic code change with no identified effect on behavior. - Area: Artifacts - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Internal renames only: sandbox credential masking (cae) and reply-on-resume (Yme) No functional change: sandbox credential masking and reply-on-resume code was just renamed **What** The logic that masks credential files inside the sandbox, and the logic that handles resubmitting an initial prompt when a session resumes ('reply on resume'), both show large diffs. These are consistent with pure variable renaming from the minifier, with no new behavior found. **Why** Nothing for users to act on; this appears to be a cosmetic code change rather than a functional one. - Area: Sandbox - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Version bump and build metadata Version bumped to 2.1.273 with updated build metadata **What** The `VERSION`, `BUILD_TIME`, and `GIT_SHA` constants were updated across all bundle entry points to reflect version `2.1.273`. **Why** Routine release bookkeeping that marks this build's version and build provenance. - Area: Elsewhere - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ### Auto-mode-environment-configured check now reads user/policy settings directly (je/de helpers) Checking whether auto mode's environment list is configured now reads settings files directly through new helper functions **Unclear.** The finding does not explain what `de()` does beyond being paired with `je()`, or what user-visible effect this has beyond the internal check. **What** Claude Code has an internal check for whether "auto mode" has a non-empty `environment` list configured, either in the user's own settings or in an organization policy. Previously this worked by resetting a settings cache and reading `userSettings`/`policySettings` inline. It's now done through two new helper functions: `je()`, which loads the settings module fresh, reads the user's settings file (falling back to policy settings if needed), and validates the result against a schema (`autoModeConfigSchema`); and `de()`. The result feeds into `userAutoModeEnvironmentConfigured`, and is only computed when the environment list is actually non-empty and this value hasn't already been set. **Why** This is an internal refactor of how that configuration check is performed; it changes how the check reads and validates settings rather than what auto mode itself does. - Area: Remote Control - Tier: Under the hood - Useful: 1/5 - Signal: 0/5 ## Removed ### Model catalog 'flag rows' feature removed Model catalog's 'flag rows' feature removed, replaced by a new servedCatalogOffBeforeAsking field **Unclear.** What the flag-rows feature did for users and what servedCatalogOffBeforeAsking changes in practice are not stated. **What** The model catalog's "flag rows" mechanism has been removed entirely: the `flagRowsAwaitTrust` and `flagAliasSpellings` state fields and the `model_catalog_flag_rows` telemetry event are gone. In their place is a new `servedCatalogOffBeforeAsking` field. **Why** This reflects an internal change to how the model catalog handles trust and alias spellings before presenting model choices; it is not stated what user-visible effect, if any, this has. - Area: Models - Tier: Under the hood - Useful: 2/5 - Signal: 2/5