Orphaned agent-exec gh shell storm maxes CPU after Plan Mode (multi-root)

[t-ricci-aux (Tommaso Ricci)]

Bug: Orphaned agent-exec shell storm maxes CPU after Plan Mode finishes (multi-root + custom SSH GitHub host)

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Summary

After a Plan Mode agent finished and left a plan awaiting confirmation, Cursor’s extension-host (agent-exec) for a multi-root workspace continued spawning dozens of parallel sandboxed zsh shells running invalid gh pr list --hostname … / gh --version commands across every workspace git root. This saturated a 16-core M4 Max (load averages 25–32, ~0% idle) for 15+ minutes with no visibly running agent in the UI.

Killing the agent-exec process does not stop it: Cursor immediately respawns a new agent-exec host and the same gh storm resumes.

Environment

• Cursor: 3.13.21 (stable), commit 55434bd8062ece6fee083b82beed2aee42d253f0
• OS: macOS 26.5.2 (Build 25F84), Darwin 25.5.0 arm64
• CPU: Apple M4 Max (16 cores)
• Shell: zsh (Oh My Zsh / Powerlevel10k in user environment; agent shells use Cursor sandbox wrapper with dump_zsh_state)
• gh: 2.96.0
• Workspace: multi-root .code-workspace with 20+ folders, nearly all on branch switch-to-vite
• Git remotes: SSH host alias form [email protected]:amigo-framework/<repo>.git (not github.com)
• Related plan: Plan Mode completed at ~14:24 local; plan file react-19-upgrade_*.plan.md; agent transcript id 026f2542-cf70-4d82-a996-d568d915b7f2 showed turn_ended / success and was not growing while the storm continued
• Extensions present (may be unrelated): GitHub Pull Requests 0.156.0, GitLens 18.3.0, GitHub Actions 0.32.3

Expected Behavior

Once Plan Mode finishes and is waiting for user confirmation to build:

• No further agent shell tool executions
• CPU returns to normal baseline for an idle multi-root window

Actual

• Cursor Helper (Plugin): extension-host (agent-exec) application-amigo-6 continuously spawned ~15–25 child zsh processes
• Each child used Cursor’s sandbox wrapper (snap=$(command cat <&3); …; dump_zsh_state) and ran either:
  • gh pr list --hostname "github.com-avatarux" --repo "amigo-framework/<repo>" --head "switch-to-vite" --state all --json url
  • gh --version
• Observed for 15+ minutes after the plan chat appeared idle
• Load average peaked around 32 on 16 cores; Activity Monitor / ps showed many /bin/zsh at 50–80% CPU each (startup/dump_zsh_state overhead dominates)
• Some shells hung >8 minutes stuck on cat reading sandbox fd 3 (snap=$(command cat <&3))
• gh pr list --hostname … is an invalid invocation (unknown flag: --hostname); hostname belongs on gh globally / GH_HOST, not as a pr list flag — so these calls fail immediately and appear to be retried in a loop
• Killing agent-exec PID caused immediate respawn ([1-4] → [1-9]) and storm continued

Additional signals from local state

workbench.backgroundComposer.workspacePersistentData contained:

{
  "cachedSelectedRemote": {
    "name": "origin",
    "url": "github.com-avatarux/amigo-framework/application"
  },
  "cachedSelectedGitState": {
    "ref": "main",
    "continueRef": "switch-to-vite",
    "autoBranch": true
  }
}

Note continueRef: switch-to-vite matches the --head filter being spammed, and the remote URL embeds the SSH host alias that is incorrectly passed as --hostname.

Impact

• Machine unusable / fans high / load 2× core count
• Happens while user believes agent work is finished (plan awaiting confirm)
• Process-level kill is ineffective due to respawn + persisted work queue
• Workaround that should work: Developer: Reload Window or close the multi-root workspace window (not verified in this report if reload clears the queue; process kill alone does not)

Request

Please investigate:

1. Why agent-exec keeps scheduling shell tools after Plan Mode turn end / with no visible running agent
2. Why invalid gh pr list --hostname <ssh-host-alias> is generated from remotes like [email protected]:org/repo.git
3. Why failures appear to retry indefinitely across all multi-root folders
4. Why killing agent-exec respawns and resumes the same storm (persisted pending tool queue?)

Diagnostics captured

Local dump: /tmp/cursor-cpu-storm-bug-20260728-144137/diagnostics.txt (also summarized above). Happy to attach Request ID if needed (Plan Mode chat: transcript 026f2542-cf70-4d82-a996-d568d915b7f2).
https://pastebin.com/9yg3Pk9q

Steps to Reproduce

(approximate)

1. Open a multi-root workspace with ~20 git folders
2. Use SSH remotes with a custom host alias (e.g. github.com-avatarux in ~/.ssh/config)
3. Check out the same feature branch (e.g. switch-to-vite) on most roots
4. Run a Plan Mode agent that surveys the multi-root workspace / git state (React upgrade plan in our case)
5. When the plan is presented and awaiting confirmation, do not click build
6. Observe system CPU: agent-exec continues firing parallel gh pr list --hostname <ssh-alias> --head <branch> across repos even though UI shows no running agent

Operating System

MacOS

Version Information

Cursor IDE: 3.13.21 (stable), commit 55434bd8062ece6fee083b82beed2aee42d253f0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[Colin]

Hi @t-ricci-aux!

Thanks for the report. This looks a lot like this issue reported yesterday:

IDE agent PR lookup spams desktop with popups

Hey @bradley_b The retry storm. When your current branch has no pull request, Cursor’s background branch→PR lookup keeps re-checking about once a second instead of settling on “no PR” and backing off. Each retry falls back to the local GitHub CLI (gh pr list), which is what you’re seeing spawn over and over. The visible console windows. On Windows those background lookups aren’t launched hidden, so each one flashes a pwsh/conhost window. That’s a known Windows issue we’re already tracking, and…

We can reproduce it, which is a good signal! The team is aware and looking into it.

[fbndsprz]

Hey,

same issue here on ubuntu (multi-root / multi git workspace, gh, custom github alias via ssh/config

workaround (based on forum suggestion)

~/.local/bin/gh

#!/usr/bin/env bash
# Short-circuit Cursor's background branch→PR lookup storm.
# Real CLI: /usr/local/bin/gh
set -euo pipefail

REAL_GH="/usr/local/bin/gh"

is_cursor_agent() {
  [[ -n "${CURSOR_AGENT:-}" || -n "${CURSOR_SANDBOX:-}" || -n "${COMPOSER_NO_INTERACTION:-}" ]]
}

if is_cursor_agent; then
  if [[ "${1:-}" == "pr" && "${2:-}" == "list" ]]; then
    # Cursor retries on invalid --hostname / empty PR; return empty JSON fast.
    if [[ " $* " == *" --json "* ]]; then
      printf '%s\n' '[]'
    fi
    exit 0
  fi
fi

exec "$REAL_GH" "$@"

[t-ricci-aux (Tommaso Ricci)]

unfortunately that bash script trick didn’t mitigate the problem for me on macOS

I also tried with instructions in AGENTS.md and .cursor/rules and .cursor/hooks.json to explain and block how gh hostname should be github.com instead of github.com-avatarux and similar aliases but it doesn’t seem to be picked up by cursor and agents correctly the CPU still gets capped at 100% by a swarm of zsh shells

This is really making it harder for me to work properly and it’s a high priority blocker for me

[Novic]

Can confirm the same behavior on Win 10 + powershell 7.
Behavior is the same even tho github client is not installed nor used, neither github integration is used.
Cursor version:

Summary

Version: 3.13.25 (user setup)
VS Code Extension API: 1.128.0
Commit: 31e8d61c448c7472e371505838a0fe34083dad50
Date: 2026-07-28T06:17:45.069Z
Layout: IDE
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.19045

[nicemarmot]

Same experience here. With as few as two subfolders in a workspace, a storm of unstoppable powershell “gh --version” processes consumes all CPU while Cursor is “idle”. Cursor is effectively unusable in this environment.

[t-ricci-aux (Tommaso Ricci)]

Still reproducible with the updated version of Cursor 3.14.7

[t-ricci-aux (Tommaso Ricci)]

Unfortunately, still reproducible in Cursor version 3.14.27.

Also, FYI, prompting anything to AI in anymode triggers this, not just plan mode, it reproduces in agent mode too

[t-ricci-aux (Tommaso Ricci)]

Checked this issue still happens in Cursor 3.15.6

[t-ricci-aux (Tommaso Ricci)]

Not sure what changed, but for the entire day I haven’t encountered this issue anymore while using Cursor normally, but I’m not 100% sure it’s gone. I’m still on Cursor 3.15.6