An agent finishing shouldn't silently change active window

Ideas Feedback
,
1

This has happened multiple times now.

  • I set an agent to do something (usually building a plan)
  • I start typing in the dialogue box of another agent
  • The first agent finishes
  • And that forcefully transforms the window into that finished agent, while I’m mid-typing
    Most of the time this is annoying, but worst case scenario that could mean me sending a partial command to a wrong agent
4

Hey, thanks for the report. This is a known bug, it’s focus stealing when one of the parallel agents finishes. We’ve already fixed some cases bit by bit (plans, terminal, worktrees), but the specific case where one agent finishes and steals focus from another agent’s input is still happening. I can’t share an ETA for the fix.

If you run into other focus-related cases (for example, focus jumps during streaming), please post them in this thread or file a separate report. It helps us separate the different cases.

6

Still seeing this in the Agents Window (Glass). Looked through local logs + the workbench bundle to narrow it down.

Logs (renderer.log): finish is only logged as wakelock release — there’s no explicit “select agent / steal focus” log after that, so the UI switch isn’t instrumented. Around the same time we also see Glass tab / Diff tab activity.

Sanitized morning timeline (Agents Window, empty-window workspace; UUIDs truncated):

06:18:42 [warning] [GlassTabPersistenceService] migration_tab_transition.promote_noop
  {"sourceAgentId":"b0509159-…","targetAgentId":"553446ee-…",
   "sourceWorkspaceId":"empty-window",
   "reason":"no_tabs_or_active_fallback_to_promote"}
06:18:42 [info] [ComposerWakelockManager] Acquired wakelock reason="agent-loop" composerId=553446ee-…
06:18:54 [info] [buildRequestedModel] composerId=3883bfb4-…  (subagent)
06:19:26 [warning] [GlassTabPersistenceService] migration_tab_transition.promote_noop
  {"sourceAgentId":"12385a9d-…","targetAgentId":"6e96ad7b-…",
   "reason":"no_tabs_or_active_fallback_to_promote"}
06:19:26 [info] [ComposerWakelockManager] Acquired wakelock reason="agent-loop" composerId=6e96ad7b-…
06:19:31 [info] [ComposerWakelockManager] Released wakelock reason="generation-ended" composerId=6e96ad7b-…
06:19:51 [error] [DiffTabContent] snapshot error (kind=gitProviderUnavailable, scope=unstaged,
  agentSource=local, repo=<no repo>): Git provider is not available
06:20:13 [info] [ComposerWakelockManager] Released wakelock reason="generation-ended" composerId=553446ee-…

Code path on finish (AgentResponseAdapter / ComposerChatService):

  1. status → "completed"
  2. maybeSurfaceCanvas()
  3. chat-stream-finished capabilities (notifications / chime)
  4. If finishing agent ≠ active agent → hasUnreadMessages = true (badge only — intentional non-focus)
  5. onComposerSettled → composer-done

System notifications only fire when !hostService.hasFocus, and composer.openComposerFromNotification only runs on click. There is still no cursor.agent.focusOnComplete setting.

So the remaining steal looks like a side effect of finish (canvas/Diff/plan surfacing, or setLastFocusedComposerId / selectedComposerIds reordering when views update) rather than an intentional “focus on complete” feature — same case Dean called out here: agent finishes and steals focus from another agent’s input.

Happy to attach a tighter repro + more log snippets if useful.

7

Hey, thanks for the detailed write-up. The timeline from renderer.log is especially helpful.

Yep, this is the same known case I mentioned above. The agent exits and steals focus from another agent’s input. We fixed a few related variants separately (plans, terminal, worktrees), but this one in the Agents Window and Glass is still open. I can’t share an ETA for a fix yet.

I’d be happy to take you up on the offer for a tighter repro and extra logs. The more compact and repeatable the steps are, the better. Also, please add two things:

  • the exact Cursor version from Help > About
  • your OS and OS version

I’ll attach this to the tracked issue as a fresh confirmation on the latest version. If you notice other focus-related cases, like focus jumping during streaming or when the browser or changes tab opens on finish, please start a separate thread for those so we can track each variant more easily.

8

Thanks — happy to tighten this up.

Environment

  • Cursor: 3.13.25 (Help → About; commit 31e8d61c448c7472e371505838a0fe34083dad50, build date 2026-07-28)
  • OS: macOS 26.5.2 (Build 25F84)
  • Surface: Agents Window (Glass) — empty-window / no-repo workspace

That’s the same build I was on when I posted the timeline above (Jul 28). Still seeing the focus steal there.

Minimal repro

  1. Open Agents Window (Glass).
  2. Start Agent A on a short-but-not-instant task (enough time to switch away while it’s still running).
  3. While A is running, open/switch to Agent B and put the caret in B’s input — start typing.
  4. Let A finish (ComposerWakelockManager → generation-ended for A).
  5. Expected: stay in B’s input; A gets unread/badge only.
    Actual: active agent / focus jumps to A mid-typing (can send a partial prompt to the wrong agent).

Optional amplifier: have A (or a subagent) produce UI on finish (Diff / Changes / canvas). In my log, DiffTabContent activity showed up between the two generation-ended lines — I don’t think Diff is required, but it may make the steal more obvious.

Log anchors (same session as my earlier post; UUIDs truncated; sanitized renderer.log excerpts attached)

  • Agent create → GlassTabPersistenceService migration_tab_transition.promote_noop
  • Run → ComposerWakelockManager acquire agent-loop
  • Finish → release generation-ended
  • No follow-up selectAgent / “steal focus” log — the switch isn’t instrumented

Separately: I haven’t filed streaming / browser-tab / Changes-tab focus jumps as their own threads yet — will do that if I hit a clean variant.
cursor-focus-steal-logs.zip (3.3 KB)

9

Thanks, this is exactly what we needed. I’ve got the repro, version, OS, and logs, and cursor-focus-steal-logs.zip is also there.

I’ll attach this as a fresh confirmation on the latest version (3.13.25 / macOS 26.5.2, Agents Window Glass). Your note that the UI switch itself isn’t logged is helpful. We only see generation-ended from the wakelock, with no explicit selectAgent. That helps narrow down where the focus steal is coming from. It’s the same known issue I mentioned above: a finishing agent steals focus from the input field of another agent. I can’t give an ETA yet.

For the other cases (focus jump during streaming, opening the browser or the Changes tab on finish), yep, please file them as separate threads like we agreed. It’s easier to track each case on its own. I’ll post here if there’s an update on this one.