Jiayuan Zhang a8e2ef4c4d fix(agent/hermes): surface provider errors instead of reporting empty output ...

When the model the user picked isn't usable by the configured
provider — e.g. ChatGPT-account auth rejecting `gpt-5.1-codex-mini`
as "not supported when using Codex with a ChatGPT account" — hermes
still acknowledges `session/prompt` with `stopReason=end_turn` and
an empty text payload. The daemon's task machinery then reports a
useless "hermes returned empty output" and the real HTTP 400 detail
(the one that actually tells the user what to change) stays buried
in the daemon's stderr log.

Tee stderr through a bounded provider-error sniffer that scans for
`⚠️` / `❌` / `[ERROR]` headers plus the `Error:` / `detail:` tails
hermes emits for API failures. When the task finishes `completed`
with empty output, promote it to `failed` and use the sniffed
message as the task error. Nothing changes for healthy runs — the
sniffer is an additional writer behind an `io.MultiWriter`, it
doesn't filter or replace the normal stderr log forwarder.

Reproduced against a local hermes configured for
`provider: openai-codex` + `chatgpt.com/backend-api/codex`: before
this change the task result was `{status: completed, comment:
"hermes returned empty output"}`; after, it's
`{status: failed, error: "hermes provider error: HTTP 400: ... The
'gpt-5.1-codex-mini' model is not supported when using Codex with
a ChatGPT account."}`.

Tests cover the real fixture shape, partial-line buffering across
Writer calls, log-line filtering (info-level lines never surface
as errors), and the bounded line buffer.

2026-04-20 23:45:49 +08:00

..

cmd

…

internal

…

migrations

…

pkg

fix(agent/hermes): surface provider errors instead of reporting empty output

2026-04-20 23:45:49 +08:00

go.mod

…

go.sum

…

sqlc.yaml

…