Where does the bug appear (feature/product)?
Cursor CLI
Describe the Bug
I use the Cursor agent through PyCharm’s ACP integration, not the Cursor desktop app.
When the network hiccups (DNS flake, brief disconnect), the agent dies on the first try and shows something like RetriableError. The name says retriable — but nothing retries. I have to send the same prompt again, and it often works.
So: transient failure → instant fail → manual retry works. That’s annoying and avoidable.
I already turned on useHttp1ForAgent in config. Didn’t fix this.
Steps to Reproduce
- PyCharm 2026.2 + Cursor ACP agent
- Send a normal agent prompt
- Hit a brief network/DNS glitch (or wait for one — they’re intermittent on my corp VPN)
- Prompt fails with connection / RetriableError
- Send the same prompt again → usually succeeds
Expected Behavior
If the connection fails briefly, the agent should retry automatically a few times before giving up — same idea as when it works in other Cursor paths.
Operating System
Windows 10/11
Version Information
• PyCharm: 2026.2 (ACP)
• Cursor ACP bundle: 2026.09.10 (under JetBrains acp-agents\cursor)
• Model: Composer 2.5
• Config: useHttp1ForAgent: true in ~/.cursor/cli-config.json
Additional Information
What the logs actually say
Log file: %LOCALAPPDATA%\Temp\cursor-agent-logs-\session-*.log
Log tag: [nal_agent_retries]
On failure you get something like:
{
“decision”: “THROW RetriableError”,
“willRetry”: false,
“enableAgentRetries”: false,
“transportErrorRetries”: 0,
“attempt”: 0,
“errorName”: “ConnectError”
}
Then immediately: [nal_agent_retries] Error not retryable So the UI says RetriableError, but the retry machinery is off (enableAgentRetries: false) and it never gets past attempt 0.
Errors I’ve seen on api2.cursor.sh:
• getaddrinfo EAI_AGAIN
• getaddrinfo ENOTFOUND
• ECONNRESET / socket hang up
Same session log often shows successful [nal_agent_retries] Request successful on the next manual prompt — so it’s not “Cursor is down,” it’s “one flake, zero retries.”
== Why I think this is an ACP wiring bug (not user config):
There is no enableAgentRetries, transportErrorRetries, or retry-timeout setting in ~/.cursor/cli-config.json. Only network knob I have is useHttp1ForAgent (already true).
In the bundled agent (2026.09.10):
• IDE / headless CLI paths set enableAgentRetries using helper w5(“userMessageAction”) → true for normal prompts.
• ACP agent-session.ts builds the run-options object passed to agentClient.run() without enableAgentRetries at all — just conversationId, headers, requestedModel, callbacks, etc.
The retry classifier only retries transport errors when enableAgentRetries || endlessRetries is true. If enableAgentRetries is missing, it’s treated as false → throw on first failure, even for errors classified as RetriableError with DNS codes like EAI_AGAIN / ENOTFOUND (which the classifier does recognize as transport).
Feature flag nal_agent_retries appears enabled in the bundle, but without enableAgentRetries on the ACP run options, it doesn’t help.
=== What should happen (technical):
For userMessageAction, ACP should pass the same thing IDE/CLI does: enableAgentRetries: w5(“userMessageAction”) → true
Then transient DNS/connection errors should get automatic retries with backoff (built-in transport retry budget — up to ~10 in non-test mode) instead of failing instantly.
=== Related threads
Staff have acknowledged ACP missing retry behavior elsewhere:
• Direct CLI retries transient errors; ACP does not
This looks like the same class of problem, with a specific root cause: ACP agent-session.ts omits enableAgentRetries.
=== Workaround
Resend the prompt manually when it fails.
=== Not asking for
DNS flush lectures or corporate IT tickets — I have log evidence of intermittent flakes plus zero automatic retries on the ACP path.
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor