CC Switch for Claude Code: Managing Accounts, Providers, and Configs

At 9:05 a.m., you point Claude Code at a company gateway. At 11:30, you need a personal Anthropic account. After lunch, a customer repository requires its own MCP servers and model aliases. By the end of the day, ~/.claude/settings.json has been edited three times, one shell still contains an old token, and nobody is certain which endpoint the next request will hit.

CC Switch addresses that operational problem with named profiles managed from a desktop application. Instead of manually moving credentials, provider URLs, MCP definitions, and agent-specific configuration files, you select the profile that should be active. The important engineering detail is that this is configuration management, not account virtualization: Claude Code still reads its normal local files and environment settings, while CC Switch coordinates what is written there.

That convenience is substantial, but so is the trust boundary. A utility that can switch developer accounts must be able to read or write developer credentials. Before adopting it, you should understand exactly which files it changes, where its own database lives, and how those files are protected.

What CC Switch Claude Code Management Actually Does

CC Switch is an open-source desktop configuration manager for coding agents. Its supported integrations have expanded over time, so check the current repository and release notes before standardizing on a fixed list. Claude Code is a primary integration; current versions also target other command-line coding agents such as Codex and Gemini CLI.

For Claude Code, a provider profile usually combines:

• An Anthropic-compatible API endpoint
• An API key or authentication token
• Model mappings or model-related environment values
• Additional environment variables
• MCP server definitions
• Claude Code settings that should follow the profile

This is useful when “account” does not simply mean an Anthropic login. In real deployments, developers may alternate between:

• Direct Anthropic API access
• An organization’s authenticated API gateway
• A third-party Anthropic-compatible provider
• Separate personal, staging, and production billing accounts
• A local or remote proxy exposing compatible request semantics

CC Switch centralizes those choices and activates the selected configuration. It does not make every compatible endpoint behave identically. Differences in model names, authentication headers, rate limits, prompt caching, and unsupported API fields remain the provider’s responsibility.

The table exposes the trade-off: CC Switch reduces operator error, but it becomes another privileged local application.

Installation and Platform Support

CC Switch is distributed through the project’s GitHub Releases page. The repository currently describes desktop support for macOS, Windows, and Linux, with release artifacts varying by platform and version. Verify the assets attached to the release you intend to deploy; the existence of source code does not guarantee that every operating-system version, CPU architecture, or package format is built for every release.

On macOS, the project provides a Homebrew cask workflow:

brew tap farion1231/cc-switch
brew install --cask cc-switch

Before using a downloaded binary in a managed environment, verify what Homebrew installed:

brew info --cask cc-switch
brew list --cask cc-switch
codesign -dv --verbose=4 "/Applications/CC Switch.app" 2>&1

Windows and Linux users should take the installer or package from the release’s published assets. Package names and channels can change, so I avoid putting a potentially stale winget, Scoop, .deb, or AppImage command into workstation bootstrap scripts without pinning and testing the exact release.

For a controlled rollout:

1. Pin a CC Switch version.
2. Record the expected release checksum.
3. Test it against disposable Claude Code configuration.
4. Inventory all files changed during profile activation.
5. Define an upgrade process rather than silently tracking the latest release.

A simple pre-install snapshot helps:

mkdir -p /tmp/claude-config-before
cp -R ~/.claude /tmp/claude-config-before/ 2>/dev/null || true

# Install CC Switch, create a test profile, and activate it.

diff -ru /tmp/claude-config-before/.claude ~/.claude || true

This catches behavior that documentation can miss, including formatting rewrites, removed fields, or MCP entries merged at an unexpected scope.

Creating and Switching Provider Profiles

A profile should represent one coherent security and billing context. I use names that communicate impact, such as:

• anthropic-personal
• company-gateway-dev
• customer-a-restricted
• local-proxy-test

Avoid labels like default-2. When a production incident happens, the active profile name should answer “where will this request go?” without opening an editor.

A Claude Code profile backed by an Anthropic-compatible gateway might produce settings conceptually similar to:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://ai-gateway.example.com/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "${TOKEN_MANAGED_BY_PROFILE}",
    "ANTHROPIC_MODEL": "company-claude-default"
  },
  "permissions": {
    "defaultMode": "default"
  }
}

The exact variables required depend on the provider and Claude Code version. Some services expect ANTHROPIC_API_KEY; some gateway integrations use ANTHROPIC_AUTH_TOKEN. Do not populate both merely to make authentication “more likely” to work. Determine which credential Claude Code will prefer, because a stale higher-precedence value can route requests under the wrong account.

After switching, start a new Claude Code process:

claude

What actually happens when you switch while Claude Code is already running is easy to misunderstand. The utility can update files on disk, but it cannot reliably replace environment values already inherited by a running process. Existing sessions may therefore continue using their original provider until restarted.

Validate the effective configuration without printing secrets:

python3 - <<'PY'
import json
from pathlib import Path

path = Path.home() / ".claude" / "settings.json"
data = json.loads(path.read_text())
env = data.get("env", {})

for key, value in sorted(env.items()):
    if "KEY" in key or "TOKEN" in key or "SECRET" in key:
        value = "<redacted>"
    print(f"{key}={value}")
PY

A common gotcha is testing only whether Claude responds. A compatible proxy can return a valid response while silently mapping your requested model to another model. Verify the provider’s request logs or gateway audit trail when model identity matters.

MCP Settings Across Agents

MCP configuration is where centralization becomes more useful than a token picker. A developer may have filesystem, issue-tracker, database, and browser servers configured across several agents, each with its own schema or storage location.

A typical MCP server definition contains a command and arguments:

{
  "mcpServers": {
    "project-files": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/alex/work/customer-a"
      ]
    }
  }
}

Treat this as executable configuration. Activating the profile may allow an agent to launch npx, execute a package, and expose the specified directory to the model-facing tool layer.

In practice, I separate MCP profiles by repository sensitivity:

• A general profile exposes documentation and low-risk tools.
• A customer profile exposes only that customer’s working directory.
• Database and production-control servers are not enabled globally.
• Tokens used by MCP servers are scoped independently from the model provider token.

Also compare CC Switch’s generated result with the agent’s native MCP command where available. For Claude Code, inspect the active servers after switching:

claude mcp list

Do not assume one MCP JSON object can be copied unchanged into every coding agent. CC Switch can normalize management in its UI, but each downstream agent still has its own schema, scope rules, and lifecycle behavior.

Where Credentials Are Stored

There are two storage layers to audit:

1. CC Switch’s application data, used to retain profiles.
2. The coding agent’s native configuration, written or updated when a profile is activated.

CC Switch uses local application storage rather than a hosted account service. The exact path is platform-dependent and has changed as the application has evolved, so derive it from the installed build instead of relying on a path copied from an old issue. Common OS application-data roots are:

macOS:   ~/Library/Application Support/
Windows: %APPDATA%
Linux:   ~/.local/share/ or an XDG data directory

Search without dumping credential contents:

find "$HOME/Library/Application Support" \
  -maxdepth 3 -iname '*cc*switch*' -print 2>/dev/null

find "${XDG_DATA_HOME:-$HOME/.local/share}" \
  -maxdepth 3 -iname '*cc*switch*' -print 2>/dev/null

For Claude Code, review ~/.claude/, especially settings.json, plus project-level Claude configuration where applicable. Other agents commonly use separate directories such as ~/.codex/ or ~/.gemini/, but filenames and credential formats are agent-version-specific.

Do not assume that “stored locally” means “encrypted.” Unless your installed CC Switch version explicitly uses an operating-system credential vault for the relevant secret, treat its application database and generated agent files as potentially plaintext-readable by your user account. Confirm with file inspection and repository code review, while taking care not to paste secrets into terminals, tickets, or chat sessions.

Security Implications of Desktop Token Access

CC Switch necessarily operates with the permissions of your desktop user. If that account can read a token, malware or another process running as the same user may also be able to read it. CC Switch does not eliminate endpoint security requirements.

The main risks are:

• Credential concentration: Multiple provider tokens may coexist in one local profile store.
• Configuration overwrite: Profile activation can replace or merge files used by an agent.
• Backup leakage: Application data and dotfiles may enter unencrypted backups.
• Process inheritance: Old terminals and running agents can retain previous credentials.
• MCP execution: A profile may activate commands with filesystem or network access.
• Supply-chain exposure: Installing updates gives new desktop code access to stored tokens.
• Screen and log disclosure: UI diagnostics or bug reports may reveal endpoint and credential data.

Use least-privilege controls around the utility:

chmod 700 ~/.claude
chmod 600 ~/.claude/settings.json

Prefer short-lived or revocable gateway tokens where the provider supports them. Never place a production administrative credential in a convenience profile. Rotate tokens after removing a machine from service; deleting a profile is not evidence that the credential was never copied elsewhere.

For enterprise deployment, I would require:

• Pinned, reviewed releases
• Full-disk encryption
• Restricted backup handling
• Provider-side spend limits and audit logs
• Separate tokens per developer and environment
• A documented revocation procedure
• Periodic review of MCP commands and exposed paths

CC Switch is a practical fit for local multi-provider workflows. It is not automatically a fit for environments where policy requires hardware-backed secrets, ephemeral credentials, or centrally enforced configuration. In those cases, a company gateway and secret-manager-backed launcher may be the more defensible design.

Practical Takeaways

• Use CC Switch when repeated manual edits are creating account, endpoint, or MCP mistakes.
• Confirm platform artifacts on the project’s current GitHub release before rollout.
• Give each profile a name that identifies its provider, owner, and environment.
• Restart Claude Code after switching because running processes may retain old values.
• Inspect the generated files and use claude mcp list to verify the effective state.
• Treat CC Switch’s local data and downstream agent configs as sensitive credential stores.
• Scope MCP servers as carefully as API tokens; they can execute commands and expose files.
• Pin releases, test configuration diffs, and maintain a token-revocation path.
• Keep high-impact production credentials out of desktop switching tools unless the surrounding controls explicitly support that risk.