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

Same issues present on Windows 11

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

Same issue here. Edge Version 146.0.3856.72

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.

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

Same present on Win10 Edge 146.0.3856.109

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

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.

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:

• #34909 (Cowork Edge connector support, Windows) — closed as "not planned" / invalid
• #24367 (native messaging host not registered for Edge on Windows) — closed as duplicate
• #21783 (Claude in Chrome CSP failure on Edge Windows) — closed as "not planned," marked stale
• #14535 (/chrome command should detect Edge) — closed as duplicate
• #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.

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.

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

Same problem with Edge on MacOS.

Come on Anthropic, just give this issue to an AI agent!

Concur. this one is silly...

All this AI and 100x productivity and they cant fix a silly bug? Obviously not running a hands of software factory here.

Come on Anthropic, show us how its done!

This defect cripples the potential usefulness of this extension, which is one of Claude's best product differentiators.

same here on windows 11

Same :)

Update — Anthropic support response received

Raised this via Anthropic support and received a reply on 12 June 2026 (through their Fin AI agent) confirming the issue.

Summary of the response:

• Confirmed as a known issue; the team is working on it.
• No user-side workaround available at the moment — the fix has to come from Anthropic's side.
• No specific timeline committed.
• Support has closed the ticket on their end but asked us to report back if the issue persists.

Screenshot of the response attached below.

<img width="405" height="709" alt="Image" src="https://github.com/user-attachments/assets/628b088c-c10e-4df3-bfe7-8a7d4baaa4ab" />

+1 — Same issue on Windows 11 with Microsoft Edge.

The chat pin/fix button (side panel persist toggle) visible in Chrome is not showing up in Edge at all. The side panel also closes whenever switching tabs, which makes it essentially unusable for multi-tab workflows.

Please prioritize Edge support — many enterprise users are on Edge by default. Looking forward to the fix!

@claude Please work on this.

Also hitting this on Windows 11 / Edge (original report was macOS). Same symptom: side panel closes and the session disconnects on every tab switch or new tab, requiring a reconnect each time — which makes the extension unusable for anything spanning multiple tabs.

Root cause looks correctly identified above: the panel is enabled for one tabId only, with no chrome.tabs.onActivated listener to re-attach on switch. Chrome tolerates this; Edge doesn't.

On priority: Edge is listed as officially supported for this integration, and on enterprise Windows desktops — where this extension actually runs — Edge is roughly the #2 browser. Paying for a Max plan and having the browser feature broken on a supported, widely-used browser is a rough experience. A small onActivated re-open handler would resolve it.

Please fix this.

I have a workaround. Not sure if it's okay to post or not.

This NEEDS to be fixed.

This is incredibly annoying, especially since the fix is provided already. @claude should be able to auto-fix this in like 30 seconds.

For anyone hitting this on Edge, I packaged a workaround as a small open-source patcher so you don't have to hand-edit the bundle:

https://github.com/afterglow-labs/claude-edge-window-mode

It's a PowerShell script (Windows/Edge). It downloads the current extension from Google's official Web Store update endpoint, patches a local copy, and prints a load-unpacked folder. The repo contains only the script and docs — no Anthropic code is redistributed; you patch your own installed copy. Verified against the current v1.0.80.

It offers two fixes for the closing-panel problem — pick either, or install a small settings page (right-click the Claude icon) that toggles between them live:

• Sidebar-persist — keeps the native docked side panel but stops Edge from closing it on tab switch. The panel enables per-tab today (setOptions({tabId, path, enabled})); enabling it globally instead (drop the tabId key, keep ?tabId= in the path) means every tab has it enabled, so Edge never closes it. No re-opening, no user gesture needed.
• Window mode — the extension already ships a full window mode (sidepanel.html?mode=window) with a TARGET_TAB_ID storage fallback, used internally for scheduled tasks but not reachable from the toolbar. The patch wires the icon to it: Claude opens in its own persistent window that survives tab switches, new tabs, and minimize. (Bonus: each click opens an independent window bound to its tab, so you can run multiple sessions on different tabs at once.)

Why the onActivated fix suggested earlier can't work: chrome.sidePanel.open({tabId}) throws may only be called in response to a user gesture inside that listener — tab activation isn't a gesture — and setOptions alone re-enables but doesn't re-show the panel. The global-enable trick above avoids needing to re-open at all.

For the Anthropic team: since both the global-enable behavior and ?mode=window + TARGET_TAB_ID already exist in the shipped bundle, fixing this on Edge (or exposing window mode as a setting) looks like a genuinely small change.

(Not affiliated with Anthropic; use at your own risk.)

Also affected —

Windows 10, Edge 150.0.4078.65 (64-bit), Claude for Chrome extension. Confirming this is still happening as of July 2026, after the update above about escalating to the Edge team in June. Panel closes when switching to another app window (not just tab-switching), and reopening the extension starts a brand new chat instead of restoring the previous session.

Would also support the fix suggested above (setPanelBehavior({ openPanelOnActionClick: true }) with window-level panel options) if that resolves it for Windows too.