If I open a new chat window in cursor, prior to 3.10.17, any browser/terminal tabs i have open in other chat windows persist.
Now, they are cleared.
This is incredibly annoying as I have a browser tab pointed at the github project, and another at the app. Having to re-open them manually for each chat window is very annoying, so much so that I am finding I am just using the same continous single chat all day instead.
Also, sometimes, just switching chat windows totally blanks out the area where the browser tabs should show. hiding and showing this area makes them re-appear. screenshot
Steps to Reproduce
create a chat in a project
open browser tabs
create a new chat
same browser tabs do not show
for the second issue,
switch tabs a few times til it happens
Expected Behavior
same browser tabs across multiple chats in the same project as was previously the behaviour
Hey Simon!
Browser/terminal tabs not carrying into a new chat: this is a recent behavior change. Browser tabs are currently tied to the specific chat that opened them, so a new chat starts with an empty browser strip. They aren’t deleted though, they still belong to the original chat, so switching back to that chat brings them right back. We know this is a step back from how it worked before, and we’re tracking the request to make them persist across chats in the same project. In the meantime, for a reference you want visible everywhere (like your GitHub page or your app), keeping it in a separate external browser window is the most reliable option right now.
Browser area going blank when switching chats: this is a separate display glitch, and toggling the panel off and on (which you already found) is the current workaround. We’re aware of it and tracking it too. If you can grab a short screen recording of it happening (Cmd+Shift+5 on macOS), that would really help us pin down a reliable repro.
thanks @mohitjain . Just so I’m clear, is there a plan to restore the functionality of browser tabs persisting across multiple chats?
If I may be so bold as to make a suggestion: being able to pin any window - be it, terminal, browser or diff, is a UI thing everyone is already super familiar with. Pin = persists across multiple chats.
For me, on MacOS, changing to literally any chat window leads to the blank tab area. Literally any change at all. I have then been using the shortcut to hide/show the tab area to make it re-appear. But for me it’s not a complex set of repro steps, it really is as easy as clicking on any chat other than the one I’m in now. The video would really be the same as the screenshot in the original post, but just clicking on the selected chat right before taking the screenshot.
Adding to this — same root issue, different angle: I use the Agents window a lot for when I need to do design work (clicking around, iterating), and my context fills up fast enough that I need fresh chats often. When I want to multitask — running several chats in parallel, each making edits at once — every new chat spins up its own browser tab from scratch. I have to re-navigate to the page, re-auth, rebuild whatever state I had, just to get back to where I was.
What I’d really want is for the browser (and terminal) to behave like a shared, persistent resource across chats in the same project — the same way terminal sessions/files already stay put — rather than being owned by a single chat. @Simon_S’s “pin” idea above captures it well: pin a browser/terminal/diff window so it survives across new chats and chat switches, instead of resetting or disappearing.
Given @mohitjain’s note that this is being tracked as a regression, +1 to fixing the persistence — and I’d suggest the pin model as the long-term fix rather than just restoring the old behavior, since it’d also solve the parallel-multitasking case, not just switching back to one chat.
OS: macOS (Darwin arm64 24.6.0)
Version: Cursor 3.11.13, Build: Stable, Electron 40.10.3
Impact: Often — this is a significant workflow blocker when running multiple chats in parallel.
@Jayden10125 - browser and terminal tabs currently stay with the chat that opened them, so every new chat starts fresh. I understand why it’s painful.
On whether the cross-chat persistence comes back: I can’t share a timeline, but it’s a known request we’re tracking, and the “pin any window” framing (cc: @Simon_S) fits right into it. The +1s and concrete workflows on this thread genuinely help us prioritize, so keep them coming.
@Simon_S - thanks for confirming the blank strip shows up on any chat switch. That’s a useful detail for the display side of this.
In the meantime, for a page you want available in every chat, a separate external browser window is the most reliable option today.
Thanks for letting me know the version number. The experience with the latest version is absolutely terrible; I’m going to manually downgrade, and I won’t trust or upgrade to the latest version again!
This basically reduces cursor down from a full IDE to the equivalent of just running claude code in a terminal.
If I don’t have the browser embedded in cursor, which is the suggested workaround, then the Design features of the built-in browser, and the ability to toggle between browser and reviewing code easily, is all gone.
I’ve started running my terminals outside cursor too.
Now cursor is just the agents and nothing else.
The only reason I use cursor is because it has those extra features so for me just speaking personally, this removes my incentive to not explore other options and just go with the cheapest most cost efficient harness. Which I am pretty sure is not cursor!
The core problem: without one shared browser, every new chat opens its
own. I work in parallel — an agent runs while I move to the next task —
so I’m never going back through old chats to close browsers I’ve
finished with. They just accumulate.
And as they accumulate, so does the memory. Each browser sits at
350–400 MB and is never reclaimed. Past twenty chats in a day, that’s
~7 GB in dead browsers and Cursor approaching 10 GB — over 40% of this
machine’s 24 GB. I restart Cursor through the day to clear it, and it
crawls if I don’t.
So this isn’t only a UX annoyance, it’s a performance problem. One
pinned, shared browser per project fixes both.
Agreed this should be fixed. I don’t see the rationale behind this feature : why should the app front browser tab be scoped to a conversation ? the front does not die with the conversation, on the contrary. Plus why should consoles not follow the same logic then ? (please don’t …). Imho consoles and app front, should stay across all conversations.
For context on how I use these tabs : consoles are to build and launch backends et front (at least 3 of them) et at least one browser tab for the app front. I name them so that I can refer to it to the agent for it to read error messages. The first thing I do when coming to a fresh agent window is to set up my working tabs. Hence I once asked to be able to save the tabs configuration; ideally each tab would have its own history but that’s another topic …
Is there any update on this? Going on nearly 3 weeks now where I am just using cursor as an AI chat window only, with zero access to the features that make it better than the competitors
Related but different symptom from chat-scoped browser tabs: on 3.13.21 we also saw cross-workspace attachment — a project-workspace agent’s browser_tabs listed/controlled Home/empty-window Browser Tabs (stable-browser-session/<home-workspace-id>).
Cross-workspace evidence + sanitized logs (related to chat-scoped tabs)
From a project workspace agent we controlled tabs whose viewId embedded Home workspaceId b23abea01bc4771017b008369920af3f. Separately, MCP FS Writer tried to write cursor-ide-browser~staging into a third project path (stocktextalerts-sfeo) — ENOENT.
Full write-up + attachments: 166856. Catalog/runtime twin: 166850.
machineId 45f9fb3f-e7a9-4793-a235-3a7bb93e4e3f, log folder 20260727T152911, data sharing on.
@Jayden10125 - 20+ browsers never getting reclaimed isn’t expected (there’s an internal cap). If you can grab a Process Explorer snapshot next time it’s high (Cmd+Shift+P → “Developer: Open Process Explorer” → open a History tab → Export), that will show us which BrowserViews are actually alive and why they’re not getting evicted.
@rognierbenoit - the current per-chat scoping was about isolating state between chats, but “shared/pinned per project” is what most workflows here need and it’s where we’re aiming.
@Simon_S - no timeline I can share yet. This thread is on the team’s radar and I’ll post here when there’s something concrete.
@mohitjain thanks for the explanation; glad the aim is to provide tabs per project : it captures indeed the way we are using tabs I guess. Some tabs are naturally conversation related though, like plans : hence it would make sense to close them when starting a new conversation (although there is no simple way as far as I know to see the list of past plans)
@rognierbenoit@William_Stith - The frustration is fair. Nothing new to add beyond what’s above yet: the current per-chat scoping is on the team’s radar, and shared/pinned-per-project is the direction we’re aiming for. No timeline I can share, but I’ll post here the moment there’s something concrete.
How do designers at Cursor handle working in Cursor without this being fixed?
Every time I start a new chat and all my right side tabs disappear I question the whole approach and whether I want to keep using Cursor versus harnesses/apps that give me more control.
Thought it was worth you guys knowing this is annoying my team’s designers so badly we are literally working on building a replacement agentic-design surface to Cursor. This is such a basic UX improvement that screams itself out every time you do frontend UI work in Cursor that it really begs the question how are you guys working on Cursor UI internally without going crazy?
You are gonna lose money from design teams because of this.
This long since the bug is filed, the least we deserve is, “no, we’re not going to fix this” or, “yes, we are going to fix this and the fix will land by…”
