Keeping Claude Accounts Separate: A Windows Fix for a Shared-Config Problem

If you use the Claude CLI with more than one account — say, a personal account and a work (Claude Teams / managed) account — you've probably run into a quirk: they all share the same ~/.claude home directory. That's fine for most settings, but it causes a real problem with telemetry.

The Problem

Managed accounts typically set up OpenTelemetry (OTEL) for usage tracking. OTEL settings live in the home directory — and since that directory is shared across accounts, logging into your personal account doesn't isolate you from it. Your personal usage ends up tracked by your organization's managed account telemetry, because both accounts are reading from the same ~/.claude.

The Fix

The fix is to give each account its own config root, and switch between them by setting CLAUDE_CONFIG_DIR before launching claude. When the work account starts up with its own config directory, it picks up the correct (work-configured) remote-settings.json, and your personal account's directory stays untouched by telemetry settings.

Concretely:

• Work account config lives in ~/.claude-work, and that's where the work-configured remote-settings.json goes.
• Personal account config remains in the default ~/.claude, unchanged — though if remote-settings.json already exists there from before, delete it.

On Linux/macOS: a Bash Alias

The simplest implementation is a one-line alias that sets the env var just for that invocation:

alias claude-work='CLAUDE_CONFIG_DIR="$HOME/.claude-work" claude'

Clean, scoped to the single command, done.

On Windows: There's No Direct Equivalent

Windows doesn't have a shell construct that matches this exactly — the right approach depends on which shell you're using.

PowerShell

PowerShell aliases can't take arguments or set env vars inline, so you need a function instead. Add this to your $PROFILE:

function claude-work {
    $env:CLAUDE_CONFIG_DIR = "$HOME\.claude-work"
    claude @args
}

@args forwards whatever arguments you pass to claude-work. One catch: this sets CLAUDE_CONFIG_DIR for the rest of the session, not just this command — PowerShell has no clean syntax for a command-scoped env var. If you want that bash-alias behavior (scoped only to this invocation), wrap it:

function claude-work {
    $prev = $env:CLAUDE_CONFIG_DIR
    $env:CLAUDE_CONFIG_DIR = "$HOME\.claude-work"
    try { claude @args } finally { $env:CLAUDE_CONFIG_DIR = $prev }
}

cmd.exe

Use a doskey macro:

doskey claude-work=set CLAUDE_CONFIG_DIR=%USERPROFILE%\.claude-work $T claude $*

$T chains commands, $* forwards arguments. Doskey macros aren't persistent by default, though — you'd need to load them via a startup script referenced in the registry's AutoRun key, or from a batch file.

Batch File — the Recommended Option

If you want something that works reliably regardless of which shell invokes it (cmd or PowerShell), a batch file is the way to go. Create claude-work.bat somewhere on your PATH:

@echo off
set "CLAUDE_CONFIG_DIR=%USERPROFILE%\.claude-work"
claude %*

This is inherently scoped — set only affects the batch file's own process — and it works the same whether you call it from cmd or PowerShell.

Takeaway

The underlying problem — shared config directory, shared OTEL settings — isn't a Windows-specific issue. But Windows' lack of an inline-env-var alias means the fix looks different depending on your shell. A batch file is the most portable answer if you move between cmd and PowerShell; a $PROFILE function is more idiomatic if you live in PowerShell exclusively.