Before submitting
Area
apps/server
Steps to reproduce
Cursor CLI documents API keys as a first-class auth method: https://cursor.com/docs/cli/reference/authentication
- Install Cursor CLI. Do not run
agent login.
- Export a valid
CURSOR_API_KEY (or pass --api-key). See the same auth doc and https://cursor.com/docs/cli/reference/parameters
- Confirm the CLI itself works:
cursor-agent models lists models.
- Confirm
cursor-agent about --format json returns "userEmail": null (no saved login).
- Enable the Cursor provider in T3 Code on that same machine / environment.
Expected behavior
T3 treats the official API-key session as authenticated, discovers models, and can start a Cursor thread. Same shape as Grok's XAI_API_KEY path.
Actual behavior
- Provider status is unauthenticated:
Cursor Agent is not authenticated. Run \agent login` and try again.`
- After that check is satisfied, ACP model discovery fails. T3 always sends ACP
authenticate with cursor_login, and the CLI tries to open a browser even though CURSOR_API_KEY is already enough for session/new and cursor/list_available_models.
T3's Cursor probe only looks at agent about userEmail (apps/server/src/provider/Layers/CursorProvider.ts) and hardcodes authMethodId: "cursor_login" (apps/server/src/provider/acp/CursorAcpSupport.ts). It never reads CURSOR_API_KEY.
Impact
Major degradation or frequent failure
Headless / CI / API-key-only hosts cannot use Cursor in T3 even when the CLI is healthy.
Version or commit
main @ d23b181
Environment
macOS, Cursor CLI 2026.08.11, T3 Code server driving cursor-agent
Logs or stack traces
cursor-agent about --format json
{
"cliVersion": "2026.08.11-e8db854",
"userEmail": null,
"subscriptionTier": null
}
ACP authenticate / cursor_login:
{"error":{"code":-32602,"message":"Invalid params","data":{"message":"Failed to open browser for login. Please visit: https://cursor.com/loginDeepControl?..."}}}
session/new and cursor/list_available_models succeed with the same CURSOR_API_KEY if authenticate is skipped.
Workaround
Run agent login so about has an email. That is the interactive path, not the documented API-key path.
Before submitting
Area
apps/server
Steps to reproduce
Cursor CLI documents API keys as a first-class auth method: https://cursor.com/docs/cli/reference/authentication
agent login.CURSOR_API_KEY(or pass--api-key). See the same auth doc and https://cursor.com/docs/cli/reference/parameterscursor-agent modelslists models.cursor-agent about --format jsonreturns"userEmail": null(no saved login).Expected behavior
T3 treats the official API-key session as authenticated, discovers models, and can start a Cursor thread. Same shape as Grok's
XAI_API_KEYpath.Actual behavior
Cursor Agent is not authenticated. Run \agent login` and try again.`authenticatewithcursor_login, and the CLI tries to open a browser even thoughCURSOR_API_KEYis already enough forsession/newandcursor/list_available_models.T3's Cursor probe only looks at
agent aboutuserEmail(apps/server/src/provider/Layers/CursorProvider.ts) and hardcodesauthMethodId: "cursor_login"(apps/server/src/provider/acp/CursorAcpSupport.ts). It never readsCURSOR_API_KEY.Impact
Major degradation or frequent failure
Headless / CI / API-key-only hosts cannot use Cursor in T3 even when the CLI is healthy.
Version or commit
main @ d23b181
Environment
macOS, Cursor CLI 2026.08.11, T3 Code server driving
cursor-agentLogs or stack traces
session/newandcursor/list_available_modelssucceed with the sameCURSOR_API_KEYifauthenticateis skipped.Workaround
Run
agent loginsoabouthas an email. That is the interactive path, not the documented API-key path.