[MODEL] Sonnet 5 (Claude Code returns "Sonnet 5 can't help with this" when reading or receiving a valid USPTO API key credential)

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude's behavior changed between sessions

What You Asked Claude to Do

Complete a data-pull task (USPTO alias/record search, per a work order already in the project folder) using a stored USPTO Open Data Portal API key. This was attempted two ways across separate sessions: (1) asking Claude Code to read the key from a credentials file already present in the project folder, and (2) providing the key value directly in the chat message after the first method failed.

What Claude Actually Did

Four times, across both methods of providing the key, Claude Code began the task normally, then immediately terminated with "API Error: Sonnet 5 can't help with this" right after the key was read or received — no further explanation, just a link to Anthropic's Usage Policy. One of the four sessions also displayed a stale, unrelated task summary (referencing a "field coverage audit" task that had already finished days earlier) in its recap before this error occurred, suggesting possible session-state corruption may be a contributing factor.

Expected Behavior

Claude Code should have authenticated with the key and completed the requested USPTO lookup — the same key and the same kind of task had worked successfully in an earlier session of this same project (an earlier round of the same work).

Files Affected

A credentials file at Credentials\uspto_api_key.txt within the project folder; a script named build_round2_taska.py was also written to disk during one session, shortly before that session's crash.

Permission Mode

Accept Edits was OFF (manual approval required)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

Reproduced 4 times, consistently, across 2 different methods of supplying the same credential.

1. In a Claude Code project containing a stored API credentials file, ask Claude Code to use that credential to authenticate a request to an external API (in this case, USPTO's).
2. Observe that immediately after the credential is read from the file, or provided directly in chat, the session terminates with "API Error: Sonnet 5 can't help with this."

Claude Model

Sonnet

Relevant Conversation

Request IDs from the four occurrences, in order: req_011Cf5fd8mPY1txSg65Fvvjy, req_011Cf5iTPHKxjje1qSqc7co1, req_011Cf5j8SPCSQLnXF4oZUrxA, req_011Cf5mTkiH5evNN2C1dcXv3

Impact

Critical - Data loss or corrupted project

Claude Code Version

Claude Code v2.1.224

Platform

Anthropic API

Additional Context

The credential itself was independently confirmed valid and working, tested outside Claude Code entirely (a direct request to the same API endpoint using a separate tool, which returned valid data). This confirms the credential is not the cause — the failure is specific to Claude Code's handling of it. Also worth noting: the failure occurred identically whether the key was read from a file or provided directly as plain text in the chat message, suggesting the trigger is the presence and use of this kind of credential value, not the specific method of supplying it.

Main session model: Opus. However, the actual error message specifically named "Sonnet 5" as the model that failed — Claude Code appears to have delegated the failing operation to a Sonnet 5 subagent rather than handling it directly in the main Opus session.

Confirmed the tool itself is functioning normally in a fresh session for unrelated requests (e.g., basic arithmetic) — the failure is specific to this particular task's content, not a general outage.

This may be a false-positive from the new 'Containment Escape' auto-mode classifier rule (added in 2.1.257) and cited below— my task (reading a stored API key to make a legitimate, authorized government-API request) may be structurally resembling the credential-exfiltration pattern this rule was built to catch.

Look at this entry from version 2.1.257, dated within roughly the same window as when these failures started: "Added a Containment Escape rule to auto mode so cloud metadata-credential fetches, egress evasion, and cross-tenant reach are no longer auto-approved unless your environment marks them expected"

And this one, from the following week (2.1.267): "When the auto mode classifier blocks an action, the reason Claude receives usually names the rule that matched, such as [Data Exfiltration]"