Claude in Chrome: no background-tab option — every tool call steals OS focus (regression ~2026-03-25)

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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?

The Claude in Chrome extension forces its tab/window to the foreground on every interaction. During background Cowork work this repeatedly rips focus and keyboard input away from whatever the user is doing in another window. Onset ~2026-03-25, coinciding with an extension auto-update. It reproduces with computer-use disabled entirely, so this is not a computer-use issue.

**The two browser toolsets are not at parity — the in-app browser already solved this, the extension did not.**

`mcp__Claude_Browser__tabs_create` exposes a `foreground` parameter, documented as: "Opens in the background by default — set `foreground: true` when the user wants to watch."

`mcp__claude-in-chrome__tabs_create_mcp` exposes no parameters at all (`{}`), and `mcp__claude-in-chrome__navigate` exposes only `tabId` and `url`. So the extension has no way to create or navigate a tab without activating it. `chrome.tabs.create({active: false})` and `chrome.tabs.update({active: false})` are available in the Chrome API and are not being used.

**Impact**

- Keystrokes intended for another application land in Chrome mid-typing. This is dangerous over SSH, where stolen keystrokes can execute unintended commands.
- Concurrent Cowork sessions fight each other for the foreground.
- It defeats the premise of background work: the user cannot do anything else while Cowork runs.

**Not fixable by the user**

- Separate Chrome profiles do not help. Profiles are not focus isolation, and only one extension instance is connected at a time (confirmed via `list_connected_browsers`, which returned a single browser). Raising any Chrome window pulls the user out of whichever window they were working in.
- Rolling the native host back (2.1.85 to 2.1.83) does not help; the cause is in the extension.
- Virtual desktops reduce visual noise but do not stop the focus theft.

There is no setting in Claude Code, in the extension, or in Cowork that controls this.

### What Should Happen?

Agent-initiated tab creation and navigation should not activate the tab or raise the Chrome window. The user should be able to keep typing in another application while Cowork works in the background.

Concretely: add an `active` parameter to `tabs_create_mcp` and `navigate`, defaulting to `false` for agent-initiated calls, matching the behaviour `Claude_Browser` already ships.

### Error Messages/Logs

```shell
No error output — the failure is behavioural. The relevant evidence is the tool schemas themselves.

Extension (no way to stay in the background):

mcp__claude-in-chrome__tabs_create_mcp
parameters: {} <- no active / foreground

mcp__claude-in-chrome__navigate
parameters: { tabId, url } <- no active / foreground

In-app browser (already correct):

mcp__Claude_Browser__tabs_create
parameters: { foreground }
"Opens in the background by default — set foreground: true
when the user wants to watch."
```

### Steps to Reproduce

1. Connect the Claude in Chrome extension to Chrome. Disable computer-use entirely.
2. Start a Cowork task that does any browser work (navigate to a page, read it, click something).
3. While it runs, switch to another window — a terminal, an editor, another Chrome window — and start typing.
4. On every browser tool call, Chrome jumps to the foreground and takes keyboard focus. Typing lands in Chrome instead of the intended window.
5. With several concurrent Cowork sessions, the sessions also fight each other for the foreground.

### Claude Model

None

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

_No response_

### Claude Code Version

2.1.241 (Claude Code)

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

PowerShell

### Additional Information

**Environment:** Windows 11, Claude Code 2.1.241 with Cowork, Claude in Chrome extension. Reproduces with computer-use disabled. Still present after updating Claude Code from 2.1.218 to 2.1.241.

**Note on triage — this is why I am opening a new report rather than commenting on an existing one.**

This has been reported at least four times, and each report was closed as a duplicate of another closed report, so no open canonical issue remains:

- #39558 — closed as duplicate of #39696
- #39600 — closed as duplicate
- #39696 — closed as duplicate of #31119
- #31119 (opened 2026-03-05) — also closed as duplicate

No maintainer response appears on any of them. #31119 asked for two things: background tab creation and a tab-close tool. The tab-close half shipped (`tabs_close_mcp` now exists). The background-tab half did not, and that is the half causing the focus theft.

I am not filing a duplicate to be noisy — I could find no open issue tracking this, and the parity evidence above (the in-app browser already has the parameter the extension lacks) does not appear in any of the closed reports.

Start by comparing the extension entry points mcp__claude-in-chrome__tabs_create_mcp and mcp__claude-in-chrome__navigate with the in-app tabs_create schema, then inspect how they call chrome.tabs.create and chrome.tabs.update. Done means agent-initiated creation and navigation stay in the background by default, while the reported reproduction no longer steals focus on Windows.

Written by the indexing model from the issue text.