IDE agent PR lookup spams desktop with popups

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On Windows, Cursor’s branch→PR resolver falls back to local GitHub CLI (gh pr list) through agent-exec. When the current feature branch has no pull request URL, a force-refresh path retries about every 1 second, spawning visible console windows (pwshconhostgh). This causes constant popup flashes and wasted CPU.

This started after upgrading to Cursor 3.13.10 (installed on this machine 2026-07-23/24). It happens in the main IDE (file tree left, editor center, Agent chat on the right; CURSOR_LAYOUT=unifiedAgent). I do not use the separate Agents Window.

Process Explorer shows:

Cursor.exe
 └─ pwsh.exe -ExecutionPolicy Bypass -NonInteractive -File %TEMP%\ps-script-<uuid>.ps1
     └─ conhost.exe
         └─ gh.exe pr list --repo <owner/repo> --head <feature-branch> --state all --json url

Environment on the flashing pwsh process includes:

  • CURSOR_AGENT=1
  • CURSOR_EXTENSION_HOST_ROLE=agent-exec
  • CURSOR_LAYOUT=unifiedAgent

Temp script Cursor generates contains:

Set-Location '<workspace>'
# Execute user command
gh pr list --repo "<owner>/<repo>" --head "<branch>" --state all --json url

Local product path appears to be branchPullRequestGhCliFallback / branchMetadataService.resolveBranch(..., { forceRefresh: true }) with _scheduleForceRefreshRetry at 1000ms when no PR URL is latched.

Workaround that stops the loop for one branch: open a draft PR so Cursor can latch a URL. Closing that PR while staying on the branch can bring the loop back. This is a band-aid, not a fix.

Not caused by Task Scheduler, Claude Code extension, or user hooks (ruled out).

Steps to Reproduce

  1. Use Windows 11 with Cursor 3.13.10.
  2. Use the main IDE layout (Agent chat on the right). Do not open Agents Window.
  3. Open a GitHub-backed git repo.
  4. Check out a feature branch that has no open PR (local-only branch, or pushed branch with no PR).
  5. Keep Agent chat active and/or run a Compound Engineering plan / normal agent work in that repo.
  6. Watch for brief console window flashes on screen.
  7. In Process Explorer, observe repeating short-lived processes: pwsh running %TEMP%\ps-script-*.ps1, then gh pr list --repo … --head … --state all --json url.
  8. Optional confirm: create a draft PR for that branch → flashes for that branch stop. Stay on a different feature branch with no PR → flashes return.

Expected Behavior

  1. If a branch has no PR, Cursor should resolve once to “no PR” and stop retrying every second.
  2. Background pwsh/gh lookups on Windows should be spawned with CREATE_NO_WINDOW / hidden console so they never flash.
  3. Prefer API/SCM backend for PR metadata instead of shelling out to gh, or provide a setting to disable the CLI fallback (especially on Windows).

Actual behavior: unbounded ~1s force-refresh retries via visible console subprocesses whenever the current feature branch has no PR URL.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Cursor version: 3.13.10
Commit: 4f02290ccd9304f0e6bf8ee85f6e9106f02ac1f0
Date: 2026-07-23
Layout tag observed on failing process: unifiedAgent

For AI issues: which model did you use?

Not model-specific. This reproduces from IDE/agent PR-metadata background activity, not from a particular chat completion model.

For AI issues: add Request ID with privacy disabled

N/A — this is not tied to one chat completion request.

If needed for correlation, the failing activity is continuous agent-exec shell spawns of:

gh pr list --repo <owner/repo> --head <branch> --state all --json url

while Agent chat is open on a feature branch with no PR.

Additional Information

  • Shell used by Cursor for the spawn: PowerShell 7
    C:\Program Files\PowerShell\7\pwsh.exe
  • GitHub CLI installed:
    C:\Program Files\GitHub CLI\gh.exe
  • Reproduced across multiple repos/branches, e.g.:
    • bradleybenner/cursor / feat/cognee-unified-second-brain
    • bradleybenner/para-areas / feat/warm-specialist-portfolio
  • Creating a draft PR for the active branch stops the loop for that branch; measured spawn rate dropped from ~1/sec to 0.
  • No user setting found in 3.13.10 to disable branchPullRequestGhCliFallback / branch metadata force-refresh. Cursor Settings “PR Attribution” only controls attribution labeling, not this lookup loop.
  • Separate/unrelated flashes can also come from Docker Desktop docker stats when the Docker dashboard is open; those stopped when Docker UI was closed. The gh pr list loop is Cursor-specific.
  • Related Windows issue class: agent shell spawns missing CREATE_NO_WINDOW. This report is specifically the PR-metadata gh pr list retry loop in the main IDE.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey @bradley_b

  1. 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.
  2. 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 your report adds the exact command line and the PR-metadata trigger, which is genuinely useful for pinning it down.

Your workaround is the right call for now: opening a PR (even a draft) for the active branch lets Cursor latch a real PR URL, which stops the lookup loop for that branch - and closing it while staying on the branch brings the loop back, exactly as you found. There’s no setting to disable the CLI fallback today, so the draft-PR trick is the best stopgap.

I’m reporting the once-a-second retry behavior to our engineering team as its own issue (the window-visibility side is already tracked), and I’ll follow up here when there’s movement. Thanks again for doing so much of the diagnosis for us.

@mohitjain

I’m seeing the same underlying issue on macOS, but the symptom is repeated 1Password Touch ID prompts rather than Windows console popups.

Environment:

  • Cursor: 3.13.25 stable
  • Commit: 31e8d61c448c7472e371505838a0fe34083dad50
  • Date: 2026-07-28T06:17:45.069Z
  • Layout: Agent Window
  • OS: macOS / Darwin arm64 25.6.0
  • GitHub CLI: gh 2.96.0
  • Shell: zsh
  • 1Password is configured as the gh credential provider via:
    alias gh="op plugin run -- gh"

Observed process shape:

Cursor Helper (Plugin): extension-host Agents Window
└─ /bin/zsh -c ...
   └─ gh pr list --repo <owner>/<repo> --head <branch> --state all --json url

Because Cursor launches this through my shell, my gh alias expands to:

op plugin run -- gh pr list --repo <owner>/<repo> --head <branch> --state all --json url

That means each background branch→PR lookup triggers a 1Password “CLI access requested” Touch ID prompt. I was seeing roughly 12 prompts per minute, making Cursor effectively unusable.

This reproduces across Cursor 3.13, 3.12, and 3.11 for me, so it does not appear to be a 3.13-only regression. I also tried clearing Cursor’s branch metadata / composer header / local agent state caches, but the behavior returned after reopening Cursor, which suggests the lookup is being rescheduled from active repo/branch state rather than only stale persisted metadata.

I also confirmed locally that Cursor’s bundled code has a GitHub CLI fallback path that runs:

gh --version
gh pr list --repo <owner>/<repo> --head <branch> --state all --json url

I could not find a Cursor setting that disables this local gh fallback for background PR metadata lookup.

Impact:

  • Frequent 1Password Touch ID prompts, multiple times per minute
  • Cursor becomes hard to use even when no visible agent task is running
  • Background gh lookups happen for merged/stale branches as well as current branches
  • Users who route gh through credential helpers, SSO, 1Password, or other interactive auth flows get interrupted constantly

Expected behavior:

  1. If no PR exists for a branch, Cursor should cache “no PR” and back off rather than retrying aggressively.
  2. There should be a setting to disable local gh fallback for background PR metadata lookup.
  3. Background PR metadata lookup should avoid invoking shell aliases/functions when possible, or use a non-interactive path.
  4. Background PR metadata lookup should be independently controllable, especially for users with interactive gh authentication flows.

Temporary workaround I used locally:

I replaced my gh alias with a guarded shell function that detects Cursor Agent Window / agent-exec background calls and returns [] only for this exact lookup shape:

gh pr list --repo ... --head ... --state all --json url

All other gh commands still go through 1Password normally. This stopped the 1Password prompt storm, but it is only a local workaround.

Please check if this issue is also related: Orphaned agent-exec gh shell storm maxes CPU after Plan Mode (multi-root)