Cursor Agent works correctly in direct interactive CLI mode, but consistently fails when invoked through its ACP stdin/stdout JSON-RPC interface by T3 Code. ACP initialization, authentication, and session creation succeed. Every session/prompt request then fails almost immediately with:
Error: RetriableError: [internal] Failed to run step, exceeded max retries
T3 sometimes displays this as ‘Cursor reported a transport failure,’ but the underlying response is the Cursor RetriableError above.
Steps to Reproduce
Authenticate Cursor Agent normally.
In a completely empty folder, confirm that a direct interactive Cursor Agent prompt works.
Configure T3 Code to use the local cursor-agent binary through ACP.
Create a completely new T3 session.
Send a minimal prompt such as ‘hey’.
The ACP prompt fails almost immediately with the max-retries error.
Repeating the prompt or allowing three automatic retries produces the same error each time.
Expected Behavior
An authenticated ACP session should process the same basic prompt that succeeds through the direct interactive Cursor Agent CLI. If the backend cannot process it, ACP should return an actionable diagnostic and Request ID.
Operating System
MacOS
Version Information
IDE:
Cursor 3.20.17
CLI:
Cursor Agent 2026.09.10-fd3934a
OS:
macOS
For AI issues: which model did you use?
Auto and Composer 2.5. Direct CLI smoke tests succeed with both the default model and --model auto.
For AI issues: add Request ID with privacy disabled
No Request ID is exposed in the Cursor Agent ACP response. It returns only: Error: RetriableError: [internal] Failed to run step, exceeded max retries
Additional Information
Troubleshooting already completed:
Clean-installed Cursor IDE and Cursor Agent CLI.
Confirmed direct CLI prompts work with the default model and --model auto.
Confirmed Cursor Agent authentication succeeds.
Confirmed api2.cursor.sh is reachable with valid TLS and HTTP 200.
Confirmed no HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY environment variables are set.
Tested fresh T3 threads and a completely empty folder.
Tested Auto, Composer 2.5, Full Access, and auto-accept modes.
Tested a T3 build that retries Cursor ACP failures three times; every retry failed identically.
session/new succeeds; the failure occurs during session/prompt.
This appears specific to Cursor Agent’s ACP execution path rather than installation, authentication, project contents, model selection, or general Cursor service connectivity.
Related T3 Code issue:
Related Cursor forum acknowledgement of the same error:
Please advise how to collect the corresponding Request ID or diagnostic bundle from Cursor Agent ACP mode.
Hey @plutotom, thanks for the detailed report, and for testing both paths.
I found your requests on our side. The failure is not network or auth-related. Every prompt sent through T3 Code arrives at the model at roughly 570,000 tokens, which is about 3x more than the model accepts. Your direct CLI prompts arrive at 12k to 30k tokens, which is why those work.
That extra ~550k tokens is probaly always-on context that gets loaded from the folder the session runs in: rules files (.cursor/rules, AGENTS.md, CLAUDE.md, including ones in parent folders and subfolders), skills, and MCP tool definitions.
Could you try this so we can pin it down?
In T3 Code, note the exact project folder path for the thread that fails.
Open a terminal and cd into that same folder.
Run agent (interactive mode) and send the prompt hey.
Once it answers (or fails), type /context and press Enter. It shows a breakdown of what is in the context (rules, MCP tools, skills, etc.).
Reply with that breakdown, plus: does that folder or any parent folder up to your home directory contain an AGENTS.md, CLAUDE.md, .cursor/rules, .claude or .codex folder? And how many MCP servers are in ~/.cursor/mcp.json or the project’s .cursor/mcp.json?
If the interactive run in that folder also fails or shows a very large context, the fix is to trim that context.
I got curious and ran a trace locally of the raw ACP request/response trace. Here is the resaults.
/Users/proctoi/Desktop/test-t3`
Cursor Agent version: 2026.09.10-fd3934a
Request sizes
Direction
Message
Bytes
T3 → Cursor
initialize
369
T3 → Cursor
authenticate
195
T3 → Cursor
session/new
387
T3 → Cursor
session/prompt
535
T3 → Cursor
Complete stream
1,490
Cursor → T3
Complete stream
18,490
Cursor emitted these ACP updates:
session_info_update: 176 bytes
available_commands_update: 12,405 bytes
agent_message_chunk: 268 bytes, containing Error: RetriableError: [internal] Failed to run step, exceeded max retries
Cursor then returned a successful JSON-RPC response for the prompt with stopReason: "end_turn". The failure is therefore delivered as assistant text,
not as a JSON-RPC error object.
It seems that t3 Code did not send the 500k token prompt, but that it must be assembled or duplicated after the local Cursor Agent receives the ACP request—inside Cursor’s ACP context construction or backend request path.
Hey @plutotom, thanks for running that test and for the trace, that pinned it down!
You’re right that the extra context is added on our side, not by T3 Code. It is the tool definitions from your MCP servers. In the interactive CLI and the IDE, MCP tools are loaded on demand (that is why /context only shows 6.9K for MCP). The ACP mode that T3 Code uses does not do that yet: it sends the full definition of every tool from every configured MCP server with each prompt, which in your setup is about 259 tools and roughly 490k tokens. That alone is more than the model’s context window, so the request fails before the model ever sees “hey”. I’ve flagged this to the team.
In the meantime you can work around it by disabling the MCP servers for that project, which ACP respects:
Open a terminal and cd /Users/proctoi/Desktop/test-t3 (the disable list is per project, so this has to be the same folder T3 uses).
Run agent mcp list to see the server names.
Run agent mcp disable <name> for each server (Vercel, PostHog, Better Auth, Sentry).
Start a brand new thread in T3 Code and send hey.
If that works, you can re-enable them one at a time with agent mcp enable <name> to find out which one carries most of the weight (PostHog and Vercel tend to be the largest). Interactive agent sessions in that folder will also stop using those servers until you re-enable them.
Let me know if the prompt still fails with all four disabled and I’ll dig further.
