[Bug] Claude ignores non-fatal tool output — warnings and stderr treated as success

Ignoring Non-Fatal Tool Output / Stderr

Phase: Execution (Phase 3 in the failure chain documented in #32650)

Description

When Claude executes a tool (build script, SQL apply, git command, etc.) and the command exits with code 0 but prints warnings, errors to stderr, or text indicating a logical failure, Claude ignores the output entirely. As long as the tool call itself didn't hard-crash, Claude confidently proceeds and reports success.

Concrete Examples

1. SQL apply with warnings: MySQL outputs Query OK, 0 rows affected (0.01 sec) followed by 3 warnings — Claude reports "Applied cleanly" without checking what the warnings were. The warnings could indicate truncated data, implicit type conversions, or ignored duplicate keys.

1. Build with critical warnings: A C++ build completes (exit 0) but emits warnings about narrowing conversions, uninitialized variables, or deprecated function usage. Claude reports "Build succeeded" without noting the warnings, some of which may indicate runtime bugs.

1. Git operations with fuzz: git apply succeeds but reports fuzz factor or offset adjustments. Claude reports the patch applied cleanly when it may have applied to the wrong location.

1. Command output indicating logical failure: A query returns 0 rows when rows were expected, or a count doesn't match expectations. The command "succeeded" (exit 0) but the result indicates something went wrong. Claude treats exit-code-0 as categorical success.

Root Cause

Claude's success/failure evaluation appears to be primarily based on whether the tool call returned an error vs. completed normally. It does not systematically parse stdout/stderr content for indicators of partial failure, warnings, or unexpected results.

Expected Behavior

After any tool execution, Claude should:

1. Check the exit code
2. Parse stdout/stderr for warning indicators (the word "warning", "error" in output, unexpected counts, fuzz/offset messages)
3. If warnings are present, surface them to the user before claiming success
4. If the output indicates a logical failure (0 rows affected when rows were expected), flag it rather than treating exit-0 as success

Why This Is Distinct

• #32293 covers lack of per-step verification (not checking between steps)
• #32289 covers generating incorrect artifacts (wrong SQL)
• This issue covers ignoring evidence of failure that the tool already provided — the information was right there in the output, and Claude didn't read it

Related Issues

• #32293 — No per-step verification gates
• #32289 — Reports incorrect code as complete
• #32281 — Reports completion without execution
• #32650 — Meta-issue (Phase 3 addition)

Environment

• Claude Code 2.1.71
• Windows 11
• 100+ sessions of documented usage