A sandboxed child that dies without sending names the tool it was running

[Shashankss1205]

Closes #111.

The gap

poll() returns true when the pipe is readable, and a closed pipe is readable. So a child that died without sending — os._exit, a segfault, an OOM-kill — fell through the timeout guard into recv():

RAISED builtins.EOFError: ''
does the message name the tool? False

run has two failure shapes and this was neither: SandboxViolation for a confinement breach, RuntimeError(f"tool {name!r} failed: …") for the tool's own exception.

Why it mattered

AgentNode's loop catches it under the blanket clause and renders f"TOOL_ERROR: {exc}". str(EOFError('')) is '', so the model was handed:

TOOL_ERROR:

Nothing after the colon. Told its call failed, given no way to tell why, which tool, or whether a retry could help — and the same text went into the trace, so the audit trail couldn't explain it either. The _CALL_SHAPE_ERROR hint just below can't fire on it, since it matches on message text and there is none.

This is a defect shape already closed here once: "a phase the budget curtailed reported nothing at all … wrote [budget_exhausted] with nothing after it." Same empty message, one layer down.

After

clean exit(3)  -> RuntimeError: tool 't' failed: the sandboxed child exited without sending a result, exit code 3
SIGKILL        -> RuntimeError: tool 't' failed: the sandboxed child exited without sending a result, exit code -9 (killed by signal 9)
normal tool    -> returned 'fine'
tool raises    -> RuntimeError: tool 't' failed: ValueError("tool's own bug")

A negative exit code renders as the signal that killed it — which is what tells an OOM-kill apart from a deliberate _exit.

Deliberately still a RuntimeError, not a SandboxViolation. A child dying is not evidence it tried to escape confinement, and a violation is a specific accusation that lands in the trace as one. One of the tests asserts that directly.

Verification

• Three new tests in tests/test_harness_gate.py (parametrised over clean exit and SIGKILL, plus one pinning the signal detail). All go red without the fix, with the EOFError raising out of multiprocessing/connection.py exactly as reported.
• The normal return, tool-raises, and timeout paths are untouched and still covered.
• uv run pytest green · uv run ruff check . clean.

The forked child runs module-level functions rather than closures, since a fork child needs picklable top-level bodies for this to behave the same way under other start methods.

🤖 Generated with Claude Code