Bug: OpenCode prompt loop continues after finish=stop, triggering prefill error on claude-opus-4-6 #17982

Activity

1. MusiCode1

   added

   bugSomething isn't workingSomething isn't working

   on Mar 17, 2026
2. github-actions

   assigned

   thdxr

   on Mar 17, 2026
3. github-actions

   added

   coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

   on Mar 17, 2026
4. github-actions commented on Mar 17, 2026

   

   github-actionsBot

   on Mar 17, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • This model does not support assistant message prefill / Github Copilot with Opus 4.6 #13768: Same error ("This model does not support assistant message prefill") with Opus 4.6 — same root cause, still open
   • Session Loop Termination Condition Fails Causing Infinite Loop #13577: Session loop termination condition fails causing infinite loop when model returns finish=stop — same underlying loop continuation bug
   • Github Copilot / Opus 4.6 Error #12337: Same prefill error with GitHub Copilot / Opus 4.6 (closed)
5. jialigit2 commented on Mar 18, 2026

   

   jialigit2

   on Mar 18, 2026

   More actions

   the latest version 1.2.27 is the same.

   👍React with 👍4Reacted by MusiCode1, kam, Kunhyung Bahk and oliverberndt1
6. kamtang0823 commented on Mar 18, 2026

   

   kamtang0823

   on Mar 18, 2026

   More actions

   I also encountered this problem. Even after completing the task with the claude model, it still keeps requesting the model, causing my bill to explode，version = 1.2.27
7. jameskyle commented on Mar 20, 2026

   

   jameskyle

   on Mar 20, 2026

   Last edited by jameskyle

   More actions

   Pretty sure I'm being hit with this using Bedrock Anthropic models.
8. chnlkw commented on Mar 23, 2026

   

   chnlkw

   on Mar 23, 2026

   More actions

   Still present in v1.3.0

   Confirmed this bug persists in v1.3.0. The loop exit condition is unchanged:

   $ strings /usr/local/bin/opencode | grep 'lastUser.id < lastAssistant.id'
   if (lastAssistant?.finish && !["tool-calls", "unknown"].includes(lastAssistant.finish) && lastUser.id < lastAssistant.id) {
   

   PRs #17010 and #17149 (which fix this) are still open and unreviewed.

   Concrete trigger: remote opencode web with cross-machine clock skew

   This reliably reproduces when opencode web runs on a remote server (e.g. Kubernetes) and the browser is on a different machine. The browser-generated user messageID encodes Date.now() from the client clock; the assistant messageID uses the server clock. Even a few ms of skew where the browser is ahead causes lastUser.id > lastAssistant.id, so the loop never breaks.

   Does NOT reproduce when browser and server share the same machine (local opencode web).

   Workaround: HTTP delay proxy

   For anyone stuck on this, here's a minimal Node.js proxy (~40 lines) that sits between the browser and opencode web. It only delays POST /session/*/prompt_async requests by exactly the clock skew — all other HTTP and WebSocket traffic passes through instantly.

   "use strict";
   const http = require("http");
   const TARGET = { host: "127.0.0.1", port: parseInt(process.env.TARGET_PORT || "3000") };
   const LISTEN_PORT = parseInt(process.env.LISTEN_PORT || "8080");
   const PROMPT_RE = /\/session\/[^/]+\/prompt(?:_async)?$/;
   const MASK48 = (1n << 48n) - 1n;
   
   function calcDelay(messageID) {
     if (!messageID?.startsWith("msg_") || messageID.length < 16) return 0;
     const hex = messageID.slice(4, 16);
     if (!/^[0-9a-f]{12}$/i.test(hex)) return 0;
     try {
       const idEnc = BigInt("0x" + hex);
       const nowEnc = (BigInt(Date.now()) * 0x1000n + 1n) & MASK48;
       return idEnc > nowEnc ? Math.min(Number((idEnc - nowEnc) / 0x1000n), 5000) : 0;
     } catch { return 0; }
   }
   
   function proxy(req, res, body) {
     const p = http.request({ ...TARGET, method: req.method, path: req.url,
       headers: { ...req.headers, host: `${TARGET.host}:${TARGET.port}` }
     }, (r) => { res.writeHead(r.statusCode, r.headers); r.pipe(res); });
     p.on("error", () => { if (!res.headersSent) { res.writeHead(502); res.end("Bad Gateway"); } });
     body ? p.end(body) : req.pipe(p);
   }
   
   http.createServer((req, res) => {
     if (req.method === "POST" && PROMPT_RE.test(req.url)) {
       const chunks = [];
       req.on("data", (c) => chunks.push(c));
       req.on("end", () => {
         const body = Buffer.concat(chunks);
         let delay = 0;
         try { const j = JSON.parse(body); if (j.messageID) delay = calcDelay(j.messageID); } catch {}
         if (delay > 0) setTimeout(() => proxy(req, res, body), delay);
         else proxy(req, res, body);
       });
     } else proxy(req, res);
   }).on("upgrade", (req, sock, head) => {
     const p = http.request({ ...TARGET, method: req.method, path: req.url, headers: req.headers });
     p.on("upgrade", (r, up, uh) => {
       let h = "HTTP/1.1 101 Switching Protocols\r\n";
       for (let i = 0; i < r.rawHeaders.length; i += 2) h += r.rawHeaders[i] + ": " + r.rawHeaders[i+1] + "\r\n";
       sock.write(h + "\r\n"); if (uh.length) sock.write(uh); if (head.length) up.write(head);
       sock.pipe(up); up.pipe(sock);
       sock.on("error", () => up.destroy()); up.on("error", () => sock.destroy());
     });
     p.on("error", () => sock.destroy());
     p.end();
   }).listen(LISTEN_PORT, "0.0.0.0", () =>
     console.log("[proxy] :" + LISTEN_PORT + " -> " + TARGET.host + ":" + TARGET.port)
   );

   Usage: TARGET_PORT=3000 LISTEN_PORT=8080 node proxy.js, point browser at port 8080.

   👍React with 👍2Reacted by Max Medve and MusiCode1
9. Leslie-ller commented on Mar 26, 2026

   

   Leslie-ller

   on Mar 26, 2026

   Last edited by Leslie-ller

   More actions

   Adding another minimal repro that appears to hit the same underlying loop/termination bug from a different angle.

   Observed behavior in a control sample:

   • parent session performs the main tool-call turn (finish="tool-calls")
   • then OpenCode generates one more assistant turn before exiting
   • exported session shows that extra final turn as finish="stop" with empty text

   From this repro angle, the continuation bug manifests as an unnecessary empty stop-turn after tool completion, rather than as a visible prompt/prefill error.

   Evidence from the local investigation:

   • control run log showed the parent session still advancing another prompt step before exit
   • parent session export reduced to:
     • user
     • assistant with finish="tool-calls"
     • assistant with finish="stop" and empty text
10. rekram1-node

    assigned

    rekram1-node

    and unassigned

    thdxr

    on Mar 27, 2026
11. jerome-benoit commented on Mar 29, 2026

    

    jerome-benoit

    on Mar 29, 2026

    Last edited by jerome-benoit

    Contributor

    More actions

    Root cause analysis

    After tracing the code paths in prompt.ts, message-v2.ts, processor.ts, and transform.ts, there are 2 confirmed root causes producing trailing role: "assistant" messages.

    S1 — Loop exit condition (prompt.ts) — PRIMARY

    lastUser.id < lastAssistant.id

    IDs are ULIDs encoding Date.now(). When the user messageID is generated in the browser and the assistant ID on the server, clock divergence makes this comparison unreliable. The loop fails to break even though lastAssistant.finish is set → next iteration sends the previous assistant response as the last message → API rejects.

    The correct comparison is lastAssistant.parentID === lastUser.id — parentID is always explicitly set at assistant message creation and is a semantic relationship, not a temporal one.

    S2 — MAX_STEPS injection (prompt.ts) — NARROW

    ...(isLastStep
      ? [{ role: "assistant" as const, content: MAX_STEPS }]
      : []),

    Appends role: "assistant" when step >= agent.steps. Only triggers when the agent has a finite steps setting (agent.steps ?? Infinity), so most agents are unaffected.

    Not independent sources

    • Abort mid-stream: Aborted assistant messages with substantive parts are kept in history (toModelMessages preserves AbortedError with content), but processor.process() returns "stop" on abort → the loop breaks. Creates dirty state but needs S1 to fail for the trailing assistant to reach the API.
    • Compaction/filtering: toModelMessages() only skips assistant messages with non-abort errors. User messages are always included if they have parts. No code path where filtering leaves an orphaned assistant at the tail.
    • Frontend ordering: Real bug (message.id vs time.created) but only affects UI rendering, not API request construction.

    Transport layer — current state

    normalizeMessages() in transform.ts handles empty content filtering (Anthropic), toolCallId scrubbing (Claude/Mistral), and reasoning extraction. No stripTrailingAssistant or supportsAssistantPrefill exists. ProviderTransform.message() is the single choke point for all outgoing messages.

    PRs

    Root-cause fixes:

    • fix: resolve Claude 4.6 assistant prefill compatibility issues #16900 — fixes S1 (parentID comparison) + S2 (MAX_STEPS role → "user"). 2-line surgical fix.
    • fix(session): use parentID instead of message ID ordering in prompt loop #17010 — same parentID fix as fix: resolve Claude 4.6 assistant prefill compatibility issues #16900 with regression test covering the web/cross-machine scenario.

    Transport-layer safety net:

    • fix: disable assistant prefill for Claude 4.6 models #14772 — stripTrailingAssistant() in normalizeMessages() with supportsAssistantPrefill() model detection. Defense-in-depth for unanticipated edge cases.

    Partial or incorrect:

    • fix: keep Copilot Claude prompts user-final across continuation turns #16921 — correct architecture but scoped only to Copilot Claude.
    • fix(opencode): CSP, cache headers, Anthropic prefill, idle timeout, and WebSocket URL credentials #18091 — similar to fix: disable assistant prefill for Claude 4.6 models #14772 but buried in an omnibus PR with 4 unrelated fixes.
    • fix(session): prevent assistant-last message array from reaching provider APIs #18421 — synthetic "Continue." user message, changes conversation semantics. Correctly rejected.

    Complete fix

    A single PR combining #16900 root-cause fixes + #17010 regression test + #14772 transport-layer safety net would close this and all related duplicates (#13768, #12337, #13577). Neither layer alone is sufficient: #16900 does not protect against future unknown sources, #14772 alone masks the loop bug without fixing it.
12. Sydius

    marked Agent loop runs extra step when client/server clocks are skewed #24183 as a duplicate of this issue on Apr 24, 2026
13. thdxr

    removed

    bugSomething isn't workingSomething isn't working

    coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

    on May 3, 2026
14. github-actions commented on Jul 3, 2026

    

    github-actionsBot

    on Jul 3, 2026 – with GitHub Actions

    Contributor

    More actions

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
15. github-actions

    closed this as not plannedon Jul 3, 2026