Review noted the handler's comment said "EPIPE" while the code swallowed every stdin 'error'. Swallowing any stdin-write error IS correct here — the write is best-effort and the command's authoritative outcome is its exit code + captured output (reported by the `close` handler regardless of whether the write landed). A rare non-EPIPE pipe fault means the command ran with incomplete stdin, which it surfaces itself via its own exit/output; rejecting `done` would instead discard that real output and turn it into an opaque infrastructure error. Widen the comment to state this rather than implying only EPIPE is caught. No behavior change. |
||
|---|---|---|
| .. | ||
| bash | ||
| bash-local | ||
| tool-bash | ||
| README.md | ||
bash/ — bash capability family
The canonical three-package capability seam (see capability seams): an abstract executor interface, a concrete local implementation, and the model-facing tool that consumes it. All product packages.
| Package | Role | ctx key |
|---|---|---|
bash/ |
Abstract bash executor seam (interface + vocabulary) | ctx.bash |
bash-local/ |
Local-subprocess BashExecutor implementation |
(registers ctx.bash) |
tool-bash/ |
Model-facing bash/bash_output/bash_kill tool schemas |
(registers on ctx.tools) |
The interface lives at bash/bash/. A sandboxed executor would replace bash-local without touching the interface or the tool — the split is what makes that possible.