Follow Discord
Sweep 10 Nov 2026 · 02:18Z Build v2.1.322 539 read Stable v2.1.311 Latest v2.1.322 Next v2.1.322 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.275 ·

Tool results and denials can now carry a structured 'remedy'

Failed or denied tool calls now include a structured remedy code so hosts can offer a fix without parsing error text

Group of 6 Under the hood Internal Changes
JSON All of v2.1.275
Under the hoodTier: how much it should matter to you
3Useful: my rating, 1 to 5
3Signal: worth watching, 1 to 5
Tool ResultsArea: what it touches
Internal ChangesKind: in v2.1.275,
Internal ChangesSection of the release

What

  • A new internal remedy field can be attached to a tool result's metadata (tool_result_meta), giving a structured reason for a failure instead of free text. Its possible values include mcp_needs_auth, mcp_disabled, mcp_required_missing, auth_expired, auth_overridden, auth_missing_scope, design_needs_authorization, sandbox_violation, outside_reads_blocked, memory_paused, feature_disabled, policy_denied, spawn_arg_limit, and staged_for_review.
  • This remedy is now threaded through as toolResultRemedy when building the tool-result message shown to Claude, and included in the transcript summary for denied or blocked tool calls alongside the existing non_execution_kind.
  • Errors produced after a failed tool call now include toolResultRemedy next to the existing toolDenialKind, both produced by new classifier functions that turn internal permission-deny and connection/auth failures into these structured kinds.

Why

This lets tools and host applications programmatically detect why a call failed, for example missing MCP authorization versus a sandbox violation, and suggest the right fix instead of relying on parsing human-readable error text.

See this entry in the whole of v2.1.275 →

Feedback