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

@XuanningZhang

Description

@XuanningZhang

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
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions