Stale `selectedComposerId` causes terminal-launch error after the workspace folder is deleted

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Summary

If a chat / agent is the last-selected one when its workspace folder is later deleted on disk (e.g., a git worktree is pruned, a project folder is moved or removed), Cursor repeatedly fails to launch the terminal for that chat — and the error then surfaces even when clicking unrelated, healthy chats, because the orphaned chat is still being re-opened in the background. Restarting Cursor doesn’t help until you explicitly select a different chat.
The error message:

The terminal process failed to launch: Starting directory (cwd) “/path/to/stale” does not exist.

What seems to be happening

After poking around the persisted state in ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb, the relevant pieces are:

  • composer.composerHeaders — the list of all chats, each with a workspaceIdentifier.uri.fsPath and an isArchived flag.
  • selectedComposerId — the last-selected chat, persisted across restarts.
  • composer.startupContribution — registered as a startup contribution; on launch it reads selectedComposerId and re-opens that chat, which initializes its terminal panel against the chat’s stored cwd.
    The startup-reopen path filters out chats with isWorktree === true (Cursor’s own worktree-composer flag) but does not check whether the chat’s workspaceIdentifier.uri.fsPath still exists on disk. So ordinary local chats whose folder has been deleted are still passed to openComposer, which then tries to spawn a terminal at the missing path.
    The same thing happens on the click handler: clicking any chat updates selectedComposerId to point at the orphaned one, so subsequent re-renders re-trigger the error.

Suggested fix

Before re-opening selectedComposerId on startup (and on click), check that the chat’s workspace folder still exists. If not, fall back to the next valid chat or clear the selection so the user can choose explicitly.
This would also make orphan chats behave gracefully instead of silently poisoning the panel.

Workaround

  1. Click any chat whose workspace still exists, so it becomes the selected one.
  2. Restart Cursor.
  3. (Optional) Archive the orphaned chats — archived chats are not auto-restored on startup.

Related

Steps to Reproduce

  1. Open Cursor in a folder, e.g. /Users/<user>/projects/foo.
  2. Create a new chat / agent in that workspace and send it a message so it becomes the last-selected one.
  3. Quit Cursor.
  4. Delete the folder on disk: rm -rf /Users/<user>/projects/foo.
  5. Open Cursor again in any other workspace.
  6. Click any chat in the sidebar.
    Expected: clicking a healthy chat opens it normally.
    Actual: an error toast appears: The terminal process failed to launch: Starting directory (cwd) "/Users/<user>/projects/foo" does not exist. It keeps firing on every panel re-render and on every Cursor restart, regardless of which chat you click, until a different chat is explicitly selected.

Expected Behavior

No error message pops up

Operating System

MacOS

Version Information

Version: 3.2.11
VSCode Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
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.4.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hi Matthew,

This is a known bug. When a workspace folder is deleted, the persisted selectedComposerId still references the orphaned chat, and on startup (and on agent switch) Cursor tries to launch a terminal against the missing directory without checking if it still exists. Your analysis of the code path is spot-on.

The engineering team is aware and working on a fix. In the meantime, the workaround you found is the right one – select a healthy chat, restart, and optionally archive the orphaned chats.

You may also find this related thread helpful: Persistent “The terminal process failed to launch” error (same root cause from the worktree angle).