Claude Desktop Switcher: Three Ways to Split One Mac

Running Claude for your job, your side projects and a client on one Mac means switching more than an account. Chat, Projects, Cowork, Artifacts and Claude Design each carry their own context, and Claude Code has to follow.

Claude Desktop Switcher is a macOS menu bar utility for keeping those environments apart. A guide published on dev.to on 16 October walks through v0.24.7 — and the part worth reading twice is not the install, it is the three separation modes.

Shared, isolated, copied

CSW calls your current desktop and CLI setup Existing Claude. Every new environment gets its own data directory, and each supported component can behave one of three ways. Shared means the environment uses the existing component through a link, so changes can affect both. Isolated means the environment starts with its own independent copy of that component. Copied means it is duplicated once, after which the two evolve apart.

That distinction is the whole product. Sharing rules or history is a deliberate connection between environments, not a convenience default, and it is worth choosing per component rather than per environment.

The three presets, and what each one keeps

Separate everything is the recommended default: supported components start independently with nothing carried over. It also lets the environment run alongside another Claude instance.

Separate conversations and memory too reuses supported global configuration while giving the environment its own project conversation history, auto-memory and input history. The guide lists what carries over on the CLI side: global rules in CLAUDE.md, rule files under rules/, skills, plugins, tool permissions and hooks, and worktree configuration. This is the mode for a second account where you want your familiar setup without the old conversations.

Separate the account only additionally carries over CLI project conversations, auto-memory and input history. The guide attaches a qualification the name does not convey: desktop connector and app settings, device identifiers and session state stay separate anyway.

One practical consequence across all three modes — desktop MCP connectors live in the independently managed desktop configuration, so plan on configuring them once per environment.

Running two at once

Launch behaviour splits along the same line. Environments with shared settings run one at a time, so you quit the running Claude before opening another. Fully isolated environments offer Launch alongside, which is how you keep, say, Work and Research open together. If Research shares configuration with Existing Claude instead, stick to the single-instance workflow to avoid competing writes to shared files.

Identifying windows takes a deliberate step: multiple Claude windows can share one Dock icon, so use Check the current environment in the menu bar, or select the environment in CSW and press Bring to front.

The CLI piece is a separate download

The DMG — Claude-Desktop-Switcher_0.24.7_universal.dmg, supporting Apple Silicon and Intel — installs the desktop utility only. It does not install the csw command, which ships as a standalone asset on the same release page, and updating the app does not update that binary.

A terminal opened inside a CSW-launched Claude Desktop app inherits the environment, so claude just works. An external terminal such as iTerm2 needs an explicit selection, which the guide documents as eval $(csw env Work) before running claude. That points the shell's CLAUDE_CONFIG_DIR at the environment without rewriting your shell startup files or affecting other tabs. Check it with echo $CLAUDE_CONFIG_DIR — a path ending in .context-switcher-claude/profiles/Work/cli-data confirms the Work environment. Desktop and CLI sign-ins are separate, so expect to authenticate twice per environment.

One limit to take seriously

The guide is explicit that CSW provides application-data separation, and that it should not be treated as an operating-system sandbox or a guarantee against every form of data exposure. For keeping a client's Projects out of your personal chat history, that is the right tool. For anything your organisation's rules actually govern — accounts, connectors, files — it is a convenience layer, not a boundary.