Agent “ghost shell” terminals block further commands

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When the Agent runs shell commands via the built-in Shell tool, Terminal tabs often remain listed as “∞ Cursor (command…)” even after the command finishes, times out, is aborted in chat, or has no live OS process (ps shows nothing to kill).
Symptoms:

  • Agent shell commands hang or return empty output
  • Commands may be moved to background or show “terminated_by_user” / “aborted”
  • Terminal panel keeps stale “∞ Cursor (command…)” rows (ghost shells)
  • Aborting in chat does NOT remove those terminal tabs
  • After several ghost tabs accumulate, new Agent shell spawns often fail or hang until the user manually trash-cans the ghost rows
  • The SAME commands work normally in a user-opened terminal in the same workspace (same cwd, same env)
    Environment:
  • OS: Linux on WSL2 (linux 5.15.167.4-microsoft-standard-WSL2)
  • Shell: bash
  • Workspace: WSL path (/home/droot/projects/myproject)
  • Context: Agent mode, built-in Shell tool (block_until_ms, background on timeout)
    Example commands that triggered this:
  • php artisan test --filter AiAssistant
  • php artisan tinker --execute=“…”
  • git status / git fetch
  • even short commands like: sed -n ‘97p’ file | xxd | head
    Impact: Agent cannot reliably run tests, git, or diagnostics; user must run commands manually in a normal terminal tab.

Steps to Reproduce

  1. Open a workspace on WSL2 (Remote/WSL: \wsl.localhost... or “Open in WSL”).
  2. Start an Agent chat and ask it to run shell commands (e.g. php artisan test, git status, or a short sed/xxd command).
  3. Repeat several times, or let some runs hit timeout / background / abort in chat.
  4. Observe Terminal panel: multiple rows labeled “∞ Cursor (command…)” remain as if still running.
  5. Check host: ps may show no matching process for those tabs.
  6. Ask Agent to run another shell command → often hangs, returns empty output, or fails to spawn until ghost “∞ Cursor” tabs are manually deleted (trash can).
  7. Control: run the same command in a user-created terminal tab → completes normally.

Expected Behavior

  1. Agent runs a command (git, php artisan test, etc.).
  2. When the process exits—or the user aborts the Agent action—the Terminal tab closes or clearly shows “completed”.
  3. Aborting in chat should tear down the associated Agent terminal session/tab.
  4. The next Agent shell spawn should start cleanly and return stdout/stderr.
  5. Stale terminal rows should not block subsequent Agent shell spawns when no OS process is running.

Operating System

Linux

Version Information

WSL2 on Windows 11

Version: 3.16.29 (user setup)
VS Code Extension API: 1.128.0
Commit: 6246455961129c32969845e00aa25d87ae926ec0
Date: 2026-08-18T01:26:26.285Z
Layout: Agent Window
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.291
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Agent / Auto (Cursor Agent with built-in Shell tool). Issue is with Agent terminal lifecycle, not model output quality.

For AI issues: add Request ID with privacy disabled

[Leave blank unless you have one from a failed Agent run: Chat → … → Copy Request ID]

Additional Information

Possible contributing factor on WSL: non-interactive bash startup (~/.ssh/ensure-ssh-agent.sh via BASH_ENV / .bashrc) can hang if ssh-add -l blocks on a bad agent socket — every Agent command then hangs with empty output. Even after fixing that, the main bug remains: ghost “∞ Cursor (command…)” tabs persist after abort/timeout with no process to kill, blocking the next Agent shell spawn.

Workaround: run commands in a normal user terminal tab; manually trash-can ghost “∞ Cursor” rows; avoid chaining many Agent shell calls when ghost tabs are present.

Request: properly tear down Agent terminal sessions on exit/abort/background; don’t leave ghost tabs; don’t let stale UI state block new Agent shell spawns.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

Hi @civizen.world Thanks for the post. It looks like two behaviors are overlapping. Agent commands use non-interactive Bash, so BASH_ENV can run even when the same command works in a normal terminal. A blocking ssh-add there can stall the Agent before the requested command starts. The ∞ Cursor (...) rows are background shell tasks. If a row says Done, it is retained terminal history. If it remains Running with no corresponding process, that is the state we need to isolate.

Please try:

  1. Temporarily disable or make the BASH_ENV / ssh-add startup hook non-blocking.
  2. Run Developer: Reload Window afterward. Starting a new chat alone may not reset the WSL execution environment.
  3. If it recurs, share a screenshot showing the rows and their Running or Done status.
  4. Share a fresh Request ID from the affected 3.16.29 run. If comfortable, temporarily enable Share Data before reproducing once. Instructions are in the Request ID guide.

For now, deleting a stale running row or reloading the WSL window should unblock the Agent.