[Bug]: Cursor provider still prompts for tool approvals in Full access and Auto runtime modes

[kevinavos]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Use T3 Code with the Cursor provider (cursor-agent ACP).
2. Set the thread runtime mode to Full access (or Auto).
3. Ask the agent to run a shell command that is not in ~/.cursor/cli-config.json permissions.allow (for example npm test), or to use an MCP tool such as T3 preview navigate.
4. Observe session/request_permission from Cursor ACP and a T3 approval card in the composer.

Expected behavior

• Full access should not ask the user to approve ordinary tool calls. Cursor ACP permission requests should be auto-answered, or cursor-agent should be launched in a run-everything / auto-review mode that matches T3's Full access.
• Auto should either map to Cursor Auto-review (--auto-review) or the UI should make it clear that Auto is Codex/Claude-only and Cursor still prompts.

Actual behavior

T3 still shows lots of tool-approval prompts.

Two layers:

1. T3 Auto does not auto-approve Cursor. PR feat: add "Auto" runtime mode — AI-reviewed approvals for Codex and Claude #4272 documents that Cursor/Grok/OpenCode fall through to existing non-full-access behavior. Selecting Auto in the composer still routes Cursor session/request_permission to the user.

2. Even Full access, T3 does not start Cursor in yolo/auto-review. buildCursorAcpSpawnInput launches:

   cursor-agent acp
   

   with no --force / --yolo / --auto-review. The ACP process then uses the user's Cursor CLI allowlist (approvalMode: "allowlist" in ~/.cursor/cli-config.json). Native ACP logs show Not in allowlist: npm test (and similar) and then session/request_permission with allow_once / allow_always / reject_once.

   CursorAdapter only auto-selects those options when runtimeMode === "full-access" and selectAutoApprovedPermissionOption finds allow_always or allow_once. On a Full access Cursor thread we still saw request.opened / composer approval cards for shell, WebFetch, and MCP dynamic_tool_call (t3-code-preview_navigate).

Related: #2823 (Cursor permission-alert loop with Xcode MCP) is a different symptom. This report is about T3 runtime modes not actually suppressing Cursor tool approvals.

Impact

Major degradation or frequent failure

Version or commit

T3 Code 0.0.33 (t3@0.0.33 background service)

Environment

Linux (Ubuntu), cursor-agent 2026.08.11-e8db854, Cursor provider instance cursor, model auto-smart. ~/.cursor/cli-config.json has approvalMode: "allowlist".

Logs or stack traces

Cursor ACP permission request from a Full access thread (~/.t3/userdata/logs/provider/events.<threadId>.log):

method: session/request_permission
toolCall.kind: execute
content: Not in allowlist: npm test
options: allow_once, allow_always, reject_once

Same thread later stuck on MCP:

approval.requested  requestType=dynamic_tool_call
detail=t3-code-preview_navigate: preview_navigate

Workaround

Use T3 Full access rather than Auto (Auto is a no-op for Cursor). Grow the Cursor CLI allowlist, or run Cursor CLI itself with --force / yolo outside T3. T3 does not pass those flags today.