Opencode with OpenAI stuck in loop with errors

[W1BTR]

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.

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

[github-actions]

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

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

[rekram1-node]

can u share session?

[W1BTR]

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.

[justfortheloveof]

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.

[3mdistal]

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