"Open Editor Window" on an agent focuses an unrelated workspace instead of opening one for that agent

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

  • Cursor IDE (Agents and Editor windows)

  • Cursor CLI

  • Background Agent (GitHub, Slack, Web, Linear)

  • BugBot

  • Somewhere else…

Describe the Bug

Clicking the Open Editor Window button on an agent in the Agents Window focuses an already-open editor window that has nothing to do with that agent’s workspace or worktree, instead of opening a new editor window scoped to the agent.

Steps to Reproduce

Setup when it reproduces

  • Number of agents open: 3

  • Repos / worktrees:

    • Agent 1 → single repo

    • Agent 2 → multi-root workspace with 5 repos

    • Agent 3 → single repo

  • Plus one pre-existing editor windows opened on the repo of agent 3.

Reproduction

  1. Open Cursor with at least one existing editor window for some unrelated workspace.

  2. From the Agents Window, have multiple active agents on different repos / worktrees (as above).

  3. On any agent’s panel, click Open Editor Window.

Expected Behavior

  • A dedicated editor window opens (or is focused) for that agent’s workspace / worktree.

  • N agents across different repos/worktrees → N editor windows side by side, each on the correct workspace.

Actual Behavior

  • No new window is opened.

  • Cursor focuses whichever existing editor window VS Code’s window manager has already opened — often completely unrelated to the agent I clicked from.

  • The focused window is still pointed at its own workspace, not the agent’s. So I end up looking at the wrong repo’s code after clicking the editor button on a totally different agent.

  • Effect: it’s impossible to have multiple agents in different repos each with their own editor window — clicking the button on agent #2, #3, … just re-focuses the same stale window.

Operating System

  • Windows 10/11

  • MacOS

  • Linux

Version Information

Cursor: 3.4.20

VSCode base: 1.105.1

Commit: 0cf8b06883f54e26bb4f0fb8647c9500ccb43310 (2026-05-15)

Layout: glass · Build: Stable · Release: Default

Electron 39.8.1 · Chromium 142.0.7444.265 · Node 22.22.1 · V8 14.2.231.22-electron.0

OS: macOS 25.4.0 (Darwin arm64)

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable

  • Sometimes - I can sometimes use Cursor

  • No - Cursor works, but with this issue

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

7

This is a confirmed bug. The “Open Editor Window” button doesn’t pass the active agent’s workspace through the command chain, so it grabs whichever existing editor window happens to be first in the list, regardless of which agent you clicked from. Your multi-agent, multi-repo setup is the worst case for this since every click targets the same stale window.

Our team is aware and tracking it. Unfortunately, there’s no workaround that preserves the parallel multi-agent workflow right now. The only option is manually opening the correct folder via File > Open Folder after the wrong window gets focused.