hermes - 💡(How to fix) Fix [--tui] gateway exits 0 mid-turn when memory.provider: byterover (SIGPIPE flood, then exit_group(0)) [2 comments, 1 participants]

Summary

In --tui mode with memory.provider: byterover configured, the python gateway process exits cleanly (exit_group(0)) mid-turn on almost every prompt submission. The TUI surfaces this as gateway exited and the session is unusable.

Switching memory.provider: '' (built-in memory only) makes the crashes disappear completely. Same hardware, same prompts, same provider, same everything else.

Environment

• hermes-agent: 0.10.0 @ 77e04a29 (fix(error_classifier): don't classify generic 404 as model_not_found (#14013))
• OS: Arch Linux, kernel 6.19.10
• Python: 3.14.4
• Node: v25.2.1
• LLM provider: copilot
• brv CLI installed and working (manual brv_query / brv_curate from agent succeed)

Reproduction

1. Configure memory with byterover plugin:

   memory:
     memory_enabled: true
     provider: byterover
     provider_config:
       auto_extract: true

2. Launch hermes --tui.
3. Submit any prompt.
4. Within a turn or two, the TUI shows gateway exited. Often on the very first turn.

What agent.log shows

• A gateway exited line, no exit code, no traceback.
• No OOM, no signal kill recorded.
• tui-stderr.log is empty — no python-level crash.

What strace shows

strace -f -e trace=signal,exit_group -p <gateway-pid> while reproducing:

• A flood of SIGPIPE on the python child (it's trying to write to a pipe that's been closed on the other end).
• Then a clean exit_group(0) — the python gateway voluntarily shuts down as if it received an EOF/shutdown signal on stdin.

So: nothing kills the python process. The python process loses its parent-side pipes (stdout SIGPIPE, then stdin EOF) and exits 0 like it was told to.

What I do not know (being honest)

I did not trace the exact code path inside the byterover memory provider that triggers this. I only have the trigger correlation:

• memory.provider: byterover → reliable mid-turn crashes.
• memory.provider: '' → zero crashes across many prompts in the same session shape.

So this could be:

• A bug in the byterover plugin's hook (slow response, wrong protocol message, child subprocess interfering with gateway pipes).
• A bug in ui-tui/src/gatewayClient.ts reacting badly to whatever byterover sends/takes/returns.
• An interaction (timing / payload size / async ordering) between the two.

The user-visible fact is: byterover-as-memory-provider in TUI mode makes the python gateway lose its pipes to the Node parent and exit.

Workaround

memory:
  provider: ''     # was: byterover

Built-in memory continues to work. brv CLI is unaffected — manual brv_query / brv_curate from the agent still succeed (they shell out directly, not through the memory provider plugin). on_session_end byterover-commit hooks also continue to work (they fire after the gateway is already done).

Useful follow-ups

• Add a try/except around the byterover prefetch path in the gateway so a misbehaving memory plugin can't take the whole session down.
• Log the EOF / SIGPIPE event in the gateway (exit_group(0) after SIGPIPE flood, last activity: <hook>) so this kind of failure isn't silent next time.
• Decide whether gatewayClient.ts should ever close the python child's stdin during an active turn — if the answer is "no", whatever is doing it is the bug.

Happy to run more diagnostics (full strace with more syscall categories, instrumented byterover plugin, ui-tui debug logs) if useful — just point me at what would help most.