ai: OpenAI Chat tool-content guard aborts session drain without identifying the offending part #55271

Activity

1. opencode-agent commented on Oct 14, 2026

   

   opencode-agentBot

   on Oct 14, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report and for pointing to the exact guard. You're right that the check in lowerToolMessages (packages/ai/src/protocols/openai-chat.ts) is still in the v2.0.28 tag, and its error doesn't say which message or part failed.

   We can't reproduce this yet, because nothing in the report shows what put a non-tool-result part into the tool message. That could be core or one of the plugins. Could you add:

   1. Provider and model used on the OpenAI Chat route (for example an OpenAI-compatible provider ID and model ID).
   2. Does it happen on a stock 2.0.28 build with plugins disabled? If it only happens with plugins, try turning them on one at a time. OMO, context-mode, Meridian and the OpenCode Claude provider are the ones most likely to rewrite message history.
   3. The content types in the failing request: for each message, its role and the type of each content part (no text or email content), especially the content type of the part in the tool message that fails. Even one failing message/part pair would help.
   4. Whether every later prompt in that session fails, or only that one.

   You can reply here with the details, or edit the issue. If you edit it, please also leave a comment saying you've updated it so we know you're done.

   Related issues I found, ordered by how likely they are to cover your problem (none matches this exact error):

   • Failed to drain Session: one malformed tool result wedges the whole session #50775 / fix(core): degrade malformed tool-result content instead of crashing prepare #50776: one malformed tool result breaks the whole session during core preparation (not-an-array tool-result value)
   • a tool result with a file type other than image or PDF makes every later request in the session fail #54798: a tool result with an unsupported file type makes every later request fail
   • mcp: binary file attachment in tool result permanently breaks the session #52448: a binary MCP attachment in a tool result permanently breaks the session
   • session: provider image rejection bricks session — generic 400 error, no recovery path #52042: a provider rejection breaks the session with no way to recover
   • Per-request context tail truncation splits tool-call groups, causing HTTP 400 invalid_request (session stuck on every turn) #53109: context truncation splits tool-call groups and leaves the session stuck
   • bug(llm): cross-provider tool-call IDs can exceed OpenAI-compatible length limit and permanently break sessions #54146: cross-provider tool-call IDs permanently break OpenAI-compatible sessions
2. opencode-agent

   added

   triaging

   on Oct 14, 2026
3. mradwankhalil commented on Oct 14, 2026

   

   mradwankhalil

   on Oct 14, 2026

   ContributorAuthor

   More actions

   Follow-up to the four diagnostic questions:

   1. Provider/model: I scanned the retained backend log for provider/model fields correlated with this session before the exact error timestamp. None were logged, so I cannot responsibly name an exact provider/model from the OpenAIChat.fromRequest stack alone. That stack identifies the lowering route, not a provider ID.
   2. Stock/plugins disabled: not tested yet. The guard is byte-for-byte present in stock v2.0.28, but that does not establish that stock core produced the offending message. The observed backend had local runtime patches and the listed plugins. No plugin is implicated by the current evidence.
   3. Role/part types: not captured. The only discriminants established by this exact predicate are tool-message lowering and at least one top-level part not supported as tool-result. It does not tell us whether the offending part was text, media, or another variant. I will not infer a MIME error or publish email history. The useful next diagnostic is role/index/type-only instrumentation before compilation, followed by a redacted boundary replay and plugin-disabled isolation.
   4. Later prompts: the retained log establishes one failed drain at 2026-10-13T22:18:58.032Z. The workflow's sends failed, but I have not established that every later prompt in the same session repeats this exact error. The issue deliberately does not claim a permanent wedge.

   For now this is blocked on capture/isolation, not a ready-to-merge fix. The independently supported improvement is diagnostic context for unsupportedContent plus a safe recovery path that preserves call/result pairing. Please do not treat the source-level negative-test recipe as an end-to-end reproduction of the real producer.
4. opencode-agent commented on Oct 14, 2026

   

   opencode-agentBot

   on Oct 14, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the careful follow-up. Agreed: the guard being in stock v2.0.28 doesn't show where the tool message came from, and calling OpenAIChat.fromRequest directly isn't an end-to-end reproduction. Without the source, or at least the part type and a stock/plugins-off run, we can't reproduce this. The issue stays open for that, and your suggestion to add the message/part index and content type to the unsupportedContent error is noted for maintainers.

   If it helps with the capture, the V2 context session hook gives a plugin the exact messages array that gets lowered for the model call, so you can log only roles, indexes and part types:

   import { Plugin } from "@opencode/plugin"
   
   export default Plugin.define({
     id: "tool-shape-log",
     setup: async (ctx) => {
       await ctx.session.hook("context", (event) => {
         const offending = event.messages.flatMap((message, m) =>
           message.role === "tool"
             ? message.content
                 .map((part, p) => ({ m, p, type: part.type }))
                 .filter((entry) => entry.type !== "tool-result")
             : [],
         )
         if (offending.length === 0) return
         console.error("[tool-shape-log]", JSON.stringify({
           session: event.sessionID,
           model: event.model, // provider + model IDs, no content
           shape: event.messages.map((message, m) => ({ m, role: message.role, types: message.content.map((part) => part.type) })),
           offending,
         }))
       })
     },
   })

   Caveats: I couldn't type-check or run this here, so treat it as a starting point. It also only sees the messages as they are when the hook runs. If nothing is logged but the drain still fails, the bad part is being added after this hook, which narrows down where it comes from too.

   Once you have one of these, please post it here:

   • the provider/model IDs and the offending entry (message index, part index, part type), or
   • whether it still happens on stock 2.0.28 with plugins disabled.

   This issue will be closed automatically on 2026-10-17 if nothing new comes in. If that happens before you've captured it, feel free to open a new issue with the captured details and link this one.
5. mradwankhalil commented on Oct 14, 2026

   

   mradwankhalil

   on Oct 14, 2026

   ContributorAuthor

   More actions

   Additional capture from the reporter's machine (read from the local session store; no message contents included).

   • Provider/model of the failed compile: opencode-go/deepseek-v4.1-flash (OpenAI-chat-compatible routing). The failed drain (2026-10-13T22:18:58.032Z) followed an ordinary, completed shell tool result; the assistant message for that drain persisted empty, then the session went idle.
   • No persistence: the next prompt in the same session — 96 seconds later — compiled and answered normally, and every later prompt that night succeeded. In this occurrence the offending element was transient to that single compile, not a persistent history wedge.
   • Tool-part census of that session: 2,676 tool parts, all type: "tool". state key shapes: {content,input,metadata,status} ×2606; {error,input,status} ×49; {error,input,metadata,status} ×11; {content,error,input,metadata,status} ×9; {input,metadata,status} ×1 — the last is an in-flight running call (transient by design). Errored parts (state.error) exist across the session's lifetime, but the nearest one to the failure predates it by ~24 h, so the timeline does not point at an errored part.
   • A stock/plugins-disabled reproduction is not possible retroactively for a one-off event; if it recurs, we will capture message/part indices with the context session hook you suggested.
6. opencode-agent commented on Oct 14, 2026

   

   opencode-agentBot

   on Oct 14, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the capture, it's very useful. Since the next prompt 96 seconds later and every prompt after it worked, this was a one-off failure, not a stuck session, so there's nothing we can reproduce right now.

   One thing it does narrow down: in stock code, core builds tool-role messages only from tool results (Message.tool in packages/core/src/session/runner/to-llm-message.ts, and the missing-result filler in packages/ai/src/tool-history.ts). A non-tool-result part in a tool message most likely came from something that edits the messages after core builds them: a plugin using the session context hook, or one of the local patches. I haven't confirmed which, but the logging hook from my previous comment should catch it if it happens again.

   So I'm treating what's left as an improvement request: when the OpenAI Chat lowering rejects a tool-message part, the error should give the message index, part index and part type, ideally at a point that shows which step or plugin added it, instead of only a generic failed drain. Maintainers will consider it; no promises on whether or when. A plugin can detect and log bad parts, but it can't change that error message, so this needs a change in core.

   If it happens again and you capture the offending indexes/types, or find which plugin adds the part, please post them here or in a new issue.

   Related (different causes):

   • Failed to drain Session: one malformed tool result wedges the whole session #50775 / fix(core): degrade malformed tool-result content instead of crashing prepare #50776: a malformed tool result breaking session preparation
   • a tool result with a file type other than image or PDF makes every later request in the session fail #54798, mcp: binary file attachment in tool result permanently breaks the session #52448: unsupported media inside tool results
   • session: provider image rejection bricks session — generic 400 error, no recovery path #52042: a provider rejection with no way to recover
7. opencode-agent

   removed

   triaging

   on Oct 14, 2026
8. mradwankhalil commented on Oct 15, 2026

   

   mradwankhalil

   on Oct 15, 2026

   ContributorAuthor

   More actions

   Found the producer — a plugin, not core. Three more occurrences on 2026-10-14 (2.0.28, OpenAI Responses twice, then Anthropic Messages after switching the session's model), all reproduced from the stored history.

   Mechanism. The OMO OpenCode V2 adapter (code-yeongyu/oh-my-openagent#9016, which we run) registers a context hook that converts event.messages to V1 { info, parts } views, runs OMO's V1 experimental.chat.messages.transform chain, and writes the views back by array index. One of those transforms (team-mode status injector) splices a message in before the latest user-role message, so every later message receives its neighbour's content. In an agent loop the latest user-role message is often a synthetic instruction message (an AGENTS.md pulled in by a read), between two tool steps:

   before: … user[text] assistant[reasoning,tool-call] tool[tool-result]
   after:  … user[text] assistant[text] tool[reasoning,tool-call] tool[tool-result]
   

   The stored history is valid throughout (core's toLLMMessages emits one tool-result per tool message); the bad tool message exists only inside the request. That matches the earlier report: transient, and the next real user prompt clears it because the transform's target changes.

   The suggested logging hook did not catch it because hooks run in registration order and the directory plugin was set up before the configured OMO plugin, so it saw the messages before OMO edited them.

   Fix: SwarmStorm/oh-my-openagent#1 (write back by identity). On our build we also carry a small core guard in SessionModelRequest.prepare: snapshot the messages before the session hooks; if the hooked list has a tool message with a non-tool-result part and the snapshot has none, log the offending index:type pairs and send the snapshot. Tool-call/result pairing is preserved, valid hook edits are kept, and pre-existing invalid history is untouched. Happy to open it as a PR here if that direction is wanted; it would also cover the "which plugin added it" part of this issue.
9. akushonkamen commented on Oct 15, 2026

   

   akushonkamen

   on Oct 15, 2026

   Last edited by akushonkamen

   More actions

   Confirmed the root cause from source: lowerToolMessages in packages/ai/src/protocols/openai-chat.ts (line ~501 on dev) checks each tool-message part with ProviderShared.supportsContent(part, ["tool-result"]) and on failure calls ProviderShared.unsupportedContent("OpenAI Chat", "tool", ["tool-result"]), whose signature in packages/ai/src/protocols/shared.ts only takes route/role/types — so the error string structurally cannot include the message index, part index/type, or tool_call_id. As noted above in this thread, the error should identify the offending message and part.

   I'm preparing a small fix: add an optional detail parameter to unsupportedContent (backward-compatible, other protocols unaffected) and pass message/part context from lowerToolMessages. Behavior unchanged — the drain still aborts; only the diagnostics improve.

   Disclosure: I'm an AI-assisted contributor working on this fix; a human reviews and submits it.
10. akushonkamen commented on Oct 15, 2026

    

    akushonkamen

    on Oct 15, 2026

    More actions

    Update: this is now a PR — #55620 (branch akushonkamen:fix/55271-tool-content-error-detail), implementing exactly the change described above: optional detail parameter on unsupportedContent (20+ existing call sites untouched) and a message #N part #M type=<t> (+ tool_call_id when present) locator from lowerToolMessages. Behavior is unchanged — the drain still aborts before the request reaches the provider.

    Verification: new regression test fails on dev with Expected to contain: "message #2" and passes with the fix; cd packages/ai && bun test test/ → 1811 pass / 28 skip / 0 fail across 135 files; bun run typecheck exit 0; oxlint on the three changed files → 0 warnings / 0 errors.
11. mradwankhalil commented on Oct 15, 2026

    

    mradwankhalil

    on Oct 15, 2026

    ContributorAuthor

    More actions

    Thanks for taking on the diagnostics improvement and sharing the failing-first test. The reported scope of #55620 matches the diagnostic gap here: identify the offending message/part without changing the drain's rejection behavior.

    That complements the plugin-side producer fix in SwarmStorm/oh-my-openagent#1 (identity-based hook write-back). They address separate layers; the adapter fix does not remove the value of locating malformed parts when another producer introduces them. I have not independently rerun #55620's tests.