BYOK Codex Agent: turn ends before write tool_use (read tools work; repro on gpt-5.4 and gpt-5.5; started after 3.9)

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

In Agent mode with BYOK (OpenAI-compatible endpoint → CLIProxyAPI → ChatGPT Codex), read-only tools work reliably. When the agent should invoke write/edit tools (Write, StrReplace, ApplyPatch), the turn often ends without any tool_use in the transcript. UI may show turn_ended status=success, but no file is created/edited. Reproduces on both gpt-5.4 and gpt-5.5 via BYOK. Worked until ~2 weeks ago; became consistent after upgrading to Cursor 3.9.16.

Steps to Reproduce

  1. Fresh Agent chat with BYOK Codex (gpt-5.4 or gpt-5.5).
  2. Control (passes): Ask agent to ReadFile a small file — tool executes normally.
  3. Fail: Ask agent to create .agents/files/eof-write-test.txt with single line eof-write-probe-ok using Write tool only.
  4. Actual: Agent may say it will write, then turn ends. No write tool_use in transcript. Often turn_ended status=success with no tool execution. No permission dialog or tool error.

Expected Behavior

Agent should emit a Write (or equivalent) tool_use and create the test file.

Operating System

Windows 10/11

Version Information

IDE:
Version: 3.9.16
VSCode Version: 1.105.1
Date: 2026-06-27
OS: Windows 10 (10.0.19044)

For AI issues: which model did you use?

gpt-5.4, gpt-5.5 (BYOK via custom OpenAI base URL → https://cocor.qzz.io/v1)

For AI issues: add Request ID with privacy disabled

Will follow up with Request ID after repro with privacy mode disabled.

Additional Information

Related threads: /t/162314, /t/160228, /t/156565. Not a filesystem permission issue (no tool_use attempted). CPA upstream logs: Post https://chatgpt.com/backend-api/codex/responses EOF on large agent payloads (400-530KB). cloudflared context canceled at 2026-07-01 22:19:04 during failed write probe. Occasional unknown provider for model gpt-5.3-codex on BYOK backend (possible subagent routing).

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hey, thanks for the detailed report with logs. That makes debugging a lot easier. Here’s what I’m seeing. It looks like the issue isn’t Cursor itself, but two parts of your BYOK setup.

  1. The proxy is dropping large requests. In your logs, the POST to chatgpt.com/backend-api/codex/responses returns EOF when the body is around 400 to 530 KB, and cloudflared shows “context canceled” during the write attempt. Read tools send small payloads and succeed, while write or edit turns send the full context plus the file contents, which is larger, and they get cut off upstream. That matches the “read works, write fails” behavior. Check body size limits and timeouts across the whole chain, including CLIProxyAPI and cloudflared, and increase them.

  2. Your custom model names conflict with built-in ones. You named your models exactly gpt-5.4 and gpt-5.5, which match built-in slugs. Because of the collision, some traffic doesn’t go through your gateway. Rename your custom models to unique names, like gpt-5.5-mycodex, so routing uses your API key plus Override Base URL. Then open Usage and confirm those requests show Type = “User API Key”. If not, routing is still bypassing your endpoint.

About “it broke after 3.9”. The relevant BYOK fix landed before your 3.9.16 build, so 3.9 didn’t introduce this. More likely, 3.9 agent payloads are a bit larger and hit your proxy limits harder.

One more thing. The setup CLIProxyAPI to personal ChatGPT Codex subscription is not a supported path, so some of this behavior isn’t guaranteed.

Try those two steps and tell me if anything changes. If it does, send a Request ID with Privacy Mode turned off, and we can dig deeper.

34525816-681e-4e1a-95a9-8fca3d7cdf7a 这里有一个复现例子,即便尝试使用小范围的编辑也会造成会话立刻终结

你试过刚才告知的修改方案了吗?感谢提供请求编号,相关团队会跟进核查此事。

已经修改了自定义模型名并增加了我代理链路保活时间。重新测试一个最小写入对话依然有问题 fa6875dc-9d18-4dbe-8f49-245a9a151f39

那我们就先等团队的反馈吧。

Thanks for running both steps and sharing the Request ID. Since even the smallest write fails, payload size is probably not the main suspect, and that actually narrows things down.

Now the key thing is to confirm where traffic is really going after the model renames. Open Usage and find those two requests. Check the Type column:

  • If it says User API Key, routing is now going through your gateway. That means the turn is ending without a write tool_use on your gateway or model side (CLIProxyAPI to personal ChatGPT Codex). This path isn’t supported, so behavior isn’t guaranteed. The Codex endpoint may simply not return write tool_use in this format.
  • If it still says included or billable (served by Cursor), then the rename didn’t take effect and routing is still bypassing your endpoint. In that case, confirm your custom model has a unique name (not gpt-5.4 or gpt-5.5), and that your BYOK config has your Override Base URL plus API key.

Send what Type shows for those requests, and we’ll know which side is dropping it. Also note: the CLIProxyAPI to personal ChatGPT Codex subscription setup isn’t officially supported, so some behavior on that route is unstable by design.