Smart Mode / Auto-Review approval card never renders for blocked MCP tool calls (macOS, cursor-ide-browser)

Support Bug Reports
, , , ,
1

Where does the bug appear (feature/product)?

Chat / Composer (Agent) — Auto-Run / Smart Mode (Auto-Review) tool-approval UI, specifically for MCP tool calls.

Describe the Bug

When the agent makes an autonomous tool call that Auto-Review (Smart Mode) blocks, the agent is supposed to retry the same call with an “approval requested” flag so a native approval card appears for me to approve or reject. The approval card never renders. From my side there is nothing to approve — the chat just shows the agent “waiting”, and the only way out is to manually interrupt the call.

This reproduces reliably with MCP tool calls that Auto-Review flags — in my case the built-in cursor-ide-browser browser_cdp tool (a Runtime.evaluate reusing an authenticated browser session). In an earlier occurrence the underlying error surfaced as “could not find bubble”, which lines up with the approval card not being anchored to a valid message bubble.

This is the macOS + cursor-ide-browser follow-up to @deanrie’s investigation in the Git commit approval UI missing thread. It confirms the missing-card failure is not specific to destructive git commands, the sandbox-less Windows path, or any single block reason — it happens whenever an MCP tool call gets routed through the Smart Mode approval path.

Request IDs for a specific stuck call (not in Privacy Mode, so these should be complete):

  • Smart Mode approval request ID: c5eea9e0-1183-4b7e-b0a2-2ddb66056377
  • Chat-turn Request ID (Copy Request ID): 659ebd68-6af2-4ea5-9c39-f7d42e9b492a

For that call: tool status came back cancelled (after I manually interrupted the hung “waiting” state), blockReason: smartMode, and the internal reviewData.status never left None — i.e. no approval was ever resolved through a card.

Steps to Reproduce

  1. Agent (Composer) with Auto-Run on and Smart Mode / Auto-Review active.
  2. Agent makes an autonomous tool call that Auto-Review classifies as needing approval — e.g. an MCP cursor-ide-browser browser_cdp Runtime.evaluate reusing an authenticated session.
  3. Auto-Review blocks the call; the agent retries requesting approval so a native card should appear.
  4. Observe: no approval card renders — nothing to approve, the call hangs in “waiting” until manually interrupted.
  5. For comparison: regular file edits and most terminal commands still show the approval UI normally.

Expected Behavior

Whenever a tool call requests user approval — including MCP tool calls — a native approval card (Approve / Reject) should always render and be anchored to a valid message bubble. If the bubble can’t be located, surface a fallback approval affordance rather than silently rendering nothing.

Actual Behavior

No approval UI is rendered for the blocked MCP tool call. The agent enters a “waiting” state with no Approve/Reject button. The call only ends when manually interrupted (tool status cancelled). In an earlier occurrence the failure surfaced as “could not find bubble”.

Operating System

macOS (Apple Silicon)

Version Information

Version: 3.9.8
VS Code Extension API: 1.105.1
Commit: 4aa8ff1b7877ed7bd01bcba308698f71a6735380
Date: 2026-06-25T01:39:30.490Z
OS: macOS

Does this stop you from using Cursor?

No - Cursor works, but with this issue

Additional Information

Workarounds are limited and undesirable: interrupt the hung call, or broadly disable Auto-Review / set Auto-Run to “Run Everything” / “Auto-Run in Sandbox” — which removes the per-call approval gate entirely, defeating its purpose.

6

Thanks @OmryA! This is a known issue we’re tracking with browser tool calls, and I’ve added your report.

8

Thanks @Colin, glad it’s already tracked and appreciate you linking my report in. Nothing further needed from my side for now — happy to grab a fresh Request ID or logs for any specific occurrence if that would help the investigation.