fix(server): Cursor threads in Auto use Cursor's Auto-review#19712

Problem

Cursor threads in Auto run with Cursor's sandbox on but autoReview: false. Any command that has to leave the sandbox (a write outside the workspace, network access) is denied straight away with "Local SDK runs cannot request interactive approval for this shell command", without being reviewed. Permission modes says Auto uses the provider's automatic review on Cursor, so the only way to get those commands through today is Full access.

Closes #19711

Change

cursorRuntimeAgentPolicy now enables autoReview for auto as well as approval-required. Cursor doesn't declare supportedRuntimeModes, so auto reaches the adapter unchanged, and the old check only matched approval-required. With autoReview: true, @cursor/sdk 1.0.35 turns on its Auto-review classifier (getSmartModeClassifierAutoModeEnabled: () => autoReview === true), so escalations are reviewed before anything falls through to the SDK's deny-all decision provider.

Full access, Auto-accept edits, Supervised, and explicit approvalPolicy overrides behave as before.

Scope and approval

Bug report: #19711 (not triaged yet). This is meant as a small, focused fix for an obvious bug: one condition in the Cursor adapter plus the missing auto case in its policy test. It makes Cursor do what the permission-modes guide already documents for Auto, and doesn't touch other providers or modes.

The issue also mentions that Supervised gets autoReview: true, which is the same question #19293 raised for Muse. That's a separate behavior decision, so this PR leaves it alone.

Verification

• Reproduced on t3 v0.0.46-nightly.20261014.3132 (macOS 27.0.1, Apple Silicon): in a Cursor thread in Auto, touch ~/.t3-sandbox-probe failed with Operation not permitted. The retry with required_permissions: ["all"] was rejected with the message above. After switching the thread to Full access, the same command succeeded.

• Added an auto case to "maps runtime modes to the SDK sandbox and auto-review controls" in packages/provider-cursor/src/server/adapter.test.ts. Without the fix it fails (expected { autoReview: false, … } to deeply equal { autoReview: true, … }). With the fix, vp test run packages/provider-cursor/src/server/adapter.test.ts passes 13 of 13.

• vpr typecheck in packages/provider-cursor, vp lint, and vp fmt --check on the changed files are clean.

• Live check on this branch (vp run dev, macOS, Cursor thread in Auto):

  • curl -sI https://example.com failed inside the sandbox on DNS lookup. The retry with network access was approved by Cursor's Auto-review without a prompt and returned HTTP/2 200. Before the fix, Auto escalations got the fixed "cannot request interactive approval" denial instead (the touch reproduction above).
  • A request worded as a sandbox escape test was declined by the classifier itself ("Network breakout and escape testing outside sandbox controls require user confirmation") rather than by the SDK's fixed denial. That confirms escalations now reach the reviewer, which still declines what it judges risky.

  The Auto thread on the dev build, and the branch it ran from:

  Cursor thread in Auto: curl to example.com returns HTTP/2 200 after Auto-review allows the network retry

  Dev build's branch panel showing cursor-auto-mode-auto-review with +11 −1 changes

Claude Opus 5.5 via Cursor in T3 Code