English · 简体中文

Use several Claude Desktop windows at once, each on a different API. Keep your official Claude subscription in one window and run as many other windows as you like on custom / third-party APIs (driven by cc-switch). Multi-API, multi-window, multi-account Claude Desktop - on Windows (tested) and macOS (experimental).

Every window has its own data, its own recoloured icon (desktop, taskbar, system tray), its own taskbar button and - if you choose - its own API. The default third-party colour is the official icon in purple-black with a white star; pick any palette (Gemini, GPT, Perplexity, DeepSeek, WorkBuddy) or any #RRGGBB.

Unofficial community tool. Not affiliated with or endorsed by Anthropic or cc-switch. Icons are generated locally from the icon of your installed app; no Anthropic artwork is shipped in this repository.

• Official + third-party at the same time. The official window keeps your subscription login; other windows run on whatever API cc-switch points them at.
• A different API per window. Pick a cc-switch provider for each window (it then talks to that provider's upstream directly), or let a window follow cc-switch's current selection.
• As many windows as you want, in a small GUI in the Anthropic look (English by default, 中文 switch built in).
• Separate icons everywhere: desktop shortcut, taskbar button, window icon, system-tray icon and tooltip.
• Shared sessions: new sessions, titles, pinned/starred sessions, pin order and MCP servers are mirrored between windows; idle background windows restart silently to load them.
• claude:// links open in the window you used last (or a fixed one).
• Same session in two windows? You get a Windows notification before the two transcripts drift apart.
• Update-proof: nothing is patched or copied on Windows; the install path is resolved from the Store package at every launch.
• Prism-grade anti-correlation & network isolation:
  • Dual-source GeoIP consensus & auto-alignment: Probes ipwho.is and ipapi.co through the instance proxy before launch, automatically aligns TZ, --lang, and Accept-Language (COUNTRY_NETWORK_MAP) to the verified exit country, persists .proxy-identity.json, and supports strict proxyExitPolicy: "block" to abort launch on exit IP drift or GeoIP conflict.
  • Runtime proxy drift quarantine (shield.cjs): Injects a Node.js network circuit breaker via NODE_OPTIONS that periodically re-verifies the proxy exit IP (CLAUDE_MULTI_STARTUP_IP) and immediately quarantines outbound http, https, and fetch requests if the proxy drops or drifts mid-session.
  • Chromium DNS / QUIC / WebRTC hardening: Passes --disable-quic, and pre-writes Default/Preferences (webrtc.ip_handling_policy = "disable_non_proxied_udp") while cleaning stale DevToolsActivePort files. Raw WebRTC UDP cannot be blocked from the command line — --force-webrtc-ip-handling-policy and --dns-prefetch-disable no longer exist in Chromium 156, the --webrtc-ip-handling-policy switch string is absent from Claude.exe, and the Preferences value is never propagated to the renderer. What actually works is udp-guard (a firewall rule blocking the host exe's outbound UDP) — see item 5 under "Multi-Official Account Support".
  • Profile identity anchor (.profile-identity.json): Locks each user-data-dir to its owning instanceId and rejects symbolic links to prevent accidental cross-account profile contamination.

Requirements: Windows 11 (10 should work), PowerShell 5.1+, Claude Desktop from the Microsoft Store (AnthropicPBC.Claude), cc-switch with a Claude Desktop provider.

git clone https://github.com/TonF1917/claude-desktop-multiple-windows-different-api
cd claude-desktop-multiple-windows-different-api
.\claude-multi.ps1 install        # icons + shortcuts for every window in instances.json
.\claude-multi.ps1 gui            # or use the Desktop shortcut "Claude Multi Manager"

Then right-click each new Desktop shortcut and choose Pin to taskbar (Windows does not let scripts pin).

The manager GUI exposes the same options: a kind selector next to Add, click-to-edit Proxy (credentials are masked in the grid and the output pane) and Timezone (common IANA zones or typed), Init / Check buttons that run in a background process and stream into an output pane, plus Stop.

The port lives in macos/ (Python 3, standard library only) and now mirrors the Windows feature set: multiple official windows, per-window kind / proxy / timezone, init / check, and a GUI with every option.

Honest status: it was written without access to a Mac. Config handling, palettes, proxy / timezone / launch-argument planning, secret masking, the egress check (against stubbed answers), init file provisioning and the GUI are exercised on Windows. The macOS-only steps - cloning Claude.app (cp -c), sips / iconutil icon tinting, ad-hoc codesign, starting the cloned binary and process matching through ps - follow the documented tool behaviour but have never been run on real hardware. Expect rough edges and please send the terminal output.

Get it: download ClaudeMulti-macOS-v1.2.0.zip (built by macos/build_release.sh), unzip, double-click Claude Multi.command (first time: right-click -> Open), or from a clone:

python3 macos/claude_multi.py gui
python3 macos/claude_multi.py add --id off2 --kind official --palette perplexity --proxy http://127.0.0.1:7890 --timezone America/Toronto
python3 macos/claude_multi.py add --id gem --name "Claude Gemini" --palette gemini [--provider <cc-switch id>]
python3 macos/claude_multi.py init [--id off2]    # data dir, MCP-config link, session link, tinted Claude.app clone (~/Applications/Claude Multi)
python3 macos/claude_multi.py check [--id off2]   # egress IP, residential/datacenter, risk, region, timezone alignment
python3 macos/claude_multi.py launch --id off2    # also: stop, restart, list, remove, install, uninstall, sync, providers
python3 macos/claude_multi.py agent &             # session mirroring + silent background refresh

What a launch does on macOS. The window's own binary is executed directly (the primary official window runs the stock Claude.app; every other window runs its tinted clone), so the environment really reaches the process:

• Strict Proxy Enforcement: --proxy-server is unconditionally passed to Electron with credentials stripped, guaranteeing Chromium routes all traffic through the proxy and preventing direct gateway bypass.
• Storage & Keychain Isolation: --use-mock-keychain and --password-store=basic prevent multi-instances from colliding on macOS Keychain "Claude Safe Storage", avoiding ad-hoc signature prompts and cookie wipeouts.
• WebRTC Leak Prevention: --webrtc-ip-handling-policy=disable_non_proxied_udp and --force-webrtc-ip-handling-policy strictly block direct UDP STUN bypass.
• TZ=<timezone> for that process only, plus --lang=<locale> derived from the timezone (override with "lang").
• --webrtc-ip-handling-policy=disable_non_proxied_udp; --user-data-dir=~/.claude-multi/<id>/Claude for every window except the primary official one.
• Secondary official windows (--kind official, id other than official) get an isolated data dir, any configLibrary is deleted before every start, and the sibling Claude-3p is never created, so they stay pure 1P and never pick up a cc-switch profile.
• Proxy credentials are masked (http://***@host:port) in list, the GUI, errors, the output pane and ~/.claude-multi/claude-multi.log; they remain in plain text in instances.json and in the child's environment.

Limits / not ported: pin / MCP-server sync, claude:// routing and tray icon. The primary official window cannot be isolated from cc-switch like on Windows (there is no LOCALAPPDATA to redirect): launching it while cc-switch has a third-party profile applied can switch it to third-party mode. The python3 from the Xcode tools may ship an old Tk; if gui fails, install Python from python.org or use the CLI.

In addition to 1 Official + N Third-Party windows, the tool now fully supports running multiple official subscription accounts (1P) and third-party accounts (3P) concurrently side-by-side:

1. Pure Direct Multi-Official Connections: The primary official instance uses the default home directory. Secondary official instances (e.g., official2) get isolated virtual data directories and private LOCALAPPDATA with empty Claude-3p, completely stripping configLibrary checks to guarantee 100% pure 1P direct connections without session collisions.

2. Dedicated Network & Proxy Isolation (-Proxy): Bypasses the client-side block on --proxy-server by dynamically injecting $env:HTTPS_PROXY at the child-process level. Assigns dedicated residential proxy exits per account to prevent multi-account IP association bans.

3. Process-Level Timezone Alignment (-Timezone): Dynamically injects $env:TZ (e.g. America/Toronto, Asia/Jakarta) into the child process. The Electron / V8 JavaScript layer aligns 100% with the egress IP's physical location without mutating Windows system timezone, eliminating cross-regional mismatch flags.

4. Automated Provisioning & Egress Audit (init & check):

   • .\claude-multi.ps1 init [-Id <id>]: Provisions the complete environment in one click (creates Data dir, mirrors MCP claude_desktop_config.json, junctions claude-code-sessions, and generates tinted icons and shortcuts).
   • .\claude-multi.ps1 check [-Id <id>]: Audits all instances' egress IP, residential/datacenter status, fraud risk score (0-100), Claude regional support, and timezone alignment.

5. Raw UDP Leak Blocking (udp-guard): --proxy-server only proxies TCP, so WebRTC STUN goes straight out of the physical NIC and hands the peer your real public IP. The command line cannot stop it — --force-webrtc-ip-handling-policy no longer exists in Chromium 156 (silently ignored), the --webrtc-ip-handling-policy switch string is not present in Claude.exe (Electron never compiled it in), and webrtc.ip_handling_policy written to Preferences is not propagated to the renderer. What actually works is a firewall rule that blocks the host exe's outbound UDP:

   .\claude-multi.ps1 udp-guard [-Id <id>]   # run from an elevated PowerShell

   The rule targets only the Claude host Claude.exe (53/UDP is left open so name resolution keeps working) and does not affect other programs on the machine. To verify: after enabling it, a STUN Binding Request to stun.l.google.com:19302 must time out. The WindowsApps path embeds the app version, so an app update invalidates the rule — re-run the command after upgrading. Every launch also checks the rule and writes a GUARD line to ~/.claude-multi/launch-audit.log when the path no longer matches. Set "settings": { "udpGuard": false } to turn the automatic check off.

Choose a Claude Desktop provider in cc-switch (not "Official"). cc-switch starts its gateway on 127.0.0.1:15721 and writes the profile into the shared 3P config folder. Windows that follow cc-switch use that gateway and its currently selected provider. Windows with a specific provider get a profile built from that provider's own base URL, key and model routes and talk to its upstream directly (Anthropic-format providers only; model ids are the real upstream ids). That is how two windows use two different APIs at the same moment. A hand-written profile can be set per window with "profile": "path\\to\\profile.json" (see examples/profile.example.json).

When cc-switch is set to Official, third-party windows have no profile and show the normal sign-in screen.

Known limit - pins. Each Claude Desktop keeps its pinned list in memory and rewrites it itself: a running window keeps showing its own pins until it is restarted, and a starting window trims the list it reads (tested: 17 pins written while closed came back as 12 within 8 seconds; the dropped ones are sessions created after 12 Oct 23:50 plus one older one - the rule is the app's, not ours). This tool keeps the config files identical and never lets an empty or new window wipe them, but it cannot force two windows to display the same pins.

Why not instantly? Claude Desktop does read these folders - but only when it starts, and again only when the signed-in account or organisation changes. It has no file watcher, rewriting its config.json does not make it re-read anything, and remote debugging is blocked in the production build, so nothing outside the app can tell a running window to re-read the folder. The closest safe thing is the silent restart: a window restarts in the background only if it is not focused, has not written a session file in the last 45 s, and none of its agent/tool child processes is using CPU. The restarted window comes back minimised and without taking the focus (it is started with SW_SHOWMINNOACTIVE), and syncing shows no pop-ups at all: notifications are off by default and can be switched on in the manager. A window you are using right now (focused and keyboard/mouse input in the last 90 s) is never restarted: you get a Windows notification with a Reload now button instead (or use Restart selected in the manager); once you have been idle for 90 s it is refreshed automatically. Session folders may be shared between windows through junctions - the check is therefore per running window ("does it know every session file that exists?"), not based on copying. The official window is excluded unless you tick Also live-refresh the official window (it may hold unsent drafts).

Same session in two windows. Every window runs its own Claude Code process per session (--resume=<id>). If you send in both, both append to the same transcript while each keeps its own context, so the history interleaves and the windows disagree. The agent notifies you when a session is live in two windows and one of them is working - keep a session active in one window at a time.

How sessions look. Every window shows the same merged list; there is no per-window badge. A session keeps its folder, model and effort, but when you open it in another window it runs through that window's login/provider (subscription in the official one, the chosen provider in a third-party one).

1. One config library for everyone. The app reads configLibrary from %LOCALAPPDATA%\Claude-3p; cc-switch writes the third-party profile there; a profile with disableDeploymentModeChooser forces every window that reads it into 3P mode - including the official one on its next start.
2. --user-data-dir and CLAUDE_USER_DATA_DIR do not help on Windows. The production build strips the env var and overrides the data dir in 3P mode, so a second 3P window collides with the first and exits silently.
3. %LOCALAPPDATA% does. The 3P data dir is derived from that variable, so each extra window starts with its own private LOCALAPPDATA (~\.claude-multi\<id>\Local) and its own profile.
4. Official isolation. The official app is started with a private LOCALAPPDATA whose Claude-3p is empty (Claude and Packages are junctions to the real ones), so it can never be forced into 3P.
5. Separate taskbar buttons and tray icons. Electron gives every window the same AppUserModelID. A small background agent sets a per-window ID and icon (SHGetPropertyStoreForWindow, WM_SETICON) and re-skins the window's notification-area icon (Shell_NotifyIcon, NIM_MODIFY); the shortcuts carry matching IDs.
6. Icons must not live in AppData\*\ClaudeMulti. Explorer and the taskbar render a blank page for .ico files under such a folder (a .ico anywhere else works), so icons are generated into ~\.claude-multi\icons.
7. Update-proof. The install path is resolved from the MSIX package on every launch; nothing is copied or patched, and no version number is stored.

• Windows: the official window picks up its isolation the next time it is restarted; a running window is never touched.
• Shortcuts that bypass this tool (Start-menu tile, protocol links registered elsewhere) start the official app without isolation.
• Everything relies on undocumented app behaviour and may break with a future Claude Desktop release.
• cc-switch is an independent project.

MIT - see LICENSE.