[Bug] GPT-5.4 repeatedly sends empty apply_patch tool calls ({}), causing Tool execution aborted, while GPT-5.3 Codex does not #20227

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:

Tool execution aborted

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

1. Open a writable local project in OpenCode.

2. Use GPT-5.4 as the model.

3. Ask the assistant to modify an existing Markdown file in the project.

4. Observe that after some normal editing activity, OpenCode may enter a state where it repeatedly emits:

   assistant to=functions.apply_patch
   {}
   

5. Observe that each of these calls returns:

   Tool execution aborted
   

6. Observe that the file is not actually modified during these repeated aborted calls.

7. Start a new session and retry with GPT-5.4 → issue still reproduces.

8. 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:

Tool execution aborted

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
{}

Tool execution aborted

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:

1. OpenCode is sometimes executing a malformed or truncated tool call from GPT-5.4
2. GPT-5.4 tool-call arguments are being dropped during serialization or parsing
3. 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