API Error 400: Tool use concurrency issues persists after initial failure, poisoning session

Summary

After a parallel tool call fails with API Error: 400 due to tool use concurrency issues, subsequent single tool calls in the same session also fail with the same error. The session becomes "poisoned" and requires a full restart to recover.

Steps to Reproduce

1. Start a Claude Code session
2. Ask Claude to perform a task that triggers parallel tool calls (e.g., "find all TypeScript and JavaScript files")
3. Claude executes two Glob calls in parallel:

``
Glob pattern: "**/*.ts"
Glob pattern: "**/*.js"
``

1. Request fails with: API Error: 400 due to tool use concurrency issues
2. Ask Claude to perform a single tool call (e.g., read one file)
3. This also fails with the same error, even though it's not parallel

Expected Behavior

• Either parallel tool calls should work, OR
• After an error, subsequent single tool calls should succeed (error recovery should reset state)

Actual Behavior

Once the 400 error occurs, the session is in a corrupted state where all subsequent tool calls fail, regardless of whether they're parallel or single. The only recovery is restarting the session.

Root Cause Hypothesis

The tool execution context maintains "in-flight" state that isn't cleaned up after a 400 error. When the parallel calls fail, the server/client still thinks tools are pending, causing subsequent calls to also fail the concurrency check.

Environment

• Claude Code CLI (VSCode extension)
• Model: claude-opus-4-5-20251101
• OS: macOS Darwin 24.6.0
• Date: 2026-01-26

Impact

• Users must restart sessions after hitting this error
• Parallel tool calls (which the system prompt encourages) can trigger this
• No programmatic recovery possible

Suggested Fix

Error recovery after a 400 tool concurrency error should reset/clear the tool execution state so subsequent calls can proceed.