Git commit approval UI missing — other agent approvals work fine

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Agent approval UI works normally for file edits and most terminal commands, but specifically fails for git commit operations.

When the agent runs git add + git commit, no approval card appears (Run / Approve / Skip / Allowlist). The agent shows “Waiting for approval…” or eventually times out with “Rejected: Review cancelled or failed”.

Other agent actions work correctly and show the approval UI as expected, including:

  • File edits (read / write / search_replace)
  • git status, git diff, git log

Manual git commit in the integrated terminal works fine. The issue only affects Agent-initiated git commit operations.

This started recently (after a Cursor update). Previously, agent git commits showed the approval dialog normally.

Workaround: I run git add and git commit manually in the integrated terminal. The agent cannot complete commits on its own.

Environment notes:

  • Shell: PowerShell (integrated terminal)
  • On Windows, use git add ...; git commit -m "..." (not &&) when testing manually

This appears related to special handling of “destructive” git commands (commit / push / reset) vs normal agent approvals.

Steps to Reproduce

  1. Open Agent mode in Cursor IDE
  2. Make some code changes in a git repository
  3. Ask the Agent: “Registre as modificações no git” (or explicitly: git add + git commit)
  4. Observe: no approval card appears for the git commit step
  5. The Agent shows “Waiting for approval…” or appears stuck
  6. Eventually fails with “Rejected: Review cancelled or failed”, or the user must click Stop

For comparison:

  • Ask the Agent to run git status or git diff → approval UI appears normally
  • Run git commit manually in the integrated terminal → works without issue

Expected Behavior

When the Agent requests to run git commit, an approval card should appear in the chat UI (Run / Approve / Skip / Allowlist), same as for other agent terminal commands and file edits.

The user should be able to approve or reject the commit before it executes.

Actual Behavior

No approval UI is rendered for git commit operations initiated by the Agent.

The Agent enters “Waiting for approval…” state but no Approve/Run button is visible.

The operation eventually fails with “Rejected: Review cancelled or failed”, or the user must click Stop.

Manual git commit in the terminal works; only Agent-initiated commits are affected.

Operating System

Windows 10/11

Version Information

Version: 3.8.11 (user setup)
VS Code Extension API: 1.105.1
Commit: e56ad3440df06d22ca7501e65fd518e905486ef0
Date: 2026-06-18T01:40:18.333Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

Additional Information

Settings (collected from local Cursor logs + config files on 2026-06-19):

  • Auto-Run mode: Allowlist mode (approvalMode: “allowlist”, userConfiguredPolicyType: “insecure_none”)
  • Sandbox: Disabled (isSandboxEnabled: false, isSandboxAvailable: false on Windows)
  • Legacy Terminal Tool: Not detected in user settings.json (using unified Agent terminal flow)
  • Smart Allowlist: Disabled (smartAllowlistEnabled: false)
  • Agent layout: unifiedAgent (Cursor 3.8.11 Stable)
  • UI theme: One Dark Pro (not High Contrast)

Command Allowlist behavior (from Cursor structured logs):

  • Auto-approved (on allowlist): git status, git diff --stat
  • Requires manual approval (NOT on allowlist): git log -5 --oneline, git commit
  • git commit cannot be allowlisted in some cases (canAllowlist: false for destructive git commands)

commit.gpgsign:

  • Local repo: not set (defaults to unsigned commits)
  • Global ~/.gitconfig: not set
  • Manual git commit in terminal works without GPG prompt

Shell / terminal:

  • Default integrated terminal profile: Cmder (cmd.exe)
  • Project shell: PowerShell/Cmder (Windows)

Internal log evidence (Cursor Structured Logs.log):

  • Backend reaches: “Shell permissions: requesting shell approval”
  • approvalReasonTypes: [“unapproved_commands”]
  • UI does NOT render approval card for git commit
  • Failure ends as: blockReasonType: “userRejected” (user clicks Stop after invisible wait)
  • Example timestamps: 2026-06-19 10:27:15, 11:07:22, 11:50:06

Related forum threads:

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report. We rarely get this level of diagnostics.

It looks like the issue is how Auto-review Smart Mode handles destructive git commands commit push reset on Windows without sandbox. Read-only git actions like status diff and file edits go through and get approved fine, but git commit gets routed into a separate approval path, and in your case the approval card doesn’t finish rendering. We’re digging into it, but I need confirmation from you.

Can you send the Request ID for a specific stuck git commit? Chat menu top right corner > Copy Request ID. If Privacy Mode is enabled, the ID may be limited, so let me know.

For now, here are a couple workarounds:

  1. Add git commit to the Auto-Run allowlist Settings > Auto-Run, then it will auto-approve and skip the classifier.
  2. If the card is stuck on Waiting for approval, switch to another agent tab and back. Sometimes that forces a re-render.
  3. Make sure you’re on the latest build.

Let me know if any of that helped, and send the Request ID. With that I can dig deeper.

6

Seeing what looks like the same Auto-review Smart Mode approval-card bug @deanrie described, but it’s broader than git commits / Windows — I hit it on macOS with an MCP tool call, so the “routed into a separate approval path → approval card never finishes rendering” failure isn’t specific to destructive git commands or to the sandbox-less Windows path.

My case: Agent in Auto-Run + Smart Mode. Auto-Review blocked an autonomous MCP call — the built-in cursor-ide-browser browser_cdp tool (a Runtime.evaluate that reused an authenticated session) — with a “this would expose credential material / authenticated request” reason. The agent then retried the same call with the approval-requested flag so a native approval card should appear. No card renders. From my side there’s nothing to approve: the chat just shows the agent “waiting”, and the only way out is to manually interrupt the call. 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.

Reproduces reliably with MCP tool calls that Auto-Review flags:

  1. Agent (Composer) with Auto-Run on and Smart Mode / Auto-Review active.
  2. Agent makes an autonomous tool call Auto-Review classifies as needing approval (e.g. an MCP cursor-ide-browser browser_cdp Runtime.evaluate reusing an authenticated session / touching credential material).
  3. Auto-Review blocks it; the agent retries requesting approval so a native card should appear.
  4. No approval card renders — nothing to approve, the call hangs until manually interrupted.

Impact: fully blocks any agent action Auto-Review flags — the only workarounds are interrupting the call or broadly disabling Auto-Review / enabling Auto-Run, which defeats the per-call approval gate.

Suggested fix: ensure the approval card is always rendered (and anchored to a valid message bubble) whenever a tool call requests user approval, including MCP tool calls; surface a fallback approval affordance if the bubble can’t be located instead of silently rendering nothing.

Environment:

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

Happy to send a Request ID for a specific stuck call if that helps the investigation — just let me know which occurrence you’d like.

7

Hey, thanks for the detailed report. It helps that you confirmed the issue isn’t tied to a git commit or Windows. The same thing shows up on macOS during an MCP call to cursor-ide-browser, when Auto-Review blocks the call and the agent retries with an approval request, but the card never renders. The detail about “could not find bubble” is also relevant.

This case the approval card not showing up for MCP browser tools is already on our radar separately from the git-commit case. I can’t share an ETA for a fix yet.

What would help:

  1. Share the Request ID for a specific stuck call. In chat, top-right menu > Copy Request ID. If Privacy Mode is on, the ID might be limited, let me know. This is the most useful thing for investigation.
  2. To avoid mixing the git-commit bug and your MCP-browser case in one thread, it’s best to open a separate thread for macOS + cursor-ide-browser. That makes it easier to track. You can create it and I’ll follow up.

For a workaround, the only thing that reliably unblocks it right now is: Settings > Agents > Auto-Run Mode > “Run Everything” or “Auto-Run in Sandbox”. I know that’s exactly the tradeoff you want to avoid since it removes the per-call approval gate entirely. So it’s temporary, not a real fix. The Request ID will help us get to the root cause.

8

Thanks @deanrie. Good call on splitting it out — I’ve opened a dedicated thread for the macOS + cursor-ide-browser case so it doesn’t tangle with the Windows git-commit bug, and I’ll link it here once it’s up.

Pulling the IDs from the session where it happened (ironically, the very session I was using to post about this bug):

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

Details of that specific stuck call:

  • Tool: cursor-ide-browser browser_cdp → Runtime.evaluate (an authenticated request reusing the logged-in browser session).
  • Auto-Review (Smart Mode) blocked the autonomous call, the agent retried requesting approval, and no approval card rendered. The call sat in “waiting” and the only way out was to manually interrupt it — the final tool status came back cancelled, with the internal reviewData.status never leaving None.
  • In this occurrence Auto-Review’s stated reason was about posting before showing a draft (not the credential-material reason from my earlier example), which suggests the missing-card failure isn’t tied to any one block reason — it happens whenever an MCP browser_cdp call gets routed through the Smart Mode approval path.

Not in Privacy Mode, so those IDs should be complete on your end — let me know if you need a different occurrence or anything else.

9

Dedicated thread is up here: Smart Mode / Auto-Review approval card never renders for blocked MCP tool calls (macOS, cursor-ide-browser) — happy to continue the macOS + cursor-ide-browser investigation there. Thanks @deanrie!

10

Thanks @OmryA, I see there’s already a separate thread and both Request IDs are in the first post, so no need to duplicate anything. My teammates will continue the macOS + cursor-ide-browser discussion there so it doesn’t get mixed up with the git commit case. These are two different code paths, so keeping them separate is the right call.

@brunorafaeI, for Windows + git commit I’m still waiting on the Request ID from the specific commit that got stuck, so I can dig into that exact case. It’s different from the MCP case above. Chat menu in the top right corner > Copy Request ID. If Privacy Mode is enabled, the ID might be limited, let me know. For now the workaround is the same: add git commit to the Auto-Run allowlist Cursor Settings (not VS Code settings) > Auto-Run, then it’ll auto-approve and bypass the classifier.

11

Thanks @deanrie, sounds good — agreed on keeping the two code paths separate. I’ll keep the macOS + cursor-ide-browser discussion in the dedicated thread. Appreciate the coordination.