Hi Colin, I only recently managed to find the time to isolate the error. Based on my logs, I got the following, AI-generated report. I hope this helps in case other people encounter a similar error:
GPT-5.5 BYOK/custom endpoint: Shell tool works, ApplyPatch/custom_tool_call aborts
Request ID: 16b669ac-93b6-44fe-b9d7-4c33f150acbd
I am following up on my earlier BYOK/custom endpoint investigation. I ran a focused reproduction to separate three possible issues:
- Basic model access / authentication / endpoint routing
- Normal tool calls such as Shell
- Cursor file-editing via
ApplyPatch / custom_tool_call
The result is that GPT-5.5 works for Shell tool calls, including shell-only file creation, but appears to abort or fail when the model returns an ApplyPatch / custom_tool_call.
Setup
- Cursor with OpenAI BYOK enabled.
- Override OpenAI Base URL enabled, pointing to a custom OpenAI-compatible endpoint.
- Model selected in Cursor: GPT-5.5 High.
- Tested in fresh Cursor chats.
- I am intentionally describing the endpoint generically because I do not think the specific local forwarding/proxy setup is the relevant part of the bug.
Capability ladder before the focused repro
Before isolating the file-editing path, I tested the following:
pwd- grep/search
- file reading
- GitHub CLI command, e.g.
gh pr list
- harmless file write through terminal
- repo file creation through terminal
- MCP usage
These worked. That suggested the issue was not basic model access, not normal tool calling, not Shell execution, and not MCP routing.
The problem appeared specifically when the agent needed to write or edit files through Cursor’s editing tools.
Focused Test A: Shell-only file creation
Prompt used in a fresh Cursor chat:
Use only terminal. Do not use ApplyPatch, file edit tools, MCPs, or subagents.
Run exactly one shell command that creates plans/_gpt55_shell_only_write.md with 5 lines of markdown using a heredoc.
Then run exactly one shell command to read it back with sed -n '1,20p'.
Stop after reading it back.
Test A result
This worked.
The file plans/_gpt55_shell_only_write.md was created and read back. Endpoint logs show a normal Shell function call and a completed response with no upstream error.
So GPT-5.5 BYOK can use Shell and can create files through Shell.
Focused Test B: ApplyPatch-only file creation
Prompt used in a separate fresh Cursor chat:
Use ApplyPatch only. Do not use terminal, MCPs, or subagents.
Create exactly one file:
plans/_gpt55_applypatch_write.md
The file content must be exactly:
# GPT-5.5 ApplyPatch Write Test
Line 1: applypatch path
Line 2: file creation
Line 3: stop after verification
After creating the file, read it back using the normal file read tool. Stop after reading it back.
Test B result
This appeared to abort in Cursor. The file was not applied/read back in the expected way, and the chat did not produce a useful completion.
However, the endpoint logs do not show an upstream failure. They show that GPT-5.5 generated a valid ApplyPatch custom tool call, equivalent to:
*** Begin Patch
*** Add File: <workspace>/plans/_gpt55_applypatch_write.md
+# GPT-5.5 ApplyPatch Write Test
+
+Line 1: applypatch path
+Line 2: file creation
+Line 3: stop after verification
*** End Patch
The response metadata shows custom_tool_call, name: "ApplyPatch", status: "completed", followed by a completed response and no upstream error.
Key difference
The two tests differ by tool-call type:
Shell write:
regular function/tool call
Cursor executes it
file is created
ApplyPatch write:
custom_tool_call
endpoint response completes successfully
Cursor aborts / does not apply the patch or continue correctly
This makes the failure look like Cursor’s handling of ApplyPatch / custom_tool_call in the GPT-5.5 BYOK/custom endpoint path, rather than a general model, authentication, endpoint, or Shell-tool issue.
Why this does not look like an upstream failure
The same setup successfully handled normal Shell tool calls.
The failing ApplyPatch case also returned a completed endpoint response. GPT-5.5 generated the patch call successfully, and the endpoint response had no upstream error.
So the failure appears to happen after Cursor receives the completed ApplyPatch custom tool call, likely in Cursor’s local agent loop or custom tool execution layer.
Current workaround
GPT-5.5 BYOK/custom endpoint seems usable for:
planning
reading
grep / rg
GitHub CLI commands
CI monitoring
reviewing diffs
shell-only diagnostics
shell-only file creation
I am avoiding it for:
ApplyPatch
Cursor file-edit tools
direct repo edits
large implementation loops that require patching files
For now, my workaround is to use GPT-5.5 for planning/review/checking and another model/path for implementation and file editing.
Minimal repro summary
- Enable OpenAI BYOK in Cursor.
- Enable Override OpenAI Base URL to a custom OpenAI-compatible endpoint.
- Select GPT-5.5 High.
- Run a Shell-only file creation prompt. It works.
- Run an ApplyPatch-only file creation prompt. Cursor aborts or does not complete properly.
- Inspect endpoint logs: upstream returns a completed response with no upstream error, and the model generated a valid
ApplyPatch / custom_tool_call.
This suggests a Cursor-side issue in ApplyPatch / custom_tool_call handling for GPT-5.5 BYOK/custom OpenAI-compatible endpoints.
