Simple Claude Account Manager for Windows

An independent open-source utility called Claude Accounts launched in an early preview v0.1.0 release to enable multiple profile management for the official Claude Desktop client on Windows 11. Built without an affiliation to Anthropic and distributed under the MIT license, the desktop launcher creates named user workspaces by isolating profile data in discrete local folders, as detailed in github.com's report. The release includes architecture-specific packages for both Intel or AMD 64-bit systems and ARM-powered machines without requiring third-party dependencies or external runtime downloads.

This analysis details the technical mechanics, configuration procedures, known constraints, and data-handling routines of the v0.1.0 release for developers and enterprise operators managing distinct accounts. Readers will learn how the software manages local file structures, routes browser sign-in callbacks, and isolates session states across simultaneous desktop windows. The piece also details the manual command fallbacks, underlying storage locations, and local build steps necessary for evaluating or auditing the utility.

01Named account directories and launcher controls

The software isolates named user profiles by launching the installed Claude Desktop executable alongside the user-data-dir startup parameter. This argument ensures each configured account accesses a separate local data folder while preserving authentication state across program restarts. Because the official Claude Desktop client retains internal responsibility for session expiration and re-authentication, the launcher never collects passwords, inspects tokens, makes subscription API calls, or sends telemetry.

The user interface delivers basic workspace management tools including buttons to add, open, rename, and delete specific accounts. Users can launch separate instances directly from the main account overview window or trigger launches from an integrated Windows system tray menu. The launcher automatically discovers Microsoft Store installations and common standalone executable locations, but it also allows operators to designate a custom Claude Desktop executable path through settings.

Operators can run the utility as a standalone portable binary named ClaudeAccounts.exe or execute Install.cmd to set up shortcuts for the current Windows user profile. The installer generates Start menu and desktop links alongside a native Windows uninstall entry without touching shared system spaces. Existing installations can immediately ingest prior workspace identifiers and saved records stored in the local application data directory from earlier development prototypes.

02Architecture selection and initial setup steps

Installation requires an active Windows 11 environment alongside the official Claude Desktop application. Developers must select the release distribution matching their hardware architecture, picking the win-arm64 package for Windows on ARM or win-x64 for standard Intel and AMD processors. Both releases bundle a self-contained .NET runtime directly into the payload, removing any prerequisite to configure developer SDKs or download global framework packages beforehand.

Setup begins by extracting the distributed ZIP archive into a chosen local folder and launching the executable or running the install script. The operator creates a profile label inside the management panel, selects the Open Claude Desktop button, and completes authentication directly within Claude Desktop own interface. Users must repeat this sequence sequentially for each separate profile, onboarding and authenticating only one profile at a time to prevent session collisions.

Unsigned preview releases may surface standard Windows reputation warnings upon initial execution because the repository does not distribute a private code-signing key. Organizations preparing wider internal or public rollouts must sign the compiled release binaries with their own verified certificates. The UI status monitor marks each configured account as launched rather than connected, deliberately ignoring authentication state or user identity to maintain strict operational detachment.

03Protocol handler routing and Google callbacks

Handling Google authentication requires a specialized workflow because external web browser redirects can misroute callbacks to an unintended active Claude window. Operators must select the targeted profile inside the launcher and click the Browser sign-in button before initiating the Google sign-in flow. This action temporarily rewrites the per-user claude protocol handler in the Windows registry to direct browser redirects straight to the specific process and data directory.

The launcher continuously monitors Windows association resolution before confirming the routing path as active. This temporary association expires automatically after ten minutes, but it also shuts down immediately if the user quits the launcher, opens another profile, or selects End browser sign-in. Existing registry associations receive full backups prior to any modification, ensuring restoration when ownership lapses or recovering original configurations following an unexpected system crash.

When Windows fails to verify automatic protocol routing, the application reverts registry changes and opens a manual callback entry dialog. The user completes Google authentication inside the browser, copies the claude login link from the Open Claude button, and pastes it into the dialogue box. The application sends this callback directly to the running profile via command-line arguments without logging or persisting the token string on disk.

04Machine level limits and verification boundaries

Testing observed separate profile execution on Windows ARM64 using Microsoft Store version 4.23118.0 alongside standard default instances. However, this interaction functions solely as a local technical observation rather than a supported Anthropic API integration guarantee. The developer has not performed end-to-end multi-account authentication testing across multiple live accounts, leaving signed-in session persistence and OAuth callback reliability subject to user verification.

The utility does not function as an operating system security boundary between distinct Windows users or separate corporate environments. Shared machine infrastructure including Cowork, Claude Code, protocol definitions, hardware shortcuts, and local plugins may trigger operational conflicts between running windows. Furthermore, upstream client updates from Anthropic could alter command-line flags or profile directory handling, requiring operators to discontinue use if directory boundaries break down.

Default Claude Desktop installations do not import preexisting sessions into the new management environment. If browser authentication redirects to an incorrect active Claude instance, operators should shut down background Claude processes and retry sign-in within the target profile. The developer explicitly advises against logging out of alternate profiles to resolve routing mismatches, recommending process termination instead to keep authentication state intact.

05Atomic file storage and session preservation

All dynamic program records reside entirely outside the installation folder within the local user data directory under ClaudeAccounts. The root contains accounts.json for profile names, unique identifiers, and launch timestamps, mirrored by accounts.json.bak containing the preceding valid configuration. Hardware paths and tray toggles persist inside settings.json, while sign-in-route.json holds temporary registry backups whenever protocol interception remains active.

Sensitive authentication data and cache directories live under discrete subfolders labeled Profiles with assigned random identifiers. Claude Desktop manages these folders directly, and the author instructs users never to upload profile trees to public forums or code repositories. The included gitignore file explicitly ignores common configuration files and profile data directories to prevent accidental credential distribution during software testing or packaging.

File writes utilize atomic write procedures to avoid configuration loss during sudden process interruptions or disk errors. If the primary configuration corrupts, the engine restores the previous backup while retaining the damaged document for administrator review. Removing a profile via the interface deletes its registry entry but preserves data directories on disk, requiring operators to terminate processes and manually erase leftover files to purge credentials completely.