v0.18.9 ships always-on sdk-raw-capture (refs hermes-agent#138) that emits a [hermes-diag] sdk RAW body[:4000]: ... line per streaming chunk + pre-parse line per chunk + normalize_response entry/exit per call. With streaming + multiple chunks per response, this produces dozens of multi-hundred-byte diagnostic lines per dispatch.

Symptom (observed in sandbox)

Even with hermes 2>/tmp/sandbox_stderr.log (stderr redirected away from terminal), the [hermes-diag] lines still appear in the tmux pane, interleaved with model output. They overwhelm progress bars + the actual model response so the operator sees visual chaos rather than the model's final text.

This suggests _diag() writes to stdout (not stderr), OR hermes TUI re-renders the stream inline regardless of redirect.

Ask

• Audit where _diag() writes (sys.stderr vs sys.stdout)
• Env-gate the raw-capture: HERMES_DIAG_RAW_CAPTURE=0 to disable (default OFF in v0.18.10; ops can flip ON when debugging)
• Keep the normalize_response entry/exit + conv-loop diagnostics ON by default — those are cheap (1 line each, fire once per turn). It's the per-chunk raw-body capture that floods.

Repro

Run any prompt through sandbox post-v0.18.9 install. Streaming responses with >5 chunks make the pane unreadable. /tmp/probe4.txt-style probes still WORK functionally, but the operator can't see clean output.

Severity

Low — purely cosmetic/operator-experience. v0.18.9 functionality is correct + the diagnostic chain it enabled was what found the streaming bug. This is just about default verbosity post-debug.