[Bug] Agent fails to parse tool-call error output, enters read-retry loop wasting thousands of tokens

Description

When a Bash or any tool call returns an error output (Python traceback, TypeScript compilation error, shell error), the agent frequently fails to properly parse the error message to identify root cause. Instead of acting on the error information, it enters a repetitive read-retry loop:

1. Re-reads the same source files that were already in context
2. Re-runs the same failing command with trivial/irrelevant modifications
3. Asks clarifying questions whose answers are already visible in the error output
4. Repeats this cycle 3–5+ times before either eventually succeeding or exhausting context

Each iteration in this loop consumes 5K–15K+ tokens for no useful work. This is a serious token-waste issue that occurs consistently across different sessions and different types of errors.

Expected Behavior

When a tool call returns a clear error (with file path, line number, error type, and call stack), the agent should:

• Identify the root cause from the error message in one pass
• Apply the correct fix directly (e.g., fix the Python syntax error at the identified line, install the missing dependency, correct the API call signature)
• Not re-read files that are already in the conversation context
• Not re-run the same command with cosmetic changes

Actual Behavior

Example pattern observed repeatedly in practice:

Cycle 1: Run command → error with traceback → agent re-reads the file(s) involved
Cycle 2: Runs a slightly different command → same error or different error → re-reads the file again
Cycle 3: Asks "it seems there is an error" despite the error clearly visible in the last tool result → tries another variant
Cycle 4+: Repeats until context gets compacted or user intervenes

The error message already contains the line number, column, error type, and description — yet the agent does not use this information effectively.

Steps to Reproduce

1. Have the agent write a Python script with a deliberate syntax error or runtime error
2. Ask it to run the script with bash or similar tool
3. Observe that when it gets an error traceback, it frequently:

• Re-reads the file (even though it just wrote it and it should know the content)
• Tries the same command again
• Only after 2-3 cycles does it actually fix the error indicated in the traceback

Impact

• Severity: High — this happens across multiple sessions daily, wasting significant token budget
• Each occurrence wastes 15K–50K+ tokens on an error loop that should be resolved in 1-2 tool calls
• Particularly painful on API-call billing where wasted tokens are real cost
• Disrupts workflow flow state when user has to interrupt the loop

Environment

• Claude Code version: Latest as of June 2026 (v2.1.x line)
• macOS 15.7
• Model: Claude Opus 4.0 / 4.5 / 4.8 (observed across multiple models)
• Shell: bash/zsh
• Terminal: iTerm2

Related

• Similar pattern to #72401 (ignores tool requests), but specifically about failing to parse error diagnostic information from tool output.
• Related to the model's general difficulty with structured error output processing, which is a training/fine-tuning issue rather than a code bug.