Version 2.1.195

Users can now authenticate with an enterprise cloud gateway directly from Claude Code using a browser-based device code OAuth flow, complete with TLS certificate pinning.

claude login          # opens the /login flow; gateway URL is provisioned via managed settings (forceLoginGatewayUrl)
/login                # same, from inside a session

• The gateway URL must use https:// (plain http:// is only allowed for localhost in development).
• On first connection, Claude Code shows the gateway's SHA-256 certificate fingerprint and prompts "You haven't connected to this gateway before. Once trusted, it can push settings to this machine that execute commands and change your environment. Only continue if this is your organization's gateway."
• If the certificate changes after a previous trust, a warning is shown: "The TLS certificate for this gateway has changed since you last connected. Only continue if your administrator has confirmed a certificate rotation."
• DNS resolution is validated to confirm the gateway host resolves to private-network addresses only. Direct IPs, dual-stack hostnames with a public AAAA record, and HTTP proxy hosts on public networks are all flagged with specific error messages.
• The token is persisted via secure storage after the browser flow completes.
• If NODE_EXTRA_CA_CERTS is needed for a private CA or self-signed certificate, a help message now explains exactly how to set it (both as an environment variable and via env.NODE_EXTRA_CA_CERTS in ~/.claude/settings.json).

Full browser-based OAuth flow (search for "Connecting to gateway…", "Certificate fingerprint (SHA-256):", "Gateway URL must use https://")

The Monitor tool now accepts a ws source that opens a WebSocket and streams each incoming text frame as a notification event — no shell process, no polling needed.

Monitor({
  ws: { url: 'wss://events.example.com/stream', protocols: ['v1'] },
  description: 'deploy events',
})

• Each text frame becomes one notification; multiline frames stay as one event.
• Binary frames are reported as [binary frame, N bytes] rather than passed through.
• Socket close ends the watch; close code and optional reason are surfaced.
• WebSocket errors appear before close as [WebSocket error: ...].
• Same rate-limiting as bash monitor — a firehose is suppressed and eventually stopped.
• Blocks connections to private/link-local/cloud-metadata IP ranges (SSRF protection) and respects sandbox.network.deniedDomains and allowManagedDomainsOnly.
• Compliance taint disables arbitrary-URL WebSocket egress with a clear message: "Monitor cannot open a WebSocket: arbitrary-URL egress is disabled by your organization's compliance policy."
• Cannot be combined with command.

New MonitorWsTask and MonitorWsPreconditionError types (search for "MonitorWsTask", "MonitorWsPreconditionError", "ws source")

The model catalog has been reworked into a structured, versioned manifest (schema_version: 1) covering all current models. Several new models are now registered.

• New model entries added: claude-sonnet-4-6 (Sonnet 4.6, knowledge cutoff August 2025), claude-opus-4-6 (Opus 4.6, knowledge cutoff May 2025 with fast_mode), claude-opus-4-7 (Opus 4.7, native 1M context, xhigh_effort, knowledge cutoff January 2026, default effort xhigh), claude-opus-4-8 (Opus 4.8, native 1M context, lean_prompt, mid_conv_system, default effort high), claude-fable-5 (Fable 5, native 1M context, rejects_disabled_thinking, fable_5_mitigations).
• Family aliases updated: opus → claude-opus-4-8, sonnet → claude-sonnet-4-6, fable → claude-fable-5.
• All models include provider IDs for first_party, bedrock, vertex, foundry, anthropic_aws, mantle, and gateway.
• Capability flags now include effort, max_effort, xhigh_effort, adaptive_thinking, context_management, fast_mode, lean_prompt, and mid_conv_system.

New model catalog object with schema_version: 1 (search for "Generated by \bun run generate:model-catalog\", "claude-sonnet-4-6", "claude-fable-5")

A warning is emitted when requesting the 1M context beta ([1m] model suffix) on Vertex for models that do not support it.

• The check fires at startup when the resolved gateway configuration includes a vertex upstream that serves claude-sonnet-4-5 or claude-sonnet-4 models (identified internally as sonnet45 / sonnet40).
• If the gateway config sets auto_include_builtin_models: true, the built-in claude-sonnet-4-5 model is automatically added to the warning list even when no explicit upstream model mapping covers it.
• The emitted message names the specific model IDs that triggered it: "vertex upstream serves <model-list>: Sonnet 4.5/Sonnet 4 do not support 1M context on Vertex — requests with the context-1m beta (the [1m] model suffix) for these models will be rejected with a 400. Vertex 1M lineup: Opus 4.6+/Sonnet 4.6."
• Emitted as a warn-level log via gu("warn", …) during gateway config validation; does not block startup or abort the request.
• Only vertex-provider upstreams are checked; other providers (bedrock, foundry, etc.) are unaffected by this warning.

Vertex 1M limitation notice (search for "Sonnet 4.5/Sonnet 4 do not support 1M context on Vertex", u5c, auto_include_builtin_models)

If your organization's gateway has set a maximum effort level for a given model, /effort will silently cap selections above that limit and show an explanatory message.

• When you pick an effort level that exceeds the organization cap, Claude Code automatically uses the highest allowed level (or the model's own floor, whichever applies) and logs a message like: "Effort 'xhigh' exceeds your organization's limit for claude-sonnet-4-6; using 'high'."
• The /effort picker displays a "Higher effort levels are restricted by your organization." notice when some effort levels are blocked.
• The Usage: /effort [...] help text now dynamically lists only the effort levels actually available for the current model and session.

Effort capping logic (search for "exceeds your organization's limit for", "Higher effort levels are restricted by your organization.")

When starting or resuming a cloud session, a structured progress view now shows each setup step (provision, clone, setup_script, start_cc) with live status, elapsed time, and detail lines.

• Steps shown: "Setting up a cloud container", "Cloning repository", "Running setup script", "Starting Claude Code" (and resume variants: "Resuming your cloud container", "Refreshed repository", etc.).
• Elapsed time is shown per step once it exceeds 5 seconds.
• Messages queued during setup are listed: "N messages queued · sends once the session is ready" or "You can start typing — messages send once the session is ready".
• Final summary: "Remote session ready in Xs" (or "resumed in Xs").

Progress step renderer (search for "Setting up a cloud container", "Cloning repository", "You can start typing — messages send once the session is ready")

Claude Code now warns at startup if a hook matcher like mcp__my_server matches no known tool, because hook matchers are compared as exact strings — the correct pattern to match all tools from a server is mcp__my_server__.*.

• Warning message: "Hook matcher mcp__server matches no tool (it is compared as an exact string). To match all tools from this server, use mcp__server__.*. See CHANGELOG v2.1.195."
• Only fires once per distinct matcher pattern per session.

Hook matcher warning (search for "matches no tool (it is compared as an exact string). To match all tools from this server, use \"`)

MCP tools whose input schemas use top-level anyOf, oneOf, or allOf can now be normalized into a flat object schema, making them usable in Claude Code without being dropped.

• Controlled by the tengu_mcp_normalize_root_combinators feature flag. Set to ["*"] for all MCP servers, or a list of hostnames to target specific ones. Hostname entries support subdomain matching: "example.com" also matches api.example.com.
• Only URL-based MCP servers (those with a url property) are eligible. stdio and sdk-type servers have no url and are never normalized regardless of flag value.
• The injected note in the tool description differs by combinator type:
• allOf only: "Input constraint: all listed parameters apply together (flattened from a JSON Schema allOf)."
• oneOf: "Input constraint: Provide parameters for exactly one of: (param_a, param_b) or (param_c)."
• anyOf: "Input constraint: Provide parameters for at least one of: (param_a, param_b) or (param_c)."
• If parameter groups cannot be extracted from the schema branches, the note falls back to: "Input constraint: Provide parameters for exactly one of the documented parameter groups (flattened from a JSON Schema oneOf)."
• Only property names matching /^[a-zA-Z0-9_.-]{1,64}$/ are included in the flattened schema; others are silently excluded.
• Top-level schema fields preserved through normalization: $defs, definitions, $schema, additionalProperties, description, title.
• If normalization fails for any reason, the tool is dropped with a logged reason (e.g., "input schema has top-level anyOf that is not an array") rather than silently accepted with a broken schema.

Schema normalization (search for "Input constraint: all listed parameters apply together", "Provide parameters for exactly one of", "Provide parameters for at least one of", Mxp, tengu_mcp_normalize_root_combinators)

The built-in /code-review workflow now deduplicates candidates before verification — each distinct (file, line) location gets exactly one independent verifier, rather than one verifier per raw candidate.

• Old description: "one independent verifier for every candidate"
• New description: "one independent verifier for every distinct (file, line) location across the pooled candidates"
• Findings from all finder agents are pooled first, then verified — this reduces duplicate work when multiple finders identify the same location.

Updated code review description constant (search for "one independent verifier for every distinct (file, line) location across the pooled candidates")

The /config command now accepts key=value arguments to set panel settings inline without opening the interactive panel.

/config model=claude-opus-4-8
/config theme=dark

• Supported settings include model, theme, verbose, and output style.
• User-facing tip: "/config key=value sets panel settings (model, theme, verbose, output style, …) inline — no need to open the panel."

New /config inline setting tip (search for "/config key=value sets panel settings")

MCP servers that require authentication can now be authenticated from the command line, with a --no-browser flag for SSH/headless environments where the browser cannot open.

claude mcp login <server-name>
claude mcp login <server-name> --no-browser

• --no-browser prints the callback URL for manual pasting rather than attempting to open a browser.
• Tip: "claude mcp login <name> authenticates an MCP server from the CLI — add --no-browser to paste the callback URL manually over SSH."

New CLI tip (search for "claude mcp login <name> --no-browser")

Permission rules now support matching on a specific tool input parameter value, allowing fine-grained auto-handling without a blanket allow.

• Example rules: deny Agent(model:opus) or ask Bash(run_in_background:true).
• Tip: "Deny and ask rules can match a tool input parameter — e.g., deny Agent(model:opus) or ask Bash(run_in_background:true) — so that specific pattern is auto-handled without prompting each time."
• The /permissions panel guidance also updated to reference this syntax.

New permissions tip (search for "Deny and ask rules can match a tool input parameter", "/permissions, then add a Tool(param:value) deny or ask rule")

Skill enable/disable overrides (skillOverrides) are now checked in local project settings (localSettings) in addition to project and user settings, with local settings taking the highest priority.

• The resolution order is two-phase: (1) look up by fully-qualified cmdName in projectSettings, then userSettings; (2) if nothing found, look up by unqualifiedName in localSettings, then projectSettings, then userSettings. localSettings is therefore checked only for the unqualified name, not for the full command name.
• Valid override values and their effects: "on" (default — fully visible to model and typeable); "name-only" (lists the skill without its description); "user-invocable-only" (hidden from model invocation, but still typeable as /name); "off" (hidden from both the model and the /name prompt).
• When a skill's lockSource is "author", any resolved override value other than "off" is silently capped to "user-invocable-only". This means authors can prevent a skill from being fully exposed, but individual users cannot grant it full "on" status.
• The /skills panel writes overrides to localSettings (not projectSettings), so panel changes are local to the machine and do not affect teammates sharing the same project settings file.
• Attempting to invoke a skill whose effective state is "off" or "user-invocable-only" via the model produces the error: "Skill '<name>' is disabled via skillOverrides. Re-enable it in /skills or remove the override from your settings to run it."

Updated skill override resolver (search for Mjl, "localSettings" in context of skillOverrides, "user-invocable-only", "Skill.*disabled via skillOverrides")

When a response was interrupted mid-generation, the resume hint now escapes angle brackets inside the fence (HTML-entity-escaped) to avoid parse ambiguities. The prior-partial-output fence boundary is also validated more carefully.

• New message: "Your previous response was interrupted mid-generation. Your prior partial output follows this reminder, fenced as <interrupted-output> (angle brackets inside the fence are HTML-entity-escaped). It is..."
• Logs [reply-on-resume] prefill boundary mismatch if the boundary doesn't match what was expected.

Interrupted output handling (search for "[reply-on-resume] partial-hint", "[reply-on-resume] prefill boundary mismatch")

• Adoption (workflow handoff) now retries on EPERM/EBUSY/EACCES errors up to 3 times with 50ms delay before giving up, reducing failures on Windows and network paths (search for "ebusy_retry")

• system-reminder tags are now stripped from both the leading AND trailing end of assistant text blocks, not just from the start — preventing stale reminders from leaking into prefill boundaries (search for "</system-reminder>" in the Cur function)

• Daemon error messages and stack traces now have hex session IDs replaced with cc-daemon- before logging, preventing log pollution with session-specific noise (search for "cc-daemon-")

• Monitor stopped message now shows the count of excess output bytes as a number rather than a raw string fragment, and the restart advice is no longer appended (search for "[Monitor stopped — too much output (")

• Voice stream now handles mid-stream errors by salvaging partial audio rather than silently failing (search for "[voice] mid-stream error: salvaging")

• MCP server re-authentication notifications are now namespaced with a prefix (mcp-needs-reauth-) to avoid colliding with other notification IDs (search for "mcp-needs-reauth-")

Hook matchers for MCP servers have changed behavior (or rather, an existing behavior is now surfaced as a warning): mcp__server_name is an exact-string match that will never match any real tool. The correct form to match all tools from a server is mcp__server_name__.. If you see the warning "Hook matcher mcp__server matches no tool", update your hook rules in .claude/settings.json to use the __. suffix.