Context from a Composer chat about Sprint 6 embedding work (e.g. OpenAI vs Gemini / live-embedding-bench) appears to surface in a different Composer session that was for unrelated work (Sprint 5 Phase 5: BC Tier-2 / Green Gate). I did not intend to run embedding implementation in the Phase 5 thread.
I compared two local agent transcript files under the same workspace and saw embedding-related tasks mixed into the thread I use for the other initiative. (Transcript ids: 373cd83c-7ae0-4008-8606-2f39cc726568, d405d37f-8c5a-426d-9392-66a5dd6e6583 — path pattern: User/globalStorage/…/agent-transcripts//.jsonl or the workspace copy.)
Steps to Reproduce
Open a Composer chat (Chat A) and work on Sprint 6 / embedding (plans, live-embedding-bench, compare scripts, etc.).
Open a separate Composer tab/chat (Chat B) for unrelated work (e.g. Sprint 5 Phase 5: BC Tier-2, Green Gate).
Continue or trigger “Build / Implement plan” workflow in Chat B.
Observe whether embedding tasks, file edits, or “Phase 5 Embedding benchmark”-style work show up in Chat B, or whether tool traces reference harnesses/docs that belong to Chat A’s thread.
(Adjust step 3 to match what you did: e.g. starting a new plan, continuing an old thread, or switching active tab before clicking Build.)
Expected Behavior
Each Composer session should have isolated conversational context: prior turns from Chat A should not be included in Chat B’s model context unless the user explicitly adds them (@ files, @ past chats, etc.).
Running a plan or Build in Chat B should only use that chat’s own message history (plus what the user @-mentions), not the other tab’s history.
I checked the backend logs for both sessions, and the good news is that the two Composer chats are fully isolated server-side – they have separate conversation IDs, separate histories, and no messages or context from one appear in the other’s prompt.
What’s most likely happening here is that both chats are operating in the same workspace, so they naturally share certain context: the same git status, the same source files, and the same workspace rules. Since your Phase 5 and Sprint 6 work both involve embedding benchmarks and related files, there’s a lot of natural overlap in what both sessions “see” – even though they’re completely separate conversations.
A couple of tips to keep sessions feeling more distinct:
Use separate workspace folders for unrelated work streams when possible – this gives each Composer session a truly different set of files and git state
Name your chats clearly and start new chats for new topics rather than evolving an existing one, which can make it harder to track where a conversation shifted direction
That said, I understand this can feel unsettling when you see similar content across chats. If you notice this happening again with content that clearly couldn’t come from shared workspace files (like a specific instruction you only typed in one chat appearing verbatim in another), please grab the request IDs and let us know – we take context isolation seriously.
Thanks for checking! We agree separate conversation IDs; our concern is whether the worktree, automatic workspace context, or plan/build routing can make two chats produce overlapping edits without any cross-session messages e.g. unstaged but saved files from the other session, or a plan opened in the active tab.
Yes, that’s exactly right – while the conversation histories are fully separate, both chats share the same workspace context. So if Chat A saves a file (even unstaged), Chat B’s agent can discover and reference it through normal workspace operations like reading files, searching the codebase, or checking git status. The same goes for a plan file that’s open in your active tab – it may get picked up as automatic context by whichever chat you’re active in.
In short: chats are conversation-isolated, but not workspace-isolated. For truly separate workstreams, the most reliable approach is opening each one in its own Cursor window pointed at a different folder (or different worktree branch). That way each session has its own filesystem, git state, and indexing scope.
I see. That might be a problem when you try to fix some parallel issues simultaniously. They aren’t overlapse in principal but using the same part of the codebase leads to collapse. Keeping that development in different branches would be the rigth solution in pre-AI times. Now I would love to see my IDE is able to handle it
Anyway, love to use Cursor and thanks for helping.
I found the root issue. It does not seem a leaking context - it misplaces related data picking references from other chats. I made a question in a brand new chat and it referred to docs from another active chat. It is a bug
91bf6abf-5d87-4372-a5f3-3a422954c847
I checked the backend data for that request ID, and I can see what happened. When you started the new chat, Cursor automatically included a “recently viewed files” list as part of the prompt context – that list included a .md file because you had recently viewed it (likely in one of your other active chats). The model then saw that the file was relevant to your GBrain/Neither question and proactively read it.
This is the same workspace-level context sharing we discussed earlier – each chat gets a snapshot of your current IDE state, including which files you’ve recently viewed across the workspace. It’s not pulling messages or history from your other chats, but it does make the model aware of files you’ve been working with recently.
I understand this still feels unexpected in a “brand new chat.” Your concern is valid—if you want a completely fresh start, having recently viewed files carried over can work against it. The separate workspace approach remains the most reliable way to fully isolate contexts today
Are there any plans to fix that or its done by design? My humble opnion it is confusing when brand new chat instead of focusing on a task given explicitly - focus on another problem from another chat. I mean it is fine when other chat problem is considered slightly but here it replaces the topic.
I was executing cross validation things in one chat and another was about planning a webpage update is fully about cross-validation instead. I believe this happen more often if same model do planning in multiple chat simultaniously.
Kind of making Cursor one task per time tool.
PS. Still using 3.1 coz grep is hanging on 3.2. Please do something
I really really see now why my progress is nearly zero since you launched 3.2. Apparently my chats were so cross-contaminated that I could not get anything what was planned. Reminds me Cursor baby steps in 0.37 when the app was nearly unusable due to shipping lots at low quality. I would not even explain how much it costs to your users.
To answer directly: the way Cursor currently shares workspace state (recently viewed files, git status, open tabs) across all chats in the same window is by design, not a bug. But I hear you that it becomes a real problem when running multiple workstreams in parallel. I don’t have a specific timeline for per-chat context isolation, but your feedback here is noted.
For now, the most reliable workaround remains opening separate Cursor windows for each workstream. I know that’s not ideal, but it fully isolates the file context each chat sees.
On the grep issue in 3.2: this is a known problem our team is actively investigating. Could you share a request ID from a session where grep hangs in a new thread so we can focus on this separately? That would help our engineering team narrow it down.
