🐛 harness: log the agent's closing message and goose's error.data

[ibolton336]

What

Two pod-log gaps in the harness, both found on the same day from one teammate's runs:

• prompt error -32603: Internal error with no reason. goose puts the cause in JSON-RPC error.data (e.g. Error getting agent reply: Provider not set); the harness parsed and dropped it. RPCError.Error() now appends Detail() (string data unquoted, other JSON compacted) and SendPrompt/WSClient.Call wrap it with %w, so the log reads
  prompt error -32603: Internal error — Error getting agent reply: Provider not set
  and callers can errors.As on the *RPCError. The partial PromptResult is returned alongside the error.
• The model's words were never recorded. Assistant text went into PromptResult.Chunks and nowhere else; the live transcript is in the tee and dies with the pod. A run whose result was text (an answer, a question back to the user, a summary) ended stage succeeded — no changes to push with no trace. The harness now keeps the closing message — the agent messages after the last tool_call (or the latest human steer), one entry per goose message — and logs it after the turn (INFO, truncated at 4000 runes, secrets redacted). goose's own status notices (_goose/unstable/session/update status_message/notice, e.g. Unable to continue: Context limit still exceeded after compaction) are recorded and logged too.
• Provider failures hidden as prose. goose 1.45 reports provider errors as assistant messages (Ran into this error…, The provider refused this request., …Please resend your message to try again., The model returned an empty response.) and ends the turn normally, so a run that never reached the model reported success. When the closing message is one of those (matched anchored to the message, so an agent quoting the phrase is not mistaken for a failure), it is logged as WARN and attached viewers get a notice. Credits exhaustion is not in the list: over ACP goose turns it into the session/prompt RPC error, which the first change now prints.
• Max turns is now decided before the tripping tool_call is handled, so the narration that introduced it survives as the closing text instead of an always-empty "none".
• Redaction. Logging model prose opens a channel that did not exist; goose inherits the harness's environment. Every credential-looking env value (SECRET|TOKEN|PASSWORD|API_KEY|ACCESS_KEY|CREDENTIALS names, ≥ 8 chars) plus the API key, hub token, ACP secret and git token the harness holds are replaced with [redacted] in the closing message, notices and prompt errors.

Exit status is unchanged on purpose: a provider failure rendered as prose still exits 0 (README bullet updated to say so). Flipping that belongs with the Succeeded condition work in #119.

Verification

• gofmt, go vet, go test ./... green. New tests: TestRPCErrorCarriesData (jsonrpc_test.go), TestSendPromptErrorIncludesGooseDetail (partial result + errors.As), TestSendPromptMaxTurnsKeepsClosingText, TestPromptResultFinalMessageFollowsLastToolCall (message boundaries, steer reset), TestPromptResultKeepsGooseNotices, TestLooksLikeProviderError (anchored, per-message), redactor tests.
• E2E on a minikube rig (agentic-controller + Agent Sandbox + Bedrock gateway), agent-base built from this branch, runs created through the Hub API with the console's payload:
  • normal run → pod log ends with agent closing message: followed by the model's text;
  • Gateway with a nonexistent model id → after goose's six retries: WARN agent closing message is goose's provider-error text … ValidationException … The provided model identifier is invalid. Before: only stage succeeded — no changes to push;
  • run with a fake TEST_API_KEY_SECRET in spec.env and instructions to print it → [redacted] in the pod log.
• Wire shapes checked against goose v1.45.0 (crates/goose/src/agents/agent.rs reply loop, crates/goose/src/acp/server.rs message_update_meta, send_status_message_update, prompt_error_from_message_content).

Context

Seen 2026-08-21: a console-created run on a Vertex gateway whose Secret lacked GCP_PROJECT_ID died at the first prompt with a bare -32603; and a run whose instructions asked the model a question ended Succeeded with nothing to show — the model had answered "Round 1/10: Tell me something." and stopped.

🤖 Generated with Claude Code

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: a1405c12-617f-4192-9662-7f7d681aa7c6

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[djzager]

Surfacing goose's error.data and the closing message is exactly what was missing for debugging dead runs — nice.

Agreed on keeping exit status out of scope here; no new issue needed since the deferred half is already tracked:

• Harness: limit enforcement, mode env translation, and the exit-code contract #118 (harness) is the emit side of the exit-code contract — exit 2 on wind-down + write the usage blob to /dev/termination-log.
• Run outcomes: refusal and no-op must not report bare Succeeded #129 is the provider-failure / refusal / no-op case: prose rendered as an assistant message must not report a bare Succeeded. The anchored looksLikeProviderError detection you add here is a good signal to drive that.

The controller half is landing in #169 (ADR 0018): it reads the container exit code (0/1/2 → Succeeded/Failed/LimitReached) and the termination message into status.terminationData. So once #118 emits exit 2 + the blob, #169 consumes it end-to-end — nothing to change in this PR.

One note for whoever picks up #118: the harness currently only does os.Exit(1), so LimitReached is unreachable until the exit-2 path lands. Worth sequencing #118 after #169 so it implements against the merged contract.