opencode run: intermittent sub-second UnknownError whose error ref is never written to the log

Summary

opencode run intermittently exits non-zero within ~1 second, printing only:

Error: {
  "name": "UnknownError",
  "data": {
    "message": "Unexpected server error. Check server logs for details.",
    "ref": "err_d6a5e0a7"
  }
}

The message says to check the server logs, but the ref never appears in them.
grep for any of the refs I collected (err_d6a5e0a7, err_66476d67,
err_2a03eba9, err_ca4d7c1b, err_1269132f) across
~/.local/share/opencode/log/opencode.log returns nothing, and there is not a
single level=ERROR line anywhere in the wall-clock window in which the failures
occurred. So the one diagnostic the error hands the user leads nowhere.

Version: 1.18.31, macOS (darwin, arm64).

Impact

This is being driven by an orchestrator that spawns opencode run repeatedly for
a multi-phase pipeline. A sub-second, non-zero exit is indistinguishable from a
genuine agent failure to the caller, so an automated wrapper classifies the phase
as failed and discards it. Over one afternoon this cost roughly 15 discarded
phases, several of which had complete work on disk.

Observed behavior

• Failures cluster. Long clean stretches, then runs of 6-10 consecutive
  failures, then it recovers on its own with no intervention.
• Failure is always sub-second, well before any model call could return.
• Not reproducible by hand. During a cluster in which every orchestrated
  spawn failed, running the byte-identical command manually (same cwd, same
  agent, same model, same prompt read from the same file) succeeded immediately,
  repeatedly.
• Not prompt content or size. Ruled out by bisection: a 4.4 KB operator note
  and a 143-byte one failed identically, and piping the exact same 4.4 KB text
  through opencode run --auto --agent <name> by hand succeeded.
• Not model or agent specific. Seen on two different agents and two
  different models (claude-opus-4.8, gpt-5.6-terra). The same prompt hash
  failed and then succeeded minutes apart, which rules out a deterministic
  content trigger.
• Not concurrency, or at least not only that. Failures continued after every
  other concurrent run had exited, and one spawn succeeded while another pipeline
  was mid-flight.

What I could not determine, and why

I could not get past "the server returned a 500" because the ref is not
greppable and nothing is logged. That is the actual blocker for producing a
tighter report, and it is why I am filing the observability half rather than a
root cause.

Asks

1. Log the error that produced the ref. If the server returns
   UnknownError with ref: err_XXXX, that ref and its underlying exception
   should be written to the log the message points the user at. Right now the
   instruction "Check server logs for details" is not actionable.
2. Distinguish transport/startup failure from agent failure in the exit
   contract. A caller currently cannot tell "the run failed" from "the run
   never started". A distinct exit code, or a machine-readable marker on stderr,
   would let wrappers retry the second case instead of discarding work.
3. Consider a bounded internal retry when the failure occurs before any session
   is established, since it appears to be a startup/connection-class fault
   rather than anything to do with the requested work.

Happy to gather more if you can tell me where the server-side detail for a given
ref is supposed to land, or how to raise the server log level for run.

Start by reproducing the intermittent opencode run failure and tracing where the UnknownError ref is created, where server logs are written, and how the CLI reports startup failures. Use the reported refs and ~/.local/share/opencode/log/opencode.log to verify the diagnostic path. Done means the ref and underlying error are discoverable, and callers can distinguish a run that never started from an agent failure.