CLI agent in one session forgets everything when switching to new root

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Imagine I create a new cursor cli session and give the agent a secret value like BEAVER_123. If I keep the same session (same session id) but change the current working directory, the agent forgets all prior messages including the secret value.

I would assume one goal of Cursor CLI would be parity with the UI. In the UI you can change root, which is an important thing in scenarios like when an agent creates a new worktree and switches to it etc. In UI you can switch to that new worktree as root and keep full context, but this doesn’t look possible in CLI right now.

Steps to Reproduce

Here is the minimal repro:

rm -rf /tmp/cursor-agent-root-repro
mkdir -p /tmp/cursor-agent-root-repro/config
/tmp/cursor-agent-root-repro/root-a
/tmp/cursor-agent-root-repro/root-b
export CURSOR_CONFIG_DIR=/tmp/cursor-agent-root-repro/config

cursor-agent --print --output-format json --trust
–workspace /tmp/cursor-agent-root-repro/root-a
“Remember this exact token: ROOTSWITCH_SENTINEL_73921. Reply only READY.”

Copy the session_id from the JSON output, then:

SESSION_ID=“”
cursor-agent --print --output-format json --trust
–workspace /tmp/cursor-agent-root-repro/root-a
–resume “$SESSION_ID”
“What exact token did I ask you to remember? Reply only the token.”

Expected/control result:

ROOTSWITCH_SENTINEL_73921

Now resume the same session under a different workspace:

cursor-agent --print --output-format json --trust
–workspace /tmp/cursor-agent-root-repro/root-b
–resume “$SESSION_ID”
“What exact token did I ask you to remember? Reply only the token.”

Observed result: the agent does not know the token / says it lacks that context.

Optional confirmation:

cursor-agent --print --output-format json --trust
–workspace /tmp/cursor-agent-root-repro/root-a
–resume “$SESSION_ID”
“What exact token did I ask you to remember? Reply only the token.”

This returns the token again, which suggests the same session_id is effectively scoped by --workspace.

Expected Behavior

The agent should know the token no matter what, since it is one session. A “session” implies one agent you are talking to, and an agent should remember things.

Operating System

MacOS

Version Information

cursor-agent nightly
version 2026.06.09-15-20-54-7b35efa

For AI issues: which model did you use?

using GPT-5.5 272K Medium

Additional Information

Thank you!

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hi @David_Donahue, Thanks for the detailed write-up and the reproduction steps. That made it easy to confirm what’s happening, and your diagnosis is correct.

Right now the CLI scopes a session’s stored history to the workspace it was started in. When you resume a session id under a different --workspace, the CLI doesn’t find the original history there and effectively starts fresh. Resuming under the original workspace finds the full history again, which matches your confirmation step.

Importantly,

  • Your data isn’t lost. The original conversation (including your token) stays intact and returns as soon as you resume with the original --workspace.
  • The session is currently tied to the workspace path, so it isn’t yet a portable session you can carry across roots from the CLI.

As a workaround, for now: keep --resume paired with the same --workspace the session was created in. Moving into a new root mid-session (for example, a freshly created worktree) while keeping context isn’t supported from the CLI today, since changing the workspace breaks the link to the stored history.