Workspace terminals lose project directories after restart

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Workspace terminals do not persist their assigned project directories after restarting Cursor. All terminals reset to a single project path instead of retaining their original working directories.

Steps to Reproduce

Create a workspace with multiple projects (e.g., 4 projects)
Open multiple terminals
Navigate each terminal to a different project directory
Rename terminals and assign colors/grouping
Save the workspace
Close Cursor
Reopen Cursor and load the workspace

Expected Behavior

Each terminal should reopen in its previously assigned project directory within the workspace.

Operating System

Windows 10/11

Version Information

Version: 3.2.21 (user setup)
VSCode Version: 1.105.1
Commit: 806df57ed3b6f1ee0175140d38039a38574ec720
Date: 2026-05-03T01:46:14.413Z
Layout: editor
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: Windows_NT x64 10.0.26200

Additional Information

This issue breaks multi-project workflows inside a single workspace and forces repeated manual setup after every restart.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report. This isn’t really a bug, it’s a limitation of how terminal revival works. On restart it restores the initial cwd from shellLaunchConfig, meaning the folder the terminal was launched in, not the folder you later cd’d into manually. Names and grouping survive a restart, but the current directory after manual navigation doesn’t.

Workaround for a multi-root workspace is to set cwd explicitly for terminals, so you don’t rely on manual cd. A few options:

  1. Terminal profiles with an explicit cwd in .code-workspace or User settings:

    "terminal.integrated.profiles.windows": {
  "Project A": { "path": "pwsh.exe", "cwd": "C:\\path\\to\\projectA" },
  "Project B": { "path": "pwsh.exe", "cwd": "C:\\path\\to\\projectB" }
}

    Then start the right profile via Terminal: Create New Terminal (With Profile), and cwd will always be correct.

  2. terminal.integrated.cwd per workspace folder. In .code-workspace, in the settings section, you can set a default cwd for each folder. New terminals will open there.

  3. If you want automation, tasks.json with runOn: folderOpen can start the right set of terminals in the correct folders when the workspace loads.

If none of this fits your workflow, share a bit more about what you expect to see after restart, for example “I want Cursor to remember the last cd”.

9

Thanks, this solved half of my problem. However, I’m still facing another issue with the terminals. Sometimes a terminal gets completely stuck, and I’m unable to do anything with it. Even pressing Ctrl+C has no effect. The only workaround is to close that terminal, create a new one again, and then manually set the name and color label, which becomes very annoying.

This is not the first time I’ve encountered this issue.

Attaching a screenshot for reference.

image
image860Ă—256 13.4 KB

10

Hey, glad the first part is sorted. For the second one, in the screenshot I can see the History restored banner and Vite running, which means the terminal was restored from a persistent session after a restart or reload window. Looks like revive doesn’t fully reconnect stdin to the process, so Ctrl+C and any input go nowhere.

To confirm that, could you help clarify:

  1. Does it only happen to revived terminals after restart or reload, or does it also happen with freshly created terminals?
  2. What’s usually running in the terminal when it gets stuck, a dev server like Vite, Next, Webpack, a watcher, or just a shell?
  3. Does using Cmd+Shift+P then Terminal: Kill Terminal help, instead of manually closing the tab?

In the meantime, you can try a workaround by disabling process revive:

"terminal.integrated.persistentSessionReviveProcess": "never"

After a restart, terminals will be created again from scratch (cwd, name, and color are kept), but running processes won’t be revived and won’t get stuck in a half-attached state. If the terminal stops getting stuck with this setting, it points to the revive logic, and that’s on our side, I’ll report it internally.