fix(oneshot): don't swallow stderr on failure; enable faulthandler

[fabiosiqueira]

Summary

hermes_cli/oneshot.py:run_oneshot redirects both stdout and stderr to /dev/null for the entire _run_agent call tree. This keeps the success path quiet (the original goal) but discards every diagnostic when something goes wrong:

• C-level crash inside a native extension → process dies with SIGSEGV, exit 139, zero output (no Python traceback, no faulthandler trace, no last-log-line).
• Unhandled Python exception inside the agent → traceback printed to the redirected sys.stderr, never reaches the operator (the exception object propagates, but anything the agent wrote to stderr along the way is gone).
• Empty-response return (provider returned empty content, retries exhausted with no usable text, etc.) → exit 0 with empty stdout, no clue what happened.

This was concretely felt while debugging #29021 — the only symptom of a pydantic-core thread segfault was hermes -z "ping" returning empty stdout. Adding a single print was the only way to learn the process had been SIGSEGV'd at all.

What this PR changes

run_oneshot keeps the silent-on-success behavior but stops discarding diagnostics on failure:

1. faulthandler.enable(file=sys.stderr, all_threads=True) is wired before the redirect block. contextlib.redirect_stderr only swaps sys.stderr (Python-level); faulthandler holds the underlying fd, so a C-level SIGSEGV/SIGABRT stack still reaches the operator's terminal.

   Caveat: Rust PyO3 panics that call libc abort() cannot be caught by faulthandler — those still die mute. This catches everything else: numpy aborts, ctypes mis-calls, double-frees, openssl issues, etc.

2. Redirected stderr → SpooledTemporaryFile instead of /dev/null. On any exception escaping _run_agent, the tail of that buffer is written to the real stderr before the exception propagates. On an empty-response return, the tail is also surfaced with an explicit hermes -z: empty response; stderr tail follows: header.

The happy path is unchanged: stdout = final response, stderr = empty.

Test plan

Validated end-to-end in the Hermes venv (Linux x86_64 musl, Python 3.11.15):

• Happy path: hermes -z "responda apenas 'pong'" --model openrouter/owl-alpha --provider openrouter → stdout=pong, stderr=0 bytes, exit 0. Identical to current behavior.
• Python exception path: monkey-patched _run_agent to write to sys.stderr and then raise. With this PR, the stderr write reaches the operator (instead of being swallowed) and the exception propagates as before.
• SIGSEGV path (pydantic-core 2.41.5 + Responses API + thread): still dies hard with no output — Rust abort() is uncatchable by faulthandler. Acknowledged in commit message; the dep bump in fix(deps): bump pydantic to 2.13.4 to avoid pydantic-core thread segfault #29021 is what fixes that particular crash, not this PR.

Platforms tested

• Linux 6.8.0 x86_64, musllinux (Alpine container), Python 3.11.15

Related

Companion to #29021 (pydantic bump). #29021 fixes the specific crash; this PR fixes the diagnosability gap that hid the crash and turned a 30-second triage into a multi-hour investigation.

🤖 Generated with Claude Code

[fabiosiqueira]

Closing as superseded by #30623, which lands a fix for the same silent-failure problem (agent exceptions/empty responses no longer exit 0 quietly). The remaining delta here — faulthandler for native crashes and surfacing the captured stderr tail rather than just str(exc) — is marginal now that the core is covered upstream, and #30623's author already settled on their approach for this path, so I'd rather not carry a competing PR. Dropping it from our fork too. Thanks.

— 🤖 Claude Opus 4.8