Critical: Cursor IDE imperatively changes agent workspace if in 'Ask' mode without notifying

[Rf_Tsu]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When agent is put in ‘Ask’ mode Cursor IDE imperatively changes agent workspace to /home/user/.cursor/ without notifying.
proved by looking into code and ia agent confirms it (see attachment)

WHY ‘CRITICAL’: once the agent is in another workspace (has been instructed by cursor to work there) does not switch back to the ‘correct’ workspace when re-put in Agent mode: Cursor seems not to give further instructions: hence the agent writes from that moment onward in /home/user/.cursor/ instead in the opened (in the ide) workspace that has been used for hours.

Steps to Reproduce

Open a workspace, ask agent to draft a plan then make it execute it in agent mode. this goes fine and the paths in the plan being relative cause no issues.
Then switch to Ask mode and ask info about possible fixes: switch to agent mode and confirm the suggestions made in Ask mode should be now implemented by the agent (in the prompts/discussions no absolute paths specified neither by me nor by agent but only referred to known current tree relative path as usual)

Expected Behavior

classes modified in current project.

Screenshots / Screen Recordings

Operating System

Linux

Version Information

Version: 2.4.21
VSCode Version: 1.105.1
Commit: dc8361355d709f306d5159635a677a571b277bc0
Date: 2026-01-22T16:57:59.675Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Linux x64 5.15.0-139-generic

For AI issues: which model did you use?

GPT5.2-codex

Additional Information

have I ever left current workspace or opened others? no
one time issue? no, recurrent

impacts development and code consistency.
cursor changing imperatively workspace for the agent is a major/critical issue.

POSSIBLE CAUSE (inferring, can not reliably prove):
is there a real reason cursor must put agent in a different worktree? no: cursor probably do this to avoid code modifications but this is a contradiction: ‘use read only tools’ does not mean ‘I will now move you to workspace copy without need tonotifying you’: I don’t know why cursor does this: gpt5.2 is smart enough to use read only tools in ask mode.

does perhaps cursor do this for less smart agents? it’s wrong anyway, defies modes. if an agent is not smart enough to stay in ask mode it’s the dev responsibility to chose a smarter one, there are of them plenty available.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[Rf_Tsu]

updating based on new findings: it is not the “Ask” mode the smoking gun here. see attachment: I can not really understand why the gpt5.2-codex agent says it is still instructed by Cursor to work in another workspace than the one I’ve opened. I’m not completely sure what made it drift there: the plan was executed correctly and I didn’t even close and reopened Cursor ide. it will be interesting to understand why the agent cites a “canonical workspace” (the correct one!) but insists in working in another. apparently I’ve got no way to instruct agent to go back working with the “canonical” workspace

[Colin]

Hey there.

@Rf_Tsu

is there a real reason cursor must put agent in a different worktree?

If this is set to Worktree (and this is mandatory for using multiple models, also called “best-of-n”), Cursor will use different worktrees for each model.

If you do a best-of-n and want to continue work back on your main branch, you’ll need to start a new chat.

If you built a plan in the worktree, you might want to save the plan to your workspace and then ask the Agent to build based on that file!

[Rf_Tsu]

thanks Colin,

yes I confirm this is the core issue so knowing that I can easily solve.

I confirm I see 2 agents opened in chat, not my choice, probably cursor did it automatically for some reason or I did inadvertently (doubt this). I’ll keep this monitored.

thanks and have a great day