Opencode with OpenAI stuck in loop with errors #4253

Open
opened 2026-02-16 17:43:10 -05:00 by yindo · 5 comments
Owner

Originally created by @W1BTR on GitHub (Jan 5, 2026).

Originally assigned to: @rekram1-node on GitHub.

Description

Having a strange error with opencode running OpenAI's codex 5.1. It got stuck in a loop of editing a file a good 20 times with that message. I tried interrupting it and asking if there was an error, and it would just continue trying. Eventually it did complete, but Im not sure what was going on there.

Image

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

Originally created by @W1BTR on GitHub (Jan 5, 2026). Originally assigned to: @rekram1-node on GitHub. ### Description Having a strange error with opencode running OpenAI's codex 5.1. It got stuck in a loop of editing a file a good 20 times with that message. I tried interrupting it and asking if there was an error, and it would just continue trying. Eventually it did complete, but Im not sure what was going on there. <img width="1092" height="868" alt="Image" src="https://github.com/user-attachments/assets/dc74705c-7a6e-474d-8991-93afea9c6153" /> ### Plugins _No response_ ### OpenCode version _No response_ ### Steps to reproduce _No response_ ### Screenshot and/or share link _No response_ ### Operating System _No response_ ### Terminal _No response_
yindo added the bug label 2026-02-16 17:43:10 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Jan 5, 2026):

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

  • #4466: big pickle: blank edit loop - Similar issue where OpenCode gets stuck editing with blank output
  • #3038: The model loops attempting to edit files in PLAN mode - Model repeatedly attempts to edit/read files in a loop
  • #5356: OpenCode repeatedly executes a command non stop - Agent gets stuck in a loop continuously executing the same operations
  • #4445: Using GPT 5.1 Codex via OpenAI fails on the 2nd request - Specific issue with GPT 5.1 Codex model behavior

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 5, 2026): This issue might be a duplicate of existing issues. Please check: - #4466: big pickle: blank edit loop - Similar issue where OpenCode gets stuck editing with blank output - #3038: The model loops attempting to edit files in PLAN mode - Model repeatedly attempts to edit/read files in a loop - #5356: OpenCode repeatedly executes a command non stop - Agent gets stuck in a loop continuously executing the same operations - #4445: Using `GPT 5.1 Codex` via OpenAI fails on the 2nd request - Specific issue with GPT 5.1 Codex model behavior Feel free to ignore if none of these address your specific case.
Author
Owner

@rekram1-node commented on GitHub (Jan 5, 2026):

can u share session?

@rekram1-node commented on GitHub (Jan 5, 2026): can u share session?
Author
Owner

@W1BTR commented on GitHub (Jan 5, 2026):

Unfortunetly there's some proprietary code in the session I cant share at the moment. Once Im done at work I can work on creating a different session and seeing if I can reproduce it, then share that.

@W1BTR commented on GitHub (Jan 5, 2026): Unfortunetly there's some proprietary code in the session I cant share at the moment. Once Im done at work I can work on creating a different session and seeing if I can reproduce it, then share that.
Author
Owner

@justfortheloveof commented on GitHub (Jan 8, 2026):

The first 2 errors (which are the same) are from the LSP (language server) which does static analysis / type checking and the results (the LSP reported errors or warnings) are fed back to the LLM in an attempt to have it resolve the issue on its own.

The 3rd error is from the edit tool, reporting to the LLM that the "oldString" in the search/replace function it called doesn't exist in the file. This too, is fed back to the LLM in an attempt to have it correct its tool call accordingly.

Different models behave differently (obviously) and I have found that either turning LSP off or including a message in the system prompt to worry about those after the changes are done can be quite helpful. Otherwise, opus handles these pretty well in my experience.

@justfortheloveof commented on GitHub (Jan 8, 2026): The first 2 errors (which are the same) are from the LSP (language server) which does static analysis / type checking and the results (the LSP reported errors or warnings) are fed back to the LLM in an attempt to have it resolve the issue on its own. The 3rd error is from the edit tool, reporting to the LLM that the "oldString" in the search/replace function it called doesn't exist in the file. This too, is fed back to the LLM in an attempt to have it correct its tool call accordingly. Different models behave differently (obviously) and I have found that either turning LSP off or including a message in the system prompt to worry about those after the changes are done can be quite helpful. Otherwise, opus handles these pretty well in my experience.
Author
Owner

@3mdistal commented on GitHub (Jan 9, 2026):

I can reproduce this consistently with GPT 5.2 (oauthed in via the community plugin).

I dug into my local session logs and found what I think is the root cause: tool results are being stored as "type": "text" with a display-wrapper prefix instead of as proper tool-role messages.

Attached: opencode-issue-6983-repro.zip containing 7 sample parts from a single message that generated 980 parts over ~9 minutes before I stopped it. The README explains what each file shows.

Example from the logs:

{
  type: text,
  text: [Previous tool result; call_id=call_wupDgM6V3ZBrXLOOFZAtqwVw]: 54
}

When the conversation is replayed to the model, these [Previous tool result; call_id=...] strings appear as assistant text content. The model sees them, gets confused, and either echoes/continues the pattern or retries tool calls, which creates the runaway loop.

I think this happens with GPT models because they are more literal about tool scaffolding tokens. If the transcript includes tool scaffolding as plain text, GPT tends to "continue" it. Claude seems to self-correct or abandon earlier.

Suggested fixes:

  1. Never persist [Previous tool result...] as model-visible "type": "text". Tool outputs could be in a separate channel or filtered when building the next prompt
  2. Add a loop breaker: if the same tool call signature repeats N times, abort and surface an error to the model

opencode-issue-6983-repro.zip

@3mdistal commented on GitHub (Jan 9, 2026): I can reproduce this consistently with GPT 5.2 (oauthed in via the community plugin). I dug into my local session logs and found what I think is the root cause: tool results are being stored as `"type": "text"` with a display-wrapper prefix instead of as proper tool-role messages. Attached: `opencode-issue-6983-repro.zip` containing 7 sample parts from a single message that generated 980 parts over ~9 minutes before I stopped it. The README explains what each file shows. Example from the logs: ```json { type: text, text: [Previous tool result; call_id=call_wupDgM6V3ZBrXLOOFZAtqwVw]: 54 } ``` When the conversation is replayed to the model, these `[Previous tool result; call_id=...]` strings appear as assistant text content. The model sees them, gets confused, and either echoes/continues the pattern or retries tool calls, which creates the runaway loop. I think this happens with GPT models because they are more literal about tool scaffolding tokens. If the transcript includes tool scaffolding as plain text, GPT tends to "continue" it. Claude seems to self-correct or abandon earlier. Suggested fixes: 1. Never persist `[Previous tool result...]` as model-visible `"type": "text"`. Tool outputs could be in a separate channel or filtered when building the next prompt 2. Add a loop breaker: if the same tool call signature repeats N times, abort and surface an error to the model [opencode-issue-6983-repro.zip](https://github.com/user-attachments/files/24528014/opencode-issue-6983-repro.zip)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4253