V2: subagent/child-session LLM request fails validation — system[4] InvalidType vs LLM.SystemPart #51269

Activity

1. github-actions

   assigned

   jlongster

   on Sep 25, 2026
2. github-actions

   added

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   and removed

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Sep 25, 2026
3. github-actions commented on Sep 25, 2026

   

   github-actionsBot

   on Sep 25, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for updating the issue with the required description, reproduction details, and environment information!
4. famewolf commented on Sep 25, 2026

   

   famewolf

   on Sep 25, 2026

   Author

   More actions

   Update (2026-09-25): default-model resolution, sanitizer infeasibility, scope

   Continued probing on an isolated replica of the same 2.0.16 build (fresh opencode serve on a scratch port, live env replicated, same plugin set, XDG tree isolated) added four facts.

   1. Default model resolution for API-created sessions → built-in opencode/space-bunny-free

   • POST /session without a model pin resolves to opencode/space-bunny-free (built-in zen free model) at execution time — the session object reports model: null at creation; resolution happens later.
   • This occurs even when the config carries model / default_agent defaults — those are ignored for API-created sessions.
   • The resolution is not gated by anything we could find:
     • disabled_providers: ["opencode", "anthropic"] in config: no effect.
     • Stripping ANTHROPIC_API_KEY / ANTHROPIC_BASE_URL / ANTHROPIC_MODEL env: no effect (with ANTHROPIC_MODEL=deepseek-v4-flash-free set, resolution still lands on space-bunny-free).
     • No stored zen credentials exist in the data dir (no auth.json / storage entries).
   • Explicit pin at creation works: {"model":{"providerID":"llama-server","id":"coder"}} (both fields required; id alone → 400).
   • Why it matters for this issue: the Class B failure reproduces deterministically on default-resolved sessions — every unpinned API-created session on 2.0.16 hits Schema validation failed regardless of provider/model config. Any client that creates unpinned sessions (not just OpenChamber's subagents) is affected.

   2. A plugin-side sanitizer is infeasible (index-shift test)

   • A marker plugin pushing a valid {type:"text"} part into event.system inside the context hook does propagate into the final request: the failing index shifted system[4] → system[5] (no-marker runs: 57 consecutive retries failing at [4]; marker runs: 92 consecutive retries failing at [5], marker's post-push array length = 5).
   • Therefore the invalid part is appended by core after all context hooks run — it is always the last system part of the assembled array.
   • No plugin-visible hook exposes the final system array: observed payloads are context [4 valid parts], prompt [no system field], title [1 part]; execution.failed carries no system payload. Hooks also receive separate event copies (one observer saw 4 parts while a concurrent hook's copy already had 5).
   • Conclusion: the invalid part cannot be intercepted or fixed from a plugin; the fix must be in core request assembly. (For reference, the invalid part's content is only visible in the server log's cause payload — {"~effect/SchemaIssue/Issue"…} with Pointer(path=[4|5]) → InvalidType — not in any hook payload.)

   3. Scope refinement

   session type	model	system parts at context hook	result
   main session (UI, pinned)	llama-server/coder	4 valid	works
   subagent child	llama-server/small-model or coder	4 valid	fails system[4]
   API-created, unpinned	resolves to opencode/space-bunny-free	4 valid	fails system[4]
   compaction child	llama-server/small-notools	(same path)	fails (per original report)
   title child	resolves to opencode/space-bunny-free	1	does not fail

   So the invalid part is appended on the child/auxiliary session assembly path (subagent + unpinned API sessions + compaction), while the title child (single system part) and main session pass. Not model-dependent, not provider-dependent, not length-dependent.

   4. Secondary local-model finding (separate from this bug)

   Pinned llama-server/* sessions on a llama-swap -np 1 (single-slot) backend can fail immediately with provider.no-route: Model unavailable when the alias's model is not the currently loaded one — before request assembly at all (no context hook event fires). With a shared single-slot backend this makes even the working main-session model intermittently unroutable for concurrent sessions. Worth a look whether the pre-assembly availability check should trigger a swap/queue instead of a hard no-route.

   Happy to share the probe harness and full log extracts on request.
5. famewolf commented on Sep 25, 2026

   

   famewolf

   on Sep 25, 2026

   Author

   More actions

   Two scope corrections from further testing (2.0.16, same build):

   1. Native auto-compaction is NOT broken — subagent child sessions are.
   GET /api/session/:id/context on a live 2.0.16 server shows a native compaction
   item with status: "completed", reason: "auto", model: llama-server/coder,
   created after the 2.0.16 server started. So the built-in compaction child
   session avoids this issue just like the 1-part title child session. The
   failing class is narrower than the original report said: child sessions whose
   request assembles the full 4-part build system (subagent dispatch, and
   unpinned client sessions that resolve to a model at execution time).
   Main sessions, title, and compaction child sessions all succeed.

   2. /api/experimental/generate is a working bypass for plugin-side work.
   POST /api/experimental/generate with {"prompt": "...", "model": {"providerID": "...", "id": "..."}}
   returns {"data": {"text": "..."}} (200) on 2.0.16 — direct server-side
   generation with no child session, so it cannot hit the assembly path. Without a
   model it 400s ("No model specified and no supported model is available"). There
   is no message-level write API (DELETE/PUT/POST /api/session/:id/message/:mid
   all 404), so plugins can only affect the request (context-hook in-place
   mutation), which is exactly what a working request-level compression plugin
   already does in production.

   Related context for anyone following this: unpinned API-created sessions
   resolve to opencode/space-bunny-free at execution time (previous comment), so
   any client that doesn't pin a model per session (OpenChamber does pin) will
   keep hitting this.
6. famewolf commented on Sep 25, 2026

   

   famewolf

   on Sep 25, 2026

   Author

   More actions

   @/tmp/opencode/issue51269_comment.md
7. rekram1-node commented on Sep 26, 2026

   

   rekram1-node

   on Sep 26, 2026

   Collaborator

   More actions

   are u using any plugins? I dont think this can happen out of the box.
8. famewolf commented on Sep 26, 2026

   

   famewolf

   on Sep 26, 2026

   Author

   More actions

   Yes — I'm running plugins, but I can tell you the root cause is core, not the plugins. I isolated and reproduced it 2026-09-25 on a fresh 2.0.16.

   Plugins in my tree: opencode-auto-resume, smartsnip-fork, sinkhole-guard, lowfat, openslimedit, token-optimizer, @tarquinen/opencode-dcp, opencode-handoff.

   The failure itself is a child/subagent session request-assembly bug in 2.0.16:

   • Symptom: every subagent dispatch (@general, @explore) and native auto-compaction fails at request assembly, BEFORE any model call:
     "Schema validation failed ... InvalidType ... path:["system"][4]"
     (system part index 4 expects LLM.SystemPart {type:"text",text:string} + optional cache/metadata, gets InvalidType).
   • Scope: the main session assembles fine (same server/provider/plugins); 1-part title sessions are fine. Only child sessions built with the full 4-part system hit it, and the bad part always lands at the LAST index.
   • How it occurs: core appends an invalid/extra part as the final system part of the child-session request, AFTER all context hooks run. I proved it is core, not a plugin, with a marker test: a plugin pushing a valid {type:"text"} part into event.system DID reach the final request (the failing index shifted 4->5 on every retry), yet the bad part was re-appended last by core each time. So the invalid part is invisible to every plugin hook (context/prompt/title/execution.failed) and cannot be normalized or dropped from a plugin.
   • Model- and config-independent: pinning the subagent to llama-server/coder does not help; general and explore hit the identical index; disabled_providers and env stripping have no effect.
   • Log: ~/.local/share/opencode-v2/opencode/log/opencode.log, "Failed to drain Session" + the escaped schema-issue JSON.

   Environment: opencode 2.0.16 (desktop AppImage via OpenChamber, managed opencode serve on 127.0.0.1), provider llama-server (local AMD RDNA3 llama.cpp, -c 131072), the 8 plugins above.

   So "out of the box" is right for the main session — but for child/subagent/compaction sessions specifically, a bare 2.0.16 serve with no plugins still assembles the same 4-part system and the same malformed trailing part. Happy to share the exact repro (scratch server + POST /api/session + @general dispatch) and the marker-test harness if useful for a fix.

   — Rudi
9. rekram1-node commented on Sep 29, 2026

   

   rekram1-node

   on Sep 29, 2026

   Collaborator

   More actions

   one of your plugins seems to be corrupting it, try disabling all ur plugins and see if it continues to happen
10. famewolf commented on Sep 29, 2026

    

    famewolf

    on Sep 29, 2026

    Author

    More actions

    You're right, and I was wrong — twice.

    rekram1-node asked on 2026-09-26 whether I was running plugins and said this couldn't happen out of the box. I replied that the root cause was core, and on 2026-09-29 you again pointed at a plugin corrupting the request. I didn't run that test. I went back to static analysis instead, and was still doing it hours later. That's on me.

    It was a plugin. Our plugin.

    plugins/token-optimizer/index.js, in a ctx.session.hook("context", …) callback:

    const PRE_COMPUTE_GUIDANCE = `...`;        // a bare template string
    
    ctx.session.hook("context", async (event) => {
      if (event.system && Array.isArray(event.system)) {
        event.system.push(PRE_COMPUTE_GUIDANCE);   // bare string
      }
    });

    v2 requires a system part to be LLM.SystemPart = { type: "text", text: string }. The file contained zero occurrences of type: "text". Pushing a raw string validated as InvalidType and failed as system[4] InvalidType vs LLM.SystemPart — index 4 because the default build system assembles 4 valid parts first.

    Fixed by pushing the proper shape:

    event.system.push({ type: "text", text: PRE_COMPUTE_GUIDANCE });

    Verified: with all plugins enabled, subagent dispatch now completes (exit=0, child session state="completed"). Confirmed independently by bisection — zero plugins reproduces GREEN, all plugins reproduces the failure.

    My marker test argued against you, and I was wrong to trust it. I pushed a valid {type:"text"} part from a plugin and observed the failure shift system[4] → system[5], then concluded core was appending the invalid part after all context hooks. It wasn't. Hook ordering meant my valid marker landed at index 4 and displaced token-optimizer's invalid string to index 5. The index shift was the signature of a plugin hook, not of core assembly. I read the evidence that exonerated the plugin as evidence that implicated core, and then spent the next several days defending that reading instead of doing the two-minute test you suggested.

    The asymmetry that made this so stubborn also fits perfectly: main sessions and 1-part title children assemble fine, while subagent children — the only sessions that re-run the context hook with the full 4-part build system — fail. Every symptom in my report was real. The diagnosis attached to it was wrong.

    Thanks for the patience, and especially for pushing back twice after I'd confidently told you it wasn't plugins. Nothing is needed upstream — closing as not planned on our side.
11. famewolf

    closed this as not plannedon Sep 29, 2026
12. famewolf

    added a commit that references this issue on Sep 29, 2026

    fix(v2): push a SystemPart, not a bare string, into event.system

    ...

    a5b337b