This is a recent behavior change rather than the tab actually being closed. Browser tabs are currently scoped to the specific agent/chat that opened them, so starting a new agent conversation shows an empty browser strip. The tab isn’t lost though, it still belongs to the original chat, and switching back to that chat brings it right back.
We’ve had this reported a few times and it’s something we’re tracking. In the meantime, for a page you want available across every chat (like a preview or your app), keeping it in a separate external browser window is the most reliable option today.
thank @mohitjain you for your feedback. I have added a comment on the thread.
"I don’t see the rationale behind this feature though : 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 …"
Noting a nearby but distinct bug we hit on 3.13.21: instead of tabs being scoped to a chat, an agent in a different project workspace could attach to Browser Tabs owned by Home/empty-window (viewId contained the other workspace id).
Follow-up with sanitized logs / session IDs for the Home↔project browser tab bleed (viewId stable-browser-session/b23abea01bc4771017b008369920af3f from a non-Home chat), plus wrong-path MCP staging ENOENT.
Totally fair point, and it’s feedback we’ve heard from others. You’re right that if terminals stay across conversations, in-app browser tabs feel like they should behave the same, especially when you’re using them as persistent scaffolding (app front, GitHub, previews) rather than throwaway context for a single chat. This is an issue we’re tracking.
In the meantime, keeping the app front in an external browser window is the most reliable way to have it available across chats. For the “save tabs configuration” ask, the closest open discussion is Pinning a Browser Window in Agent Window - worth adding your specific use case there so the pinning feedback stays in one place.
@jsolly - thanks for the cross-link and the sanitized logs. That looks like a distinct scoping issue on our side, I’ll follow up on your primary thread.
Found this while googling for this bug. Well, you guys describe it as intentional but it definitely feels like a bug to me. I use design mode pretty extensively, and the cursor browser is great for that. But lately I’ve been working with grok-4.5 and with its smaller context window I find it filling up faster, and then I go to start a new agent to continue on my session and get frustrated that the browser tab closes. The terminal doesn’t close - that stays alive so my app is still running on localhost. But now on new agents I have to go and open the browser tab again and navigate back to the page I was working on. Pretty frustrating.
Hey @William_Stith you’re not wrong that this feels off. It’s not intended behavior, and it’s an issue we’re tracking. One thing that helps in the meantime: the tab isn’t actually destroyed. It stays with the original chat, so switching back to that conversation brings it (and your page) right back.