[Bug]: Cursor Opus 5.5 code-mode exec rejected on 2.84.0 while structured tool controls pass
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 38/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
Research direction
Start by tracing cursorFreeformWrapperValid, commitToolCall, and dropInvalidFreeformCall in protobuf-events.ts, then inspect the Cursor tool schema and normalization path in the named adapter files. Capture the rejected upstream argument payload and compare it with the declared {input:string} wrapper while keeping validation fail-closed. Done means a focused regression test covers the observed payload and a fresh Codex code-mode call reaches host execution.
Written by the indexing model from the issue text.
Description
Client or integration
Codex App
Area
Provider adapter
Version
@bitkyc08/opencodex 2.84.0. Both the running /healthz proxy and desktop executable report 2.84.0. Codex task runtime: 0.162.0-alpha.17.2.
Operating system
Windows, 25H2, OS build 26200.9445, x64.
Provider and model
cursor / claude-opus-5-5, requested route cursor/claude-opus-5-5, reasoning effort low, ordinary non-Fast model.
Logs or error output
exec call had invalid freeform arguments; expected {input:string}
errorCode=invalid_request_error
failureStage=semantic-output
failureCause=payload-rejected
sideEffectEvents=0
Redacted configuration
{
"provider": "cursor",
"requestedModel": "cursor/claude-opus-5-5",
"requestedEffort": "low",
"catalogToolMode": "code_mode_only",
"catalogShellType": "unified_exec",
"nativeLocalExec": "unset/default"
}
Summary
On OpenCodex 2.84.0 / Windows / Codex App, a fresh cursor/claude-opus-5-5 task fails to create a small offline SVG HTML because the Cursor adapter rejects code-mode exec calls before host execution:
exec call had invalid freeform arguments; expected {input:string}
Small structured function-tool round trips with the same model/account succeed through both Responses and Messages. These controls do not demonstrate that Codex's real freeform/code-mode surface works.
Environment
- Running OCX proxy and desktop version: 2.84.0.
- Codex task runtime: 0.162.0-alpha.17.2.
- Requested model:
cursor/claude-opus-5-5; logged provider:cursor; resolved model:claude-opus-5-5; requested effort:low. - Routed catalog row:
tool_mode: code_mode_only,shell_type: unified_exec. cursor.nativeLocalExecand providercodexToolMode: unset (default).- The model is present in live model discovery. Network connectivity is sufficient for the positive controls.
- Local-patch disclosure: this installation has existing Qoder CN and Claude Desktop/model-metadata compatibility patches. The relevant Cursor files (
protobuf-events.ts,tool-schemas.ts,native-exec.ts,tool-guidance.ts,tool-wording.ts,tool-naming.ts,tool-definitions.ts) were checked against the verified 2.84.0 npm tarball and are byte-identical. The entire installation is not claimed to be pristine.
Reproduction
- Start a fresh Codex App task, choose ordinary
cursor/claude-opus-5-5, low effort (not Fast). - Ask it to create a new isolated folder and a small self-contained
index.html: an original pelican riding a bicycle SVG animation, no network/old assets/dependencies. - Limit the work to one write and one read-back/static validation. Explicitly instruct it to use only request-advertised tools, and use nested
tools.apply_patch/tools.exec_commandinsideexecwhen code mode is exposed. - Observe repeated OCX 400 records with the exact freeform-wrapper error above, no executable tool call reaching the host, and no HTML file.
- The task ultimately stops and reports that it could not use the execution surface.
Sanitized evidence
The fresh test lasted 218.6 seconds and completed without a deliverable.
| Request | OCX logged status | Duration | Result |
|---|---|---|---|
| A | 400 | 57.8 s | invalid freeform exec arguments |
| B | 400 | 45.9 s | same error |
| C | 400 | 38.2 s | same error |
| D | 200 | 73.3 s | final explanation, no file |
- A–C:
errorCode=invalid_request_error,failureStage=semantic-output,failureCause=payload-rejected,sideEffectEvents=0; usage unreported. - D: the usage record reports 51,754 total tokens. This is not the aggregate usage for all four requests or a final billing claim.
- Host rollout: zero executable function/custom-tool calls and zero execution results. A coordination/delegation input envelope is present, but it is not host execution.
- Actual filesystem check: target
index.htmldoes not exist. - Model narration says a native Write operation was rejected and that it could not find exec. This narration is not taken as proof that exec was absent: the adapter logs positively show exec payload validation failures. The exact offending upstream argument payload was not captured, so its shape is unknown.
Positive controls (same model, isolated protocol harness)
Advertise one function tool named exec_command with a {cmd:string} schema. Request a single harmless PowerShell stdout marker, execute the validated call on the client, send its real exit status/stdout back, and require the exact marker as the final answer.
POST /v1/responses: PASS, ~14.8 s, one real host call, exit 0, correct stdout, successful continuation.POST /v1/messages: PASS, ~54.4 s, same real host execution/result/final-answer checks.
The harness executes only the exact allowlisted command. It is a structured-tool control, not a freeform exec test or a Claude Desktop UI test. It separates connectivity/model routing from the failing Codex code-mode contract.
Local audit / expected behavior
The installed Cursor schema advertises CURSOR_FREEFORM_INPUT_SCHEMA with required input:string. In protobuf-events.ts, commitToolCall checks cursorFreeformWrapperValid(finalArgs); a failure becomes dropInvalidFreeformCall and terminates the request before host execution.
Please investigate the actual upstream argument shape and declaration/normalization path for Cursor Claude code-mode calls. Possible safe repairs should be based on captured payloads and keep fail-closed validation, byte-consistent streaming, and host-owned execution/permissions. Please do not solve this by globally enabling Cursor-native local execution. No such setting was enabled in this test.
We found no verified safe configuration-only workaround. Prompt-level bridge instructions did not prevent the failure. No local Cursor adapter code change or further expensive retry was attempted.
Related reports / distinction
- #1661 and #1830: earlier Cursor child exec-surface preservation failures. This reproduction is a fresh task on 2.84.0 with exec payload validation errors, not proof of the older missing-tool root cause.
- #399: legacy shell bridge name/redirect mismatch.
- #5047 (and #4983): generic freeform-wrapper handling; this report concerns the Cursor pre-emission validation boundary, not a demonstrated SSE delta-rewind shape.
- #6648 is Anthropic inbound undeclared Write handling; this failing task uses Codex Responses, so it is not assumed to be the same defect.
Checks
- I searched existing issues and documentation.
- Kept observed failure, model narration, and root-cause hypotheses separate.
- I removed secrets, tokens, account details, request credentials, and personal data.
- Stopped the bounded reproduction; no continuing retry or background task remains.
中文简述:Opus 5.5 的小型结构化工具调用可正常执行和回传,但真实 Codex code-mode 写 HTML 任务仍连续报 exec freeform 参数不合约,最终零本机工具执行、无产物。需排查 Cursor Claude 的参数封装/工具声明适配,不能仅凭 HTTP 200 或模型自述判断成功。
- Dominant language
- TypeScript
- Stars
- 16.9k
- Forks
- 1.3k
- Avg merge
- 6h 54m
- Merged PRs (30d)
- 606
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from lidge-jun/opencodex
-
[Provider compatibility] volcengine-coding-plan: response.incomplete relays non-canonical incomplete_details.reason ("length")Possibly taken A pull request linked to this issue is open or already merged. Openprovider provider-compatibility streaming
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
bug catalog
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
lidge-jun/opencodex#7075 · 2 comments ·
Maintainers usually reply within 1 day
-
account-pool enhancement needs-design proxy
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
lidge-jun/opencodex#6737 · 1 comment ·
Maintainers usually reply within 1 day
-
[Bug]: Codex still retries an Anthropic refusal five times because response.incomplete ignores retryable:false (follow-up to #4312)Possibly taken A pull request linked to this issue is open or already merged. Openbug streaming
Difficulty 3/5 1-2 days Newbie friendliness 45/100
Maintainers usually reply within 1 day
-
provider provider-compatibility tools
Difficulty 4/5 3-5 days Newbie friendliness 22/100
lidge-jun/opencodex#7118 · 1 comment ·
Maintainers usually reply within 1 day
All issues in lidge-jun/opencodex
Similar issues
-
documentation good first issue
Difficulty 2/5 Half a day Newbie friendliness 72/100
sujithputta02/Esapay#13 ·
-
Share dialog: the address book's contact count reads "1 contacts" (no singular form in any language)Possibly taken @chibenwa claimed this today. Openai-driven-qa bug claude Cosmetic
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
linagora/twake-contacts-frontend#271 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Koenkk/zigbee2mqtt#33402 ·
Maintainers usually reply within 1 day
-
dx P2 platform Stellar Wave Wave 10
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
winsznx/routedock#579 · 1 comment ·
Maintainers usually reply within 1 day
-
area:ui effort:S enhancement priority:P2
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day