Repository navigation
command_output: explain the 128+N exit codes a host's pipefail surfaces - #56
Conversation
…surfaces
`exit_code_hint` covered 127 and 126, so every other status reached the model
as a bare number. That left the signal codes unexplained, and a host that
wraps commands in `set -o pipefail` produces them constantly: piping a large
output into a reader that closes early (`| head`, `| grep -q`,
`| sed -n '1,Np'`) kills the writer with SIGPIPE, and the pipeline reports 141
even though the reader got everything it asked for. In one agent run, 9 of 44
recorded command failures were this, indistinguishable from real ones.
Explain the four conventional statuses, which need opposite responses:
141 SIGPIPE the output above is what the reader accepted and is usually
complete; treat it as data, not an error
137 SIGKILL killed by the OOM killer or a hard timeout; an unchanged retry
is killed again
143 SIGTERM stopped before finishing, so the output is partial
139 SIGSEGV a fault in the program or its input, not in the invocation
Only these and the two existing codes are annotated. An adjacent-looking
status (138, 140, 142) is not a convention and is left alone, as is any
application's own exit code.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
(cherry picked from commit 6daae62750c16a6e3e8671273a5e7571a760e85b)
Tiny Sweeper reviewTiny Sweeper reviewed this change across 6 lane(s) and found 1 active actionable finding(s). Detailed lane evidence and any incomplete work are listed below. State: Changes requested Review snapshot
Completeness: Complete What changedThe review could not produce a supported behavioral summary; inspect the cited changed surface and lane details below. FeaturesNone identified with supported citations. TestsNo supported feature-to-test mapping was produced. Test execution is not inferred. Findings
Before merge
How this fits togetherflowchart LR
n0["render_command_failure"]:::impacted
n1["command_failure"]:::impacted
n1 -->|calls| n0
classDef changed fill:#0d4429,stroke:#238636,color:#e6edf3
classDef impacted fill:#161b22,stroke:#6e7681,color:#c9d1d9
classDef flagged fill:#5a1e02,stroke:#d93f0b,color:#ffffff
classDef blocking fill:#67060c,stroke:#f85149,color:#ffffff
Agent review detailscritique
security
tests
commits
description
e2e
Evidence and run details
|
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Comment |
There was a problem hiding this comment.
Requesting changes: 1 lane(s) blocking, worst finding is high.
Fix or reply to the findings below and push. The next review clears this automatically once they are gone — you should not need to dismiss anything by hand.
$0.0019 · 48,064 in / 4,329 out · 5,973 cached (12%) · gpt-5.6-luna, glm-5.3-flash
critique: $0.0010 · 19,979 in / 1,817 out · 2,626 cached (13%) · gpt-5.6-luna, glm-5.3-flash
security: $0.0008 · 13,268 in / 999 out · 3,155 cached (24%) · gpt-5.6-luna
tests: $0.0000 · 5,599 in / 206 out · 64 cached (1%) · glm-5.3-flash
description: $0.0000 · 5,317 in / 93 out · 64 cached (1%) · glm-5.3-flash
| restriction. This will not succeed on retry — report the blocker \ | ||
| or request escalation instead of repeating the command" | ||
| } | ||
| 141 => { |
There was a problem hiding this comment.
Do not infer signals from exit codes alone
render_command_failure receives only an integer exit code, so it cannot distinguish a shell's 128 + signal result from an application that deliberately exits with the same value. For example, sh -c 'exit 141' reaches this arm without any SIGPIPE or early-closing reader, but the rendered message tells the agent to treat the output as usable rather than treating the command as failed. The same ambiguity applies to the newly added 137, 139, and 143 arms. Only emit these hints when the execution result preserves signal provenance, or remove the signal-specific hints from this formatter.
[RULE] ambiguous-exit-status ·
exit_code_hintcovered 127 and 126, so every other status reached the modelas a bare number. That left the signal codes unexplained, and a host that
wraps commands in
set -o pipefailproduces them constantly: piping a largeoutput into a reader that closes early (
| head,| grep -q,| sed -n '1,Np') kills the writer with SIGPIPE, and the pipeline reports 141even though the reader got everything it asked for. In one agent run, 9 of 44
recorded command failures were this, indistinguishable from real ones.
Explain the four conventional statuses, which need opposite responses:
141 SIGPIPE the output above is what the reader accepted and is usually
complete; treat it as data, not an error
137 SIGKILL killed by the OOM killer or a hard timeout; an unchanged retry
is killed again
143 SIGTERM stopped before finishing, so the output is partial
139 SIGSEGV a fault in the program or its input, not in the invocation
Only these and the two existing codes are annotated. An adjacent-looking
status (138, 140, 142) is not a convention and is left alone, as is any
application's own exit code.
(cherry picked from commit 6daae62750c16a6e3e8671273a5e7571a760e85b)
🤖 Generated with Claude Code