Claude in Chrome extension: Side panel closes when switching/opening tabs in Microsoft Edge on macOS

[ogmios2]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When using the Claude extension in Microsoft Edge on macOS, the side panel closes every time I open a new tab or switch between tabs. This also disconnects the Claude browser session, requiring me to reopen the panel and reconnect.

In Google Chrome, the side panel persists across tab switches as expected.

What Should Happen?

The side panel should stay open and the session should remain connected when switching between tabs or opening a new tab, consistent with the behavior in Google Chrome.

Error Messages/Logs

Steps to Reproduce

1. Install the Claude extension in Microsoft Edge on macOS
2. 2. Open the side panel (click extension icon or Cmd+E)
3. 3. Start a Claude session and connect via Claude in Chrome / Cowork
4. 4. Open a new tab (Cmd+T) or click on a different tab
      Expected: Side panel stays open and the session remains connected.
      Actual: Side panel closes and the Claude browser session is lost.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

Claude in Chrome v1.0.57

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment

• OS: macOS
• • Browser: Microsoft Edge (Chromium-based)
• • • Extension: Claude in Chrome v1.0.57
• • • • Native Messaging Hosts: Correctly registered in ~/Library/Application Support/Microsoft Edge/NativeMessagingHosts/

---

Root Cause Analysis

After inspecting the extension source (v1.0.57), the side panel is opened per-tab:

chrome.sidePanel.setOptions({
  tabId: e,
  path: `sidepanel.html?tabId=${encodeURIComponent(e)}`,
  enabled: true
});
chrome.sidePanel.open({ tabId: e });

The side panel is bound to a specific tabId. Chrome handles this gracefully by keeping the panel visible when switching tabs, but Edge closes it because the panel was only enabled for the original tab.

The extension has no chrome.tabs.onActivated listener to re-open or re-attach the side panel when the user switches tabs. It relies on Chrome's more permissive side panel behavior, which Edge does not replicate.

---

Suggested Fix

Add a chrome.tabs.onActivated listener in the service worker that re-enables and re-opens the side panel for the newly activated tab when a session is active:

chrome.tabs.onActivated.addListener(async (activeInfo) => {
  if (hasActiveSession()) {
    chrome.sidePanel.setOptions({
      tabId: activeInfo.tabId,
      path: `sidepanel.html?tabId=${encodeURIComponent(activeInfo.tabId)}`,
      enabled: true
    });
    chrome.sidePanel.open({ tabId: activeInfo.tabId });
  }
});

Alternatively, consider using chrome.sidePanel.setPanelBehavior({ openPanelOnActionClick: true }) combined with window-level (non tab-specific) panel options to make the panel persist across all tabs in the window.

[Lionheart831]

Same issues present on Windows 11

[CanReader]

I get the same issue in my Windows 11 25H2 10.0.26200 Build 26200

[Sealjay]

Same issue here. Edge Version 146.0.3856.72

[couchpardons]

Experiencing this on macOS as well (Edge on MacBook Pro). Beyond the side panel closing on tab switch, the bigger issue is that all chat history and conversation context is lost when the panel closes. When you reopen the sidebar after switching back to the original tab, it's a completely fresh session — no prior messages, no context.
In Chrome, the panel stays alive in the background so conversation state is preserved. In Edge, the panel is fully destroyed and reinitialized on each reopen, which makes it unusable for any multi-step conversation where you might need to briefly check another tab.
This effectively makes the Claude extension broken in Edge, not just inconvenient. The side panel closing is annoying; losing the entire conversation makes it a dealbreaker.
The proposed fix in the original post (adding a tabs.onActivated listener) would solve the panel closing, but even as a stopgap, persisting conversation state so it survives a panel close/reopen would make a huge difference for Edge users.

[proguha]

Still on the same issue. Edge version Version 146.0.3856.97 (Official build) (arm64)

[skyfackr]

Same present on Win10 Edge 146.0.3856.109

[BillyHilly]

Just updated Edge and the problem persists
Version 147.0.3912.72 (Official build) (arm64)

[afterglow-labs]

Seeing this on Edge/Windows 11 with v1.0.68. Tried both fixes in the OP and neither works:

onActivated + re-open. chrome.sidePanel.open({tabId}) rejects inside the listener with:

Error: `sidePanel.open()` may only be called in response to a user gesture.

Tab activation isn't a gesture, so the browser hard-blocks it. setOptions alone re-enables the panel but doesn't re-show it.

setPanelBehavior + window-level options. setPanelBehavior on its own doesn't change the close-on-switch behavior (confirmed). Going truly window-level means dropping tabId from setOptions, which breaks sidepanel-*.js — there are around 20 sites in there reading URLSearchParams().get("tabId"), so the sidepanel would need a rewrite to query the active tab itself on load and on its own onActivated listener.

As a workaround I got Claude to launch in a small persistent window instead of the sidepanel, which is honestly better than the sidepanel anyway — it stays visible regardless of what tab you're on, survives minimize, tab grouping still works, and you can open multiple Claude sessions and have them working on different things at the same time.

The extension already has a window-mode code path built in that it uses internally for scheduled tasks. It opens Claude as a popup pointed at sidepanel.html?mode=window, and the sidepanel reads a TARGET_TAB_ID from storage as a fallback when the ?tabId= URL param is missing. It just isn't connected to the action icon. Here's the code:

chrome.sidePanel.setPanelBehavior({ openPanelOnActionClick: false });

chrome.action.onClicked.addListener(async (tab) => {
  if (!tab?.id) return;
  await storage.set(TARGET_TAB_ID, tab.id);
  await chrome.windows.create({
    url: chrome.runtime.getURL("sidepanel.html?mode=window"),
    type: "popup",
    width: 500,
    height: 768,
    focused: true
  });
});

The file to edit is assets/service-worker.ts-<hash>.js — replace the body of the existing K(e) function with the handler above.

Each popup binds to its own TARGET_TAB_ID, so different tabs stay independent. They do share the browser though, so if you point two at the same tab they interfere. I told them to just make local edits on a page and reply to whatever text shows up and they figured out what was happening and started having a conversation. Fun little interaction.

Point being, window-mode isn't only an Edge band-aid, it's a capability upgrade. Could ship as an opt-in setting while the proper fix lands.

[couchpardons]

Seven weeks in and this issue still has no assignee, no linked PR, and no milestone. The original report includes a full root-cause analysis and a working fix (three lines in the service worker), so this doesn't appear to be a triage-complexity problem.

Zooming out, there's a consistent pattern across Edge-related issues in this repo:

• [Feature Request] Claude Desktop Cowork: Support Microsoft Edge as browser connector (not just Chrome) #34909 (Cowork Edge connector support, Windows) — closed as "not planned" / invalid
• [BUG] Claude browser extension native messaging host not registered for Microsoft Edge #24367 (native messaging host not registered for Edge on Windows) — closed as duplicate
• Bug: Claude in Chrome extension fails to connect due to CSP errors #21783 (Claude in Chrome CSP failure on Edge Windows) — closed as "not planned," marked stale
• [Feature Request] /chrome command should detect extension in Chromium-based browsers (Edge) #14535 (/chrome command should detect Edge) — closed as duplicate
• Claude in Chrome: Native messaging host not installed for Chromium/Brave browsers (Linux) #14391 (native messaging host for Chromium-based browsers on Linux) — still open, no movement

A third-party repo (stolot0mt0m/claude-chromium-native-messaging) has sprung up specifically to patch Anthropic's Chrome-only native messaging registration, and its README states outright that "Claude's official browser extension only supports Google Chrome."

Given that pattern, the question isn't really "when will this bug be fixed" — it's whether Edge is supported at all. Can someone from Anthropic confirm:

1. Is Microsoft Edge a supported platform for the Claude in Chrome extension, or is Chrome-only the official position?
2. If supported, is there an ETA for a fix on this specific bug?
3. If not supported, can that be stated explicitly in the extension listing, the troubleshooting docs, and the Cowork onboarding flow, so Edge users stop filing duplicate issues and wasting triage cycles?

The ambiguity is the worst of both worlds: the extension installs and partially works in Edge, which signals support, but bugs against it get closed or ignored, which signals the opposite. A clear statement either way would resolve this for everyone.

[rodneyjoyce]

Claude on Edge is essentially useless, unless you don't mind having a dedicated Browser and window open or a spare computer lying around. Everytime the prompt starts and I move away to other work when I come back it has lost all context and history.

[kvacha13]

Same problem here with windows 11 edge. The problem really needs to be addressed, otherwise it is useless.