Cursor provider fails through local ACP with internal max-retries error

This was generated by AI during triage.

Summary

Cursor does not currently work through T3 Code on macOS, although both Cursor CLI entry points work normally in local interactive mode. T3 reports a generic Cursor reported a transport failure, while the underlying Cursor response is Error: RetriableError: [internal] Failed to run step, exceeded max retries.

Environment

• T3 Code early-access build: v2026.09.02-c22c1a3
• Cursor Agent: v2026.09.02-c22c1a3
• macOS
• Cursor Ultra subscription
• Cursor model tested: Grok 4.6
• Binary paths tested: cursor-agent and agent
• Execution is local on the machine, not a cloud T3 environment

What works

Both local interactive commands work in Hitch terminals:

• Terminal 1: agent starts, authenticates, and responds to hey.
• Terminal 2: cursor-agent starts, authenticates, responds to hey, and successfully runs pwd.
• The local Cursor CLI can reach Cursor services and use Grok 4.6 interactively.

Reproduction in T3

1. Enable the Cursor provider in T3 Code.
2. Set Binary path to either cursor-agent or agent.
3. Use the authenticated Cursor account and Grok 4.6.
4. Start a Cursor thread and send a simple prompt such as hey.
5. T3 displays:

Cursor reported a transport failure.

Error: RetriableError: [internal] Failed to run step, exceeded max retries

Findings

T3 launches Cursor through the local ACP process, currently equivalent to:

agent --force acp

In the T3 provider log, the ACP initialize, authenticate, session/new, and session/prompt requests are recorded as successful. The assistant content itself contains the max-retries error. T3 then classifies that diagnostic as a transport failure in apps/server/src/provider/acp/CursorTransportFailure.ts.

A direct Hitch test of agent --force acp confirmed that ACP initialization succeeds. The process then failed to complete the subsequent authentication/session exchange, whereas interactive mode continues to work.

This suggests the issue is specific to Cursor Agent ACP mode or to the ACP request/context sent by T3, rather than:

• the binary name or PATH;
• Cursor authentication generally;
• the local machine’s network connectivity;
• T3 cloud execution; or
• a general Grok 4.6 outage.

T3 does not currently use Cursor’s SDK; it uses Cursor’s local Agent CLI over ACP/stdin/stdout JSON-RPC.

Expected behavior

A Cursor ACP session started by T3 should authenticate, create a session, and successfully process a simple prompt using the selected model. If Cursor returns an internal agent error, T3 should surface the underlying error distinctly from a transport failure.

Screenshots

Suggested next investigation

• Compare T3’s ACP handshake and prompt payload with Cursor’s documented minimal ACP client flow.
• Test the same flow with and without T3’s --force permission flag.
• Test against a newer Cursor Agent/nightly build if available.
• Preserve the original Cursor ACP error instead of mapping it only to Cursor reported a transport failure.

Start with apps/server/src/provider/acp/CursorTransportFailure.ts and trace the local ACP initialize, authenticate, session/new, and session/prompt flow. Compare T3’s handshake and prompt payload with the documented minimal ACP client flow, including behavior with and without --force. Done means a simple authenticated Cursor prompt succeeds or the underlying Cursor error is surfaced distinctly from a transport failure.