[auto-review] Reviewer reuses the persona-injected model route & history → emits prose instead of the JSON protocol → every tool call fails closed (Auto preset unusable under custom personas)

[Lian-peiji]

• Component: @deepseek-ai/dsh-experimental-auto-review (experimental, packages/experimental/auto-review), version seen in the packaged app: 0.2.1-rc.2
• Trigger: Auto permission preset (auto-authorization reviewer) + a session whose context carries a strong persona/instruction injection (memory plugin / custom system prompt)
• Severity: High for affected users — it makes the entire Auto mode unusable (every tool call is rejected before its body runs), and the failure is silent to non-technical users.

TL;DR

The Auto reviewer is instructed to return exactly one JSON object (REVIEW_POLICY), and the response is parsed with a strict JSON.parse in parseDecision. But classifyRisk:

1. sends the review request through the current session's own model route (provider/model come straight from session.requestHeader()), and
2. includes the session's raw user-message history in the FILTERED_HISTORY section — including persona / memory injections that are tagged as human-instruction.

When the active model route has a strong persona system context (here: a Chinese "whale-girl maid" persona with 只输出简体中文 / "reply in Simplified Chinese only" / self-referential roleplay), that persona overrides the JSON-only output contract. The reviewer replies in in-character Chinese prose, JSON.parse throws on the very first CJK token, readDecision → parseDecision throws, classifyRisk rejects, and the gate returns:

Auto review of tool "<name>" failed; its body was not executed: Unexpected token '本', "本鲸先把真实启动路径"... is not valid JSON

Because a reviewer failure is materialized as kind: "deny", the tool never executes and the whole task stalls — not because the action is dangerous, but because the judge was role-playing.

Exact code path (from packages/experimental/auto-review/src/index.ts @ master)

• REVIEW_POLICY — fixed system text; correctly says "Return exactly one JSON object and no other text" and "never by … message tone". This is fine.
• classifyRisk() builds GenerateOptions:

  provider: snapshot.provider,   // == session.requestHeader().config.provider
  model:    snapshot.model,      // == session.requestHeader().config.model  ← SAME route as the main agent
  system:   REVIEW_POLICY,
  messages: [{ role: 'user', content: [{ type: 'text', text: reviewUserText(snapshot) }] }],
  temperature: 0,

  → the reviewer shares the main agent's model route, so whatever persona/LANG_ZH_CN_ONLY behavior that route exhibits leaks into the reviewer.
• snapshotAutoReview() → filteredUserEntries() pushes every non-tool user/message into history, and textRole() classifies real human user messages as human-instruction. Persona/memory content delivered as user-role context is therefore fed to the reviewer as an authoritative instruction.
• reviewUserText() serializes snapshot.history verbatim into the FILTERED_HISTORY section.
• readDecision() → parseDecision():

  const value = JSON.parse(text)   // throws SyntaxError on non-JSON / prose

  The thrown error becomes the failure message, and:

  function failed(exec, error) {
    return { kind: 'deny', reason: `Auto review of tool "${exec.name}" failed; its body was not executed: ${message}` };
  }

Observed evidence (this session)

Repeated pwsh/ops_bash calls all returned Auto review … failed; its body was not executed: Unexpected token '<CJK>', "<persona prose>"... is not valid JSON, with a different in-character Chinese sentence each time (本鲸 / 呜 / 主人别急 / 好的主人 …), confirming it is live model output being role-played, not corrupted static data. Setting the approval policy to never (which bypasses this reviewer gate entirely) made the identical call succeed immediately — isolating the gate as the cause.

Why it matters

• The failure is fail-closed: an ambiguous judge silently blocks legitimate, user-authorized work. The user sees no "reviewer" concept, just tools mysteriously refusing to run.
• Custom personas / system-prompt layers are a first-class, encouraged DSH feature (memory plugins, dsh-plugin, etc.). Auto mode silently breaks for any user using them.
• The error surfaces only as a SyntaxError string; there is no retry, no "output wasn't JSON" re-prompt, and no fallback.

Suggested fixes (any one helps; 1+3 together are robust)

1. Don't reuse the main route for the reviewer. Send classifyRisk through a dedicated, neutral authorization route (own provider/model, no session persona). The reviewer is a mechanical judge; it must not inherit role-play.
2. Filter persona/style context out of FILTERED_HISTORY. Style/instruction injections are irrelevant to effect-based risk classification. Either drop agent-instructions/persona blocks that aren't genuine human turn text, or tag them with a role (e.g. style-context) that the policy explicitly states must not affect output format or tone.
3. Make decision parsing robust to prose. Before JSON.parse, extract the first balanced top-level JSON object from the text (tolerate leading/trailing prose). Only treat it as a hard failure if no parseable object exists.
4. On non-JSON output, re-prompt once with a tightened "you returned non-JSON; output ONLY the JSON object" follow-up instead of failing closed on the first slip.
5. Prefer native structured output (provider JSON-schema / constrained tool-call) over a prose protocol, so tone can't bleed into the response.
6. Distinguish "reviewer failed" from "reviewer denied" in UX/logging — today both read as tool denial to the user, hiding a judge-side bug as a permission problem.

Repro

1. Enable the Auto permission preset (auto-authorization reviewer).
2. Load a strong persona with an explicit "reply only in one language, in character" instruction (e.g. via a memory/plugin system-prompt layer).
3. Ask the agent to run any tool (even a read-only pwsh Get-ChildItem).
4. The reviewer returns in-character prose; the call is rejected with Auto review of tool "…" failed; … is not valid JSON, and the tool body never runs.
5. Switching approval to never (bypassing the gate) makes the same call succeed.

Environment: Windows 11, DSH Desktop build (packaged app.asar), reviewer plugin @deepseek-ai/dsh-experimental-auto-review@0.2.1-rc.2.

[PerryLink]

Both halves check out, and they are separate causes that happen to meet in the same call.

The route is the session's: classifyRisk passes provider: snapshot.provider and model: snapshot.model (packages/experimental/auto-review/src/index.ts:625-626), and snapshotAutoReview takes them from the session's request header. So whatever persona or language policy that route carries is in play for a request that must emit one bare JSON object.

The history is real too, which is the part I would not have guessed from the call site alone: reviewUserText renders a FILTERED_HISTORY section (:529), fed by filteredUserEntries (:242) and pushed at :436. So the reviewer does see user-message excerpts, including anything a memory plugin or a custom instruction injected as a user turn. Combined with a route that says "只输出简体中文" or role-plays, the strict JSON.parse in parseDecision (:611) has nothing to fall back on.

Two fixes, in order of how much they buy:

1. Give the reviewer its own route. The request is a classification task with a fixed output contract; inheriting the conversation's persona is a category error. A provider/model pair in the auto-review config, defaulting to the session route, would fix the reported failure for anyone who sets it.
2. Make the parse recoverable. Today one non-JSON reply ends the review, and the tool call is denied. A single repair turn — send the model its own text plus "return only the object" — would absorb the tail of cases that a route change does not.

The second one matters even without personas: a model that prepends "Sure," is enough to fail this, and the user experiences it as Auto being broken rather than as one malformed reply.