Repository navigation
Claude Code driver hides structured stdout errors on nonzero exit #5712
Description
Activity
- added a commit that references this issue
on Sep 2, 2026 - addedtriage: validReviewed and confirmed as a valid actionable issueReviewed and confirmed as a valid actionable issue
on Oct 9, 2026 Triage: valid — Current review confirms this is a concrete, in-scope engineering issue or request: “Claude Code driver hides structured stdout errors on nonzero exit”. No complete resolution is evident in current main.
- addedsource: externalIssue opened by an outside contributorIssue opened by an outside contributor
on Oct 9, 2026 Still reproducible in the current code, but the fix has to land in TinyAgents first.
The Claude Code driver no longer lives in this repository. It moved to the vendored TinyAgents harness, at
crates/tinyagents-harness/src/providers/claude_code/driver.rs. On both the commit OpenHuman pins today (vendor/tinyagentsat33a86887d5onmain) and the current TinyAgentsmain(b518ea77fb), lines 611-620 still check!status.success()and bail withexit {:?} stderr=...before they look atmapper.error. A nonzero exit with empty stderr therefore still loses the structured stdout error, as reported.What a fix needs:
- In TinyAgents, when the exit is nonzero, return
mapper.error(sanitized and bounded) if it is set, and fall back to bounded stderr only when it is not. Adddriver_tests.rscases for both branches and one that checks secrets stay out of the message. - In OpenHuman, move the
vendor/tinyagentsgitlink to that commit once it merges.
Related: tinyhumansai/tinyagents#360 (for #5648) touches the same block. It retries once on a missing resumed session but does not change the stderr-first ordering, so it does not fix this issue. Leaving this open to track the work.
- In TinyAgents, when the exit is nonzero, return
- added a commit that references this issue
on Oct 10, 2026
Summary
When Claude Code emits a structured error on stdout and exits nonzero, the driver reports only stderr. If stderr is empty, OpenHuman loses the actionable provider error and shows a generic failure such as
exit Some(1) stderr=.Problem
Environment
Reproduction evidence
During a failed Claude Code turn, Claude's structured output contained:
The corresponding OpenHuman log and user-visible error retained only:
The current driver awaits stderr, then bails on
!status.success()before checkingmapper.error:openhuman/src/openhuman/inference/provider/claude_code/driver.rs
Lines 483 to 493 in 41cbcc3
The event mapper already has a dedicated structured error field:
openhuman/src/openhuman/inference/provider/claude_code/event_mapper.rs
Lines 45 to 86 in 41cbcc3
Expected behavior
When a nonzero exit also has a parsed structured provider error, OpenHuman should surface a sanitized, actionable version of that error. Stderr can remain a fallback for process-level failures where no structured error exists.
Solution
Prefer
mapper.erroron nonzero exit, then fall back to bounded/sanitized stderr. Avoid logging raw payloads, credentials, headers, temporary MCP configuration, or account identifiers.Acceptance criteria
mapper.error = Some(...)returns the structured error rather than a blank stderr message.Related