Description
Description
When using GPT-5.4 in OpenCode, editing can get stuck in a loop where the assistant repeatedly attempts to call apply_patch, but the actual tool input is an empty object:
assistant to=functions.apply_patch
{}
The tool then returns:
This repeats many times, and the target file is never modified.
This does not appear to be a repository permission or filesystem problem, because earlier in the same workflow, apply_patch succeeds when a complete patch payload is actually sent. For example, I observed successful file updates like:
Success. Updated the following files:
D /path/to/project/docs/OLD_FILE.md
A /path/to/project/docs/TARGET_FILE.md
and later:
Success. Updated the following files:
D /path/to/project/docs/TARGET_FILE.md
A /path/to/project/docs/TARGET_FILE.md
So the important point is:
- the file is writable
- the path is valid
apply_patch itself works
- the failure happens when the tool is invoked with empty input
{} instead of an actual patch payload
I also tested this in a new session:
- with GPT-5.4, the problem still happens
- with GPT-5.3 Codex, the problem does not happen
That makes this look model-specific, or at least a model/tool-call integration problem affecting GPT-5.4 in OpenCode.
OpenCode version
1.3.9
Steps to reproduce
-
Open a writable local project in OpenCode.
-
Use GPT-5.4 as the model.
-
Ask the assistant to modify an existing Markdown file in the project.
-
Observe that after some normal editing activity, OpenCode may enter a state where it repeatedly emits:
assistant to=functions.apply_patch
{}
-
Observe that each of these calls returns:
-
Observe that the file is not actually modified during these repeated aborted calls.
-
Start a new session and retry with GPT-5.4 → issue still reproduces.
-
Retry the same type of edit with GPT-5.3 Codex → issue does not reproduce.
Expected behavior
If the assistant decides to call apply_patch, OpenCode should only execute the tool when a valid patch payload is present.
At minimum, an empty tool call like {} should not result in repeated failed edit attempts that make the session appear stuck.
Actual behavior
OpenCode repeatedly calls:
assistant to=functions.apply_patch
{}
which returns:
This can happen many times in a row, with no file changes being applied.
Screenshot and/or share link
I can provide logs if needed.
The most relevant log excerpts are:
assistant to=functions.apply_patch
{}
and successful earlier calls showing the repo/file were writable:
Success. Updated the following files:
D /path/to/project/docs/OLD_FILE.md
A /path/to/project/docs/TARGET_FILE.md
Operating System
macOS [please fill in exact version]
Terminal
[please fill in exact environment, e.g. OpenCode Desktop / iTerm2 / Ghostty / Warp / Terminal.app]
Additional context
What makes this particularly suspicious is that the same repository and same editing workflow behave differently across models:
- GPT-5.4 → repeated empty
apply_patch {} calls, Tool execution aborted
- GPT-5.3 Codex → normal editing, no such issue observed
This suggests one of the following:
- OpenCode is sometimes executing a malformed or truncated tool call from GPT-5.4
- GPT-5.4 tool-call arguments are being dropped during serialization or parsing
- OpenCode does not guard well against empty
apply_patch invocations and ends up in a repeated abort loop
This does not appear to be caused by:
- file permissions
- invalid path
- non-writable docs directory
- plugin residue
- repository corruption
because valid apply_patch calls succeeded earlier against the same repo and files.
I can also provide a full session log if that would help identify whether the empty {} tool call is coming from the model output itself or from OpenCode's tool-call assembly/parsing layer.
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
Description
Description
When using GPT-5.4 in OpenCode, editing can get stuck in a loop where the assistant repeatedly attempts to call
apply_patch, but the actual tool input is an empty object:The tool then returns:
This repeats many times, and the target file is never modified.
This does not appear to be a repository permission or filesystem problem, because earlier in the same workflow,
apply_patchsucceeds when a complete patch payload is actually sent. For example, I observed successful file updates like:and later:
So the important point is:
apply_patchitself works{}instead of an actual patch payloadI also tested this in a new session:
That makes this look model-specific, or at least a model/tool-call integration problem affecting GPT-5.4 in OpenCode.
OpenCode version
1.3.9
Steps to reproduce
Open a writable local project in OpenCode.
Use GPT-5.4 as the model.
Ask the assistant to modify an existing Markdown file in the project.
Observe that after some normal editing activity, OpenCode may enter a state where it repeatedly emits:
Observe that each of these calls returns:
Observe that the file is not actually modified during these repeated aborted calls.
Start a new session and retry with GPT-5.4 → issue still reproduces.
Retry the same type of edit with GPT-5.3 Codex → issue does not reproduce.
Expected behavior
If the assistant decides to call
apply_patch, OpenCode should only execute the tool when a valid patch payload is present.At minimum, an empty tool call like
{}should not result in repeated failed edit attempts that make the session appear stuck.Actual behavior
OpenCode repeatedly calls:
which returns:
This can happen many times in a row, with no file changes being applied.
Screenshot and/or share link
I can provide logs if needed.
The most relevant log excerpts are:
and successful earlier calls showing the repo/file were writable:
Operating System
macOS [please fill in exact version]
Terminal
[please fill in exact environment, e.g. OpenCode Desktop / iTerm2 / Ghostty / Warp / Terminal.app]
Additional context
What makes this particularly suspicious is that the same repository and same editing workflow behave differently across models:
apply_patch {}calls,Tool execution abortedThis suggests one of the following:
apply_patchinvocations and ends up in a repeated abort loopThis does not appear to be caused by:
because valid
apply_patchcalls succeeded earlier against the same repo and files.I can also provide a full session log if that would help identify whether the empty
{}tool call is coming from the model output itself or from OpenCode's tool-call assembly/parsing layer.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