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

[VoxCore84]

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.

2. 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.

3. 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.

4. 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

• [Bug] Multi-step tasks lack per-step verification — errors compound silently #32293 covers lack of per-step verification (not checking between steps)
• [Bug] Claude generates incorrect code/SQL and reports it as complete without validation #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

• [Bug] Multi-step tasks lack per-step verification — errors compound silently #32293 — No per-step verification gates
• [Bug] Claude generates incorrect code/SQL and reports it as complete without validation #32289 — Reports incorrect code as complete
• [Bug] Claude Code reports task completion without actually executing operations #32281 — Reports completion without execution
• [Meta] Systematic completion-integrity failures — 16 issues across 6 phases from 100+ sessions of evidence #32650 — Meta-issue (Phase 3 addition)

Environment

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

[github-actions]

Found 3 possible duplicate issues:

1. Hookify warnings don't reach the model (only shown to user) #20747
2. MCP servers incorrectly shown as 'failed' when stderr contains non-error output #17653
3. [MODEL] Opus adds unnecessary 2>/dev/null to Bash commands, silently swallowing errors #28466

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[VoxCore84]

This is not a duplicate of any of the three suggested issues. They describe different problems at different layers:

vs #20747 (Hookify warnings don't reach the model): That issue is about a specific plugin's warning messages not being injected into the model's context. This issue (#32657) is about the agent ignoring warnings and errors that are already visible in tool output — stdout/stderr from commands like SQL applies, builds, and git operations. The warnings reach the agent; the agent ignores them. Different problem, different fix.

vs #17653 (MCP servers shown as 'failed' due to stderr): That issue is about the UI misinterpreting stderr output from MCP servers as server failure. This issue is about the agent itself ignoring stderr content from the commands it runs. One is a UI display bug; the other is a behavioral failure in the agentic execution loop. They happen to both involve stderr, but at completely different layers (MCP server lifecycle vs. task command execution).

vs #28466 (Opus adds 2>/dev/null to commands): That issue is about the model actively suppressing error output by appending 2>/dev/null. This issue is about the model passively ignoring error output that is present and visible. One is a generation problem (the model writes bad commands); the other is a reasoning problem (the model doesn't process the output it receives). They are opposite failure modes — one hides errors before they appear, the other ignores errors after they appear.

This issue is part of a 16-issue taxonomy documented in #32650, which organizes completion-integrity failures by lifecycle phase. #32657 specifically addresses the execution gate treating exit-code-0 as categorical success without parsing output content — a failure mode not covered by any of the three suggested duplicates.

[VoxCore84]

Community Validation Update — Ignores stderr / Warnings

This failure mode has limited direct reports but significant economic impact evidence from review platforms.

Trustpilot

Claude.ai reviews include users describing the tool as "absolutely unusable for professional work" — citing scenarios where Claude proceeds confidently despite visible error output. One reviewer describes paying $200+/month for a service that silently ignores build warnings and test failures, producing code that appears to work in Claude's summary but fails in production.

DoltHub Blog

Claude Code Gotchas documents "forgotten compilation" — Claude makes code changes, doesn't run the build, and reports success. When the build IS run and produces warnings, Claude often treats warnings as informational rather than actionable, proceeding to the next step without addressing them.

Pattern

This issue is closely related to #32281 (phantom execution) and #32301 (never surfaces mistakes). The specific failure here is that stderr output and compiler/test warnings ARE visible in the tool response, but the model filters them out of its reasoning as non-critical. This is a different mechanism than phantom execution (where the tool isn't run at all) — here the tool runs, produces warning output, and the model ignores that output.

Mitigation Opportunity

A PostToolUse hook that scans Bash tool output for common warning/error patterns (compiler warnings, test failures, deprecation notices) and forces Claude to acknowledge them would directly address this. Similar to the edit-verifier pattern in PR #32755, but for command output rather than file content.

Part of the completion-integrity taxonomy tracked in #32650.

[VoxCore84]

Pass 5 — Final Evidence Update (Ignores stderr / Warnings)

108-Hour Unattended Test

DEV Community article: Claude ran for 108 hours autonomously. Among failures: $8 API loop — Claude called an API endpoint in an infinite loop, ignoring error responses and rate limit warnings in stderr. Cost accumulated silently because stderr output wasn't treated as actionable.

DoltHub Blog

"Forgotten compilation" gotcha — Claude makes code changes, doesn't run the build, reports success. When the build IS run and produces warnings, Claude treats them as informational rather than actionable.

HN Thread

47107630 — "Claude crashed? Am I paying for tokens for it to fix itself?" — filesystem I/O errors in output ignored, Claude continued generating corrupted responses.

Trustpilot / Enterprise

• 773+ Trustpilot reviews: Users describe paying $200+/month for a service that ignores build warnings and test failures
• Anthropic status page: 98 incidents in 90 days, 22 major — infrastructure errors that the tool should surface but doesn't

Mitigation Proposal

A PostToolUse hook for Bash tool output (similar to the edit-verifier pattern from PR #32755) that scans stdout/stderr for common warning patterns:

• Compiler warnings (warning:, Warning:)
• Test failures (FAIL, FAILED, Error:)
• Rate limits (429, rate limit, too many requests)
• Zero-row results when rows expected

This would force Claude to acknowledge warnings before proceeding. The pattern is proven — our edit-verifier hook has already caught real failures.

Part of the completion-integrity taxonomy tracked in #32650.

[VoxCore84]

Still reproducing. stderr warnings from build tools, SQL applications, and pip installs are routinely ignored — Claude treats exit code 0 as "success" regardless of warning output. This isn't stale, it's unaddressed. See meta issue #32650.