Skip to content

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

Description

@Ruifeng-Zhang

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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions