Client or integration
Codex App
Area
Provider adapter
Summary
OpenCodex 2.17.0 leaks an undeclared top-level apply_patch function call through the native OpenAI Responses passthrough path when using OpenCode Go. Codex App displays aborted, while the target file remains unchanged.
Expected behavior: an undeclared routed tool should fail closed with an explicit compatibility error before reaching the Codex executor. The supported editing path should remain exec -> tools.apply_patch(...).
Reproduction
- Start OpenCodex on port 10100.
- Use
exec -> tools.apply_patch(...) to create a temporary file containing v1.
- Invoke top-level
apply_patch with a patch changing v1 to v2.
- Codex App displays
aborted.
- The file remains
v1; content and mtime are unchanged.
- Run the equivalent patch through
exec -> tools.apply_patch(...):
- an incorrect expected line returns a real
apply_patch verification failed error;
- the correct
v1 -> v3 patch succeeds.
The request-visible catalog contains exec, wait, and request_user_input, but no top-level apply_patch schema. The session nevertheless receives function_call(name=apply_patch).
Version
OpenCodex 2.17.0
Operating system
macOS 27.0, Apple Silicon
Provider and model
Provider: opencode-go
Model: deepseek-v4-flash
At reproduction time, the provider default was openai-chat, while this model had an explicit openai-responses adapter override.
Logs or error output
- Codex result:
aborted
- No corresponding
custom_tool_call_output was emitted.
- OpenCode Go usage record was HTTP 200.
- No upstream
aborted, OpenCodex response.failed, approval denial, or sandbox denial was observed.
Screenshots and supporting files
No screenshots. Reproduction artifacts were written only under /tmp.
Redacted configuration
{
"providers": {
"opencode-go": {
"adapter": "openai-chat",
"baseUrl": "https://opencode.ai/zen/go/v1",
"modelAdapters": {
"deepseek-v4-flash": "openai-responses"
}
}
}
}
Checks
Client or integration
Codex App
Area
Provider adapter
Summary
OpenCodex 2.17.0 leaks an undeclared top-level
apply_patchfunction call through the native OpenAI Responses passthrough path when using OpenCode Go. Codex App displaysaborted, while the target file remains unchanged.Expected behavior: an undeclared routed tool should fail closed with an explicit compatibility error before reaching the Codex executor. The supported editing path should remain
exec -> tools.apply_patch(...).Reproduction
exec -> tools.apply_patch(...)to create a temporary file containingv1.apply_patchwith a patch changingv1tov2.aborted.v1; content and mtime are unchanged.exec -> tools.apply_patch(...):apply_patch verification failederror;v1 -> v3patch succeeds.The request-visible catalog contains
exec,wait, andrequest_user_input, but no top-levelapply_patchschema. The session nevertheless receivesfunction_call(name=apply_patch).Version
OpenCodex 2.17.0
Operating system
macOS 27.0, Apple Silicon
Provider and model
Provider:
opencode-goModel:
deepseek-v4-flashAt reproduction time, the provider default was
openai-chat, while this model had an explicitopenai-responsesadapter override.Logs or error output
abortedcustom_tool_call_outputwas emitted.aborted, OpenCodexresponse.failed, approval denial, or sandbox denial was observed.Screenshots and supporting files
No screenshots. Reproduction artifacts were written only under
/tmp.Redacted configuration
{ "providers": { "opencode-go": { "adapter": "openai-chat", "baseUrl": "https://opencode.ai/zen/go/v1", "modelAdapters": { "deepseek-v4-flash": "openai-responses" } } } }Checks