auto-review: reviewer calls omit x-opencode-session, so every tool call fails closed on OpenCode Go routes

[Daytimeflow]

Follow-up to #5495 (x-opencode-session on OpenCode / OpenCode Go requests). Ordinary agent turns now carry the header through pi-ai's native wrapper — thank you. One auxiliary call path still does not, and because Auto review is fail-closed, it takes the whole session's tool use down with it.

Summary

With the experimental Auto review layer enabled, every reviewed tool call fails while the session's model route is opencode / opencode-go:

Auto review of tool "bash" failed; its body was not executed:
auto-review: reviewer ended with error INVALID_REQUEST: 400:
{"type":"MissingSessionID","message":"Request is missing x-opencode-session and cannot be routed efficiently. Please see https://opencode.ai/docs/go/#where-can-i-use-it"}

It is not only the review that is lost: no tool call can execute at all while the session is on an OpenCode route (observed for bash, read and glob inside one session).

Root cause

@deepseek-ai/dsh-experimental-auto-review builds the reviewer request in classifyRisk() and calls:

const options = deepFreeze({
  provider: snapshot.provider,
  model: snapshot.model,
  system: REVIEW_POLICY,
  messages: [{ role: 'user', content: [{ type: 'text', text: reviewUserText(snapshot) }] }],
  temperature: 0,
  signal,
});
return readDecision(ctx.llm.stream(options));

No sessionId is passed — the string does not occur anywhere in the shipped package. OpenCode's relay requires the per-conversation routing header, and the pi-ai provider attaches it only when the call carries a session id:

// @earendil-works/pi-ai/dist/providers/opencode-headers.js
function withSessionHeader(options) {
  if (!options?.sessionId || hasHeader(options.headers, OPENCODE_SESSION_HEADER)) return options;
  return { ...options, headers: { ...options.headers, [OPENCODE_SESSION_HEADER]: options.sessionId } };
}

providers/opencode.js and providers/opencode-go.js wrap their APIs with withOpenCodeSessionHeader(...), so ordinary turns are fine; the reviewer's hand-built call is the one that loses the header.

The community plugin dsh-opencode-session cannot compensate either: it only covers llm/stream calls that already carry a sessionId — exactly the same condition as the built-in wrapper.

Impact

• Auto review is unusable on any OpenCode / OpenCode Go route.
• Fail-closed turns an infrastructure 400 into a total tool-call outage, which reads to the user as "this session cannot continue".
• Intermittent: header-less requests are sometimes routed anyway, so the failure comes and goes across restarts and is hard to attribute.

Repro

1. Profile with the @deepseek-ai/dsh-experimental-auto-review bundle enabled.
2. Route the session to opencode-go (here: deepseek-v4.1-flash, reasoningEffort: max).
3. Run any tool (e.g. bash).
4. The reviewer request 400s and the tool body is not executed.

Suggested fix

Pass the owning conversation's session id into the reviewer request (e.g. sessionId: agent.session.id at the ctx.llm.stream call site), or let auxiliary LLM calls inherit session identity from the originating session so provider-level routing headers are attached uniformly. A distinct infrastructure-failure message for missing-header 400s would also make this easier to diagnose.

Environment

• DSH desktop app, bundled runtime 0.2.1-rc.2 (hostProtocolVersion 4, Node 24.21.0, pnpm 11.28.5)
• @earendil-works/pi-ai 0.87.1
• Profile bundles include @deepseek-ai/dsh-experimental-auto-review
• Route: provider opencode-go, model deepseek-v4.1-flash

Workaround: disable the @deepseek-ai/dsh-experimental-auto-review bundle, or keep sessions off OpenCode routes.

[PerryLink]

Confirmed on 687f282e86 (0.2.1-rc.2), and the omission is exactly one field.

The call

packages/experimental/auto-review/src/index.ts:624-635:

const options: GenerateOptions = deepFreeze({
  provider: snapshot.provider,
  model: snapshot.model,
  system: REVIEW_POLICY,
  messages: [{ role: 'user', content: [{ type: 'text', text: reviewUserText(snapshot) }] }],
  temperature: 0,
  signal,
})
return readDecision(ctx.llm.stream(options))

No sessionId. The identifier does appear once in the file (:199, senderSessionId), which is a different concept, so your "does not occur anywhere in the shipped package" is right in substance.

The field exists and is already plumbed

• packages/llm/llm/src/types.ts:564 — sessionId?: Branded<'SessionId'> on the request options.
• packages/llm/llm-pi-ai/src/adapter.ts:420 — ...options.sessionId === undefined ? {} : { sessionId: String(options.sessionId) }, forwarded into the pi-ai call.
• In pi-ai 1.1.0/1.3.0, buildBaseOptions carries it (sessionId: options?.sessionId, simple-options.js), and the header itself is created by the OpenCode provider: dist/providers/opencode-headers.js:1 — const OPENCODE_SESSION_HEADER = "x-opencode-session".

So the harness never writes that header; it hands sessionId to pi-ai and pi-ai's OpenCode wrapper converts it. Ordinary agent turns already do this — which is why #5495 is closed and only this path is still broken. The fix is one property in that object literal.

Fail-closed is confirmed too

:705 if (!review.ok) return failed(exec, review.error), and :667-671 is the text you quoted: Auto review of tool "${exec.name}" failed; its body was not executed: ${message}. Any reviewer error therefore blocks the tool call, so a routing 400 takes the whole session's tool surface down. That part of your report is not an inference.

One design consideration before wiring it

:623 states the intent explicitly: "This review prompt is sent only through ctx.llm.stream and never enters a Session log." Passing a sessionId does not put the review into the session log — it only attaches a routing/attribution identity to the request — so it does not violate that comment. But it does change what the review is attributed to, which is worth deciding on purpose rather than as a side effect.

There is a second report on that consequence: the missing sessionId also makes the reviewer's spend unattributable in the cost meter (#9018 independently measured unattributed spend jumping from zero on the day the plugin was enabled). I have not verified the attribution mechanism myself, so take that as their observation, not mine — but if it holds, the same one-field change closes both.

On ordering

If you want a minimal patch: add sessionId first, on its own, and confirm the OpenCode route recovers before touching the cache-hostility side. The two are independent, and the first one is a one-liner that is easy to reason about.

[Mister-Hope]

Is it possible to patch and bypass this ourselves?