[BUG] Preview windows from different Claude Code sessions share a single cookie/storage partition

Resolved 💬 1 comment Opened Apr 26, 2026 by grempe Closed May 28, 2026

Summary

When two Claude Code Desktop sessions each have their preview window open against different dev servers (different ports, different backends — fully isolated), they silently share a single browser cookie jar / localStorage / sessionStorage namespace. Logging into App A in session 1's preview, then logging into App B in session 2's preview, logs the user out of session 1's preview because storage entries with the same key (e.g., a session cookie) collide and last-write-wins.

This breaks any workflow where a developer has multiple Claude Code sessions open simultaneously and expects each preview to behave like an independent browser tab.

Reproduction

  1. Open two Claude Code Desktop sessions on the same machine, each with its own project (or isolated worktree of the same project).
  2. Start a separate dev server in each session's preview window. Each binds to a different autoPort-assigned port and has its own isolated backend (separate database, separate process).
  3. Log in to the app in session 1's preview.
  4. Log in to the app in session 2's preview.
  5. Switch back to session 1's preview and refresh — logged out.
  6. Log back in on session 1; switch to session 2 — logged out.

The same effect occurs with any per-origin browser storage: sessionStorage, localStorage, IndexedDB, and HTTP cookies whose name collides across the two apps.

Expected

Preview windows from distinct Claude Code sessions should have isolated browser storage. Cookies and storage set by App A on localhost:<port-a> should not affect App B on localhost:<port-b>, regardless of whether they happen to use the same key names.

Likely cause

Claude Code Desktop appears to ship as an Electron app — /Applications/Claude.app/Contents/Frameworks/Electron Framework.framework is present, along with the four standard Electron helper processes (Claude Helper.app, Claude Helper (GPU).app, Claude Helper (Plugin).app, Claude Helper (Renderer).app), Squirrel.framework (Electron's auto-updater), and CFBundleIconFile = electron.icns in Info.plist. If that's accurate, Electron's BrowserWindow / webContents inherit the default session when no explicit partition is set, so all preview windows share a single cookie jar and per-origin storage. Even though the apps run on different loopback ports, any storage keyed by NAME (not the full origin tuple) collides.

Workaround attempted

None viable from the project side. The collision happens at the browser-storage layer; the application can't influence which Electron partition Claude Code's preview window uses.

Suggested fix

Set the Electron partition per preview window, keyed off the launch configuration name and/or the Claude Code session ID. E.g., partition: "persist:claude-preview-<session-id>".

Alternatively (or additionally), expose a partition or profile field in the launch.json schema so users can opt a launch config into its own partition explicitly.

Environment

  • Claude Desktop: Claude 1.4758.0 (fb266c) 2026-04-24T20:22:30.000Z
  • macOS (M-series)
  • Two distinct Claude Code Desktop sessions, each with its own Claude-managed worktree, each running its own dev server and backing data store on a unique autoPort.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗