Subagent Allow/Stop button layout shift causes accidental agent termination

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When a background subagent requires tool-call approval, the UI replaces the Stop button with an Allow button and relocates Stop to the left of it. After clicking Allow, if no more approvals are pending, the Allow button disappears and Stop shifts right back to the position where Allow just was.

When multiple consecutive tool calls require approval, the user clicks Allow rapidly. On the final click — when no more approvals remain — the Allow button vanishes mid-click-sequence, and the Stop button slides into the exact position where Allow was. The user’s next click (intended for another Allow) lands on Stop, unintentionally terminating the subagent.

This is a classic layout-shift anti-pattern: a destructive action (Stop) dynamically occupies the position of a non-destructive action (Allow) during rapid user interaction.

Suggested Fixes (any of these would resolve it):

  1. Fixed positions: Keep Stop in a fixed position (e.g., always on the left) regardless of whether Allow is present. Never let Stop occupy the space where Allow was.
  2. Debounce/guard: After the last Allow click, add a brief cooldown (~300ms) before Stop becomes clickable in the shifted position.
  3. Separate zones: Place Allow and Stop in non-overlapping, fixed regions — e.g., Stop always on the far left, Allow always on the far right.
  4. Batch approve: Add an “Allow All” option so users don’t need to click rapidly at all.

Related: This is related to (but distinct from) the hit-area issue in Allow button on subagents misbehaving. That thread focuses on the oversized click target; this report is specifically about the positional swap between Allow and Stop causing accidental termination.

Steps to Reproduce

  1. Start an agent session that spawns background subagents
  2. Configure tool approval to require manual confirmation (not auto-run / yolo mode)
  3. The subagent makes multiple sequential tool calls requiring approval
  4. Click Allow repeatedly to approve each tool call
  5. On the last approval, the Allow button disappears and Stop takes its place
  6. The next click (intended for another Allow) hits Stop and kills the subagent

Expected Behavior

Button positions should remain stable so that rapid sequential clicks on Allow never accidentally hit Stop. The user should be able to approve all pending tool calls without risk of accidentally terminating the agent.

Operating System

MacOS

Version Information

Version: 3.5.33 (Universal)
VSCode Version: 1.105.1
Commit: aac81804b986d739acab348ed96b8bea6e83cc50
Date: 2026-05-22T06:47:48.039Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.5.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @OmryA

I see what you’re saying.

That’s not great. I’ll let the team know!

9

Cross-linking a related approval-UI bug I just filed: the sub-agent approval button shows in three places at once (inline box, status line above the prompt, and the drill-in pop-up) and they go out of sync — approving in one leaves a stale “phantom” Allow button lingering in another for a confusing, prolonged delay, and the pop-up sometimes does not show the command awaiting approval at all: Sub-agent approval buttons shown in 3 places get out of sync.

That phantom Allow directly exacerbates the accidental-Stop problem described here: during rapid Allow-clicking, one surface can still show a stale Allow that has already been resolved. Your next click lands on nothing meaningful — or worse, on the Stop button that has just shifted into that position — so the layout-shift termination becomes even easier to trigger precisely when the buttons are out of sync.