[BUG] Chrome extension steals focus and hijacks keyboard input during concurrent Cowork tasks (post-March 24 computer use update)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Environment:
- macOS
- Claude Desktop (latest, post-March 24 2026 update)
- Claude in Chrome extension (latest)
- Cowork mode with computer use disabled
---
Since approximately March 24-25, 2026 (coinciding with the computer use update for Cowork), the Chrome extension aggressively steals cursor focus and keyboard input during Cowork browser tasks, even with computer use turned off.
The core problem: When Cowork uses the Claude in Chrome extension (priority 2 in the tool chain, via tabs_create_mcp / navigate), every browser action forces Chrome to the foreground and captures keyboard focus. This redirects whatever you are actively typing into whichever window Chrome has grabbed, typically an SSH session or other active application.
What makes this untenable:
- Single task + user conflict: Even one Cowork task using the Chrome extension will repeatedly yank focus away from the user's active work. There is a visible "app use glow spike" on Chrome immediately before focus is stolen.
- Multiple task conflict: When two or more Cowork tasks are running concurrently and both need browser access, they fight each other and the user for the single shared cursor/keyboard. Keystrokes intended for the user's own work land in the wrong window.
- This defeats Cowork's core value proposition. The entire point of Cowork is to run tasks in the background while you continue working. Focus stealing makes this impossible for any task involving browser automation.
This is new behaviour
This was not happening prior to the March 24 update. The Chrome extension previously handled browser tasks without aggressively foregrounding Chrome on every navigation or tab creation event.
What Should Happen?
Cowork browser tasks via the Chrome extension should operate in the background without stealing focus. Chrome's native API already supports this: chrome.tabs.create({ active: false }) and chrome.tabs.update({ active: false }) allow tab creation and navigation without foregrounding the browser window.
Suggested Fix: Add an active parameter (default false when called from Cowork) to tabs_create_mcp and navigate MCP tools, as previously requested in #31119. This is a one-line change on the extension side and would resolve the focus-stealing entirely for Cowork background tasks.
Error Messages/Logs
Steps to Reproduce
- Open Claude Desktop, switch to Cowork mode (computer use OFF)
- Start a Cowork task that requires browser research or web interaction via the Chrome extension
- Switch to another application (terminal, IDE, text editor) and begin typing
- Observe: Chrome is foregrounded and keyboard input is redirected to Chrome
Worse case:
- Start a second Cowork task that also requires browser interaction
- Observe: both tasks now compete for Chrome focus, and the user's own typing is continuously intercepted
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Pre-March 24, 2026 update
Claude Code Version
Latest (Claude Desktop with Cowork mode)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
Related Issues
- #31119 - Claude-in-Chrome: background tab creation + tab cleanup (describes the same underlying API gap, filed pre-computer-use launch)
- #28722 - AskUserQuestion steals focus and triggers unintended selection (same focus-stealing pattern in Claude Code VSCode)
- #32726 - VSCode extension: add option to prevent panel from stealing focus
- #31771 - Cowork browser tools connect to Chrome Canary even without extension installed (related: browser MCP tool targeting issues)
Impact
High. This renders concurrent Cowork tasks unusable for anyone who needs to continue working on their machine while Cowork runs. It is particularly disruptive for users working in terminals/SSH sessions, as stolen keystrokes can execute unintended commands.
14 Comments
Important clarification: Computer use is switched OFF in Cowork settings, yet the focus-stealing still occurs. This confirms the issue is in the Chrome extension's MCP tool layer (
tabs_create_mcp/navigate), not in the computer-use (screenshot + desktop control) feature. The extension forcegrounds Chrome on every tab creation or navigation event regardless of whether computer use is enabled.Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This isn't just extreme annoying -- it's dangerous, because if you are typing sensitive text like a password when chrome/claude randomly steal focus, you are now inadvertently typing it into a website.
This is not a duplicate -- please do not auto-close.
Our entire company has been using Cowork as a core part of our daily workflow. Since the March 24-25 update, it has become completely unusable.
What was genuinely transformative -- people running tasks in parallel, staying productive while Claude handled work in the background -- has turned into something we can no longer use at all. Every time Cowork triggers a browser action, Chrome gets yanked to the foreground and steals keyboard focus from whatever we are working on. That means keystrokes meant for our terminals, editors, or other apps land in Chrome instead. The laptop becomes unusable while a task is running.
The suggested duplicates do NOT cover this. The referenced issues (#31119, #39600, #39696) are about related but distinct prior reports. This issue specifically tracks the post-March 24 regression where the behaviour changed from working correctly to broken. Before the update, Cowork browser tasks ran in the background without stealing focus. Now they cannot. That is a regression, not a pre-existing duplicate.
This needs urgent attention. Cowork's entire value proposition is that you can keep working while it handles tasks in parallel. A focus-stealing regression breaks that completely. Please keep this open and prioritise a fix.
macOS workaround that worked for me:
Restart Chrome after running this. Chrome will no longer steal focus when Claude Code interacts with it via the extension.
To revert:
Tested on macOS 15.4 (Sequoia) with Chrome 135. Not a proper fix but a usable workaround until the extension handles focus correctly.
Update on the workaround above: The
defaults writetrick only partially works. Chrome still steals focus when the extension creates a new tab group viatabs_context_mcp. So the fix covers some interactions but not the initial tab group creation.Still looking for a more complete solution.
Experiencing the same issue on Windows 11 (Claude Desktop, Cowork mode, computer use OFF). Same timing, started after the March 24-25 update.
Chrome aggressively takes foreground focus on every MCP tool call, hijacking keyboard input from whatever app I'm working in. Makes concurrent work impossible while Cowork is running a browser task.
Hi! Thanks for reporting this -- we are working on getting a fix out now. This was a bug!
@gmulley-anthropic I can see it's fixed after an update just now! Awesome, thanks team 🙇
Can confirm this appears to be fixed as of v1.1.9310. Tested multiple MCP actions (navigate, screenshot, JS eval) via the Claude in Chrome extension — browser no longer steals focus from the terminal. Previously reported the same issue in #39600 with screenshots.
Chrome stealing focus during Cowork is a deal-breaker for multitasking.
For macOS users — Safari MCP solves this by design. All commands target Safari tabs by index via AppleScript, never calling 'activate'. Native clicks use CGEvent with window IDs — cursor doesn't move, active app stays focused.
https://github.com/achiya-automation/safari-mcp — 80 tools, works with Claude Code.
This is a duplicate of #39696, which was fixed as of Chrome extension version 1.1.9310.
Same issue here on Linux (Ubuntu, VSCode native extension).
Repro: 3+ Claude Code panels open in parallel within the same VSCode window. Happens intermittently — most of the time parallel panels work fine, but occasionally focus starts jumping between panels on its own. While the focus is jumping, typing does nothing at all — the input is completely unresponsive, no characters appear. Keystrokes aren't dropped though, they're queued somewhere.
Workaround that works for me: stack the panels on top of each other so only one is visible. After ~1 minute the previously-typed text starts appearing very slowly in the input, and a bit later everything is back to normal. No restart needed, and I can split the panels apart again afterwards.
Only happens inside VSCode — same parallel setup in a plain terminal works fine. Likely related to #32726 (panel steals focus on new output) and #7698 (input lag in VSCode extension).
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.