feat(terminal): interpret signal-termination exit codes (port from kilocode#12698)

[teknium1]

Summary

The terminal tool now tells the model why a command died when it was killed by a signal — exit_code=137 gets an exit_code_meaning note naming SIGKILL and the likely OOM cause instead of leaving the model to burn turns re-running and mis-diagnosing.

Ported from Kilo-Org/kilocode#12698 ("settle signal-terminated shell commands as 128 + signum"). Kilo's bug was a hang because their spawner produced no numeric code on signal death; Hermes already produces numeric codes (Python subprocess -signum, or the shell's 128+signum), so the adaptation targets the remaining gap: the model can't read them.

Changes

• tools/terminal_tool.py: new _interpret_signal_exit() wired into _interpret_exit_code() ahead of the per-command semantics table.
  • Negative codes (definite signal death from subprocess) → "Command terminated by signal N: …" for a curated table (SIGKILL/SIGSEGV/SIGTERM/SIGABRT/SIGBUS/SIGFPE/SIGPIPE/SIGQUIT/SIGILL/SIGXCPU/SIGXFSZ), generic fallback for uncurated signums.
  • 128+signum band (shell convention, ambiguous — a program can exit 139) → hedged "usually means…" note, curated signals only; uncurated codes stay silent so legitimate application exit codes are never mislabeled.
  • SIGINT excluded on both paths — rc=130 already has bespoke interrupt-marker handling in the executor.
• tests/tools/test_terminal_signal_exit.py: 26 tests covering both encodings, exclusions, hedging, and precedence over the command-semantics table (a SIGKILLed grep reports the signal, not "no matches").

Validation

	Before	After
python3 SIGSEGV (real process, E2E)	exit_code: 139, no note	exit_code_meaning: Exit code 139 usually means … SIGSEGV (segmentation fault…)
bash -c 'kill -9 $$' (E2E)	exit_code: 137, no note	… SIGKILL — often the kernel OOM killer …
grep no-match / diff / existing semantics	unchanged	unchanged (56/56 targeted tests pass)

E2E was run through the real terminal_tool() with an isolated temp HERMES_HOME and genuinely signal-killed processes, not mocks.

Architectural notes

• Kilo's change sits in their process spawner (Effect/Node); Hermes' equivalent gap was presentation, so the port lands in the existing exit-code semantics tier (_interpret_exit_code) — zero new tool surface, no behavior change for non-signal exits.
• Notes ride the existing exit_code_meaning field the model already knows from grep/diff semantics.

Infographic

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 8de5cb3 — feat(terminal): interpret signal-termination exit codes for}

⚠️ Warnings

CI timings · View report · View job

Wall time 25m13s vs 8m (+215.2%). 10 job(s) slower, 12 faster, 2 unchanged.

• Python tests / Run tests slice 1/12: +51.0s
• Python tests / Run tests slice 7/12: -39.0s
• Python tests / Run tests slice 4/12: -31.0s
• Python tests / Run tests slice 6/12: -25.0s
• Python tests / Run tests slice 2/12: -21.0s

---

OSV vulnerability scan · View job

5 known vulnerabilities found in pinned dependencies.

• CVE-2026-67213 in package-lock.json
• CVE-2026-67213 in website/package-lock.json
• CVE-2026-70608 in package-lock.json
• CVE-2026-56876 in package-lock.json
• CVE-2026-70606 in package-lock.json

How to fix:

Review the findings in the Security tab. Update the affected dependencies if a patched version is available.