Cursor Auto repeats a successful exec call after tool continuation on 2.100.2 #8538

Client or integration

Codex Desktop (primary reproduction), Codex CLI, and direct HTTP to the local OpenCodex proxy.

Provider or upstream service

Cursor OAuth, model cursor/auto (Cursor wire model default). The model selected internally by Auto is unknown.

OpenCodex version

@bitkyc08/opencodex 2.100.2 (npm), which includes #8492. Linux x86-64; Codex Desktop runtime 0.167.0-alpha.4.1, Codex CLI 0.167.0. Cursor native local execution was not enabled.

Endpoint or capability

/v1/responses: continuation after a successful Codex code-mode exec result.

Current behaviour

On stock 2.100.2, Cursor Auto can execute a client tool successfully and then ask to execute the same command again, without a final answer. This follows up on #8132: #8492 fixes the guidance for finding the deferred tool; here, the tool is found and the local command succeeds. The failure is what happens after the result.

Expected behaviour

For a request to run one read-only command once, consume the successful result, report it, and finish without another tool call.

Minimal redacted request or reproduction

Start a fresh Codex chat, select cursor/auto, and ask (English translation of the same prompt used in all live trials):

Run hostname exactly once on the local machine. Report the result, then finish. Do not use SSH.

Observe the actual commands and final response. In the direct HTTP harness, the first request advertised one custom exec tool. When it returned an exec call for hostname, the harness itself ran the fixed command once. It sent the real output as custom_tool_call_output with the matching call_id and previous_response_id. The harness counted a further call but did not execute it or evaluate model-generated code.

Actual response or error

• Codex Desktop, stock: eight successful hostname executions, then manual interruption at about 80 s, with no final answer. A separate debug run stopped after three successful executions; OpenCodex logged three tool-continuation requests for the same Cursor conversation, all using resumeAction.
• Codex CLI, alternate A/B trials: stock A repeated hostname in 3/3 trials (stopped on the second success). B returned the expected hostname and finished after one command in 3/3. The proxy logged both requests in those CLI runs as initial, so the CLI comparison alone does not distinguish the continuation action.
• Direct HTTP, explicit tool-output continuation: the four-way comparison below used the same prompt, machine, Cursor account, requested Auto route and successful tool result. The local copies differ only in how the Cursor encoder handles the result.
• Codex Desktop, D: in the same working directory as the stock test, one successful command and the correct final answer in 11.9 s. The lab proxy logged two HTTP 200 requests: the initial request and a tool-continuation using resumeAction.

One C trial did not produce the initial tool call and was replaced; it never tested continuation. The table covers the replacement and the other trials that reached continuation. Earlier direct A/B probes gave the same respective outcomes.

Comparison with Composer and Grok

After updating to 2.100.2, stock Composer 2.5 completed the same minimal hostname prompt in a fresh Desktop chat in the same working directory: one successful command and a final answer in 8.9 s. In a separate read-only Bitwarden verification, Composer 2.5 and Grok 4.7 both reached a final answer, while Auto repeated preliminary checks without reaching the Flatpak verification.

These are post-update comparisons, not proof that #8492 fixed either model. Composer had also passed a short tool test before the update; the earlier Composer retries were observed on a longer build task and did not establish the same cause. I do not have a matching pre-update Grok reproduction. The controlled before/after comparison in this report holds Auto constant and changes only the lab proxy's handling of the tool result.

Upstream documentation

I did not find a public Cursor protocol guarantee that specifies which part of the replayed state reaches the selected Auto model. The expected behaviour here is a concrete client requirement: a successful one-command task should terminate after reporting its result.

Suggested mapping or implementation notes

An offline check decoded the emitted protobuf and referenced blobs for all four variants using the same synthetic result. All four kept the paired structured MCP result. B and D also put the result into the text history; A and C did not. The tests isolate a condition that helped in this reproduction, not whether Cursor hydrated or showed the structured result to the selected model.

In the 2.100.2 encoder, D enabled the existing text replay for Auto in the history builder (and its corresponding checkpoint retention check), while leaving the continuation action selection unchanged. The captured continuations used full replay with no checkpoint.

D is a diagnostic patch, not a proposed blanket revert. #2317 / #2318 show that replaying the same text can make native Auto echo the tool-result envelope in chat. A production fix should account for that regression. We have not tested long workflows, checkpoint continuations or a broad sample of Auto routing.

Additional context and attachments

Related: #8132 / #8492 (deferred-tool discovery); #604 (an older Windows/PowerShell reproduction, often after failed commands). This report uses one successful command under Linux and isolates the result encoding. No raw logs, screenshots, credentials, hostnames, account IDs or private paths are attached.

Checks

• I searched existing provider and compatibility issues.
• The request and response evidence was redacted.
• The expected behaviour is based on a concrete client requirement.