Agent opens links via open_resource (Chrome Beta) then asks for forum login without specifying Cursor agent browser vs Chrome Beta

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When an Agent needs the user to authenticate (e.g. Cursor Forum to file a bug), it mixes two browser surfaces with separate cookie jars and does not tell the user which one to use.

Concrete failure in this session:

  1. Agent called cursor-app-control open_resource for cursor.com/dashboard and later forum.cursor.com — that opened in the user’s attached Chrome Beta (authenticated).
  2. Agent separately used cursor-ide-browser MCP, which has its own Browser Tab session (logged out).
  3. Agent said “log into the forum” / “you’re logged in from the prior bug” without stating that login must be in the Cursor agent Browser Tab, not Chrome Beta.
  4. User completed login in Chrome Beta (where the prior link was opened). Agent kept reporting logged-out and blocking bug filing.
  5. User had to correct the Agent that the instruction omitted which browser.

This is a product/agent UX defect: multi-browser tooling without explicit surface naming causes false “not logged in” blockers and wasted user time.

Steps to Reproduce

  1. Attach Chrome Beta for browser tooling (or have open_resource open URLs in Chrome Beta).
  2. Ask Agent to file a Cursor Forum bug that requires being logged in.
  3. Observe Agent open_resource a forum/dashboard URL into Chrome Beta.
  4. Separately observe Agent use cursor-ide-browser (Browser Tab) which is a different cookie jar.
  5. Agent asks user to “log in” without naming Chrome Beta vs Cursor Browser Tab.
  6. User logs into Chrome Beta (where the opened link is).
  7. Agent still reports logged out and cannot Create Topic until it switches to the Chrome Beta stable-browser-session viewId.

Expected Behavior

When Agent needs authenticated user action in a browser:

  1. Prefer the same browser surface that already has the session OR clearly name the required surface (“Cursor Browser Tab” vs “Chrome Beta”).
  2. Never open_resource into Chrome Beta then ask for login that only works in cursor-ide-browser without saying so.
  3. If multiple browser sessions exist, Agent should list tabs/viewIds and pick the authenticated one before claiming “not logged in”.

Operating System

MacOS

Version Information

Version: 3.12.17
Commit: 0fb762053c34788bb7760d5673f8a6d4c8589d50
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

Composer / Agent (Auto router)

Additional Information

Surfaces involved: cursor-app-control open_resource (Chrome Beta / workbench opener) vs cursor-ide-browser MCP (Browser Tab). Chat context also showed login token expired / plan [pro] while dashboard showed Pro+.

Related follow-up bug (filing separately): Agent Pro+ usage-monitoring guidance misaligned with docs + Overview UI.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey there!

The key thing: Cursor’s in-IDE Browser Tab is a separate, isolated browser session with its own cookies and storage (scoped per workspace). It never shares your login with your normal Chrome/Chrome Beta. So when the agent “opens” a link that lands in Chrome, that’s a different session than the one it can actually see and control, which is why it kept reporting “logged out” even after you signed in on Chrome.

Two things to get you unblocked:

  1. In Cursor Settings, open the Browser section and turn on Open Web Links in Browser (“Automatically open http and https links in the Browser Tab”). That keeps agent-opened links inside the tab the agent can automate.
  2. For any agent-driven flow that needs a login (like posting here on the forum), sign in inside Cursor’s Browser Tab itself, not your external browser, since the tab has its own session.

More on how the Browser Tab works: Browser | Cursor Docs

You’re right that the agent should tell you which surface to log into instead of a generic “log in,” and I’ve passed that along with your report. Thanks again for flagging it!