Skip to main content
The ccp CLI is the terminal surface. It manages profile records in ~/.ccp/profiles/, secrets in the macOS Keychain, and each profile’s isolated CLAUDE_CONFIG_DIR. ccp switch is the one command that needs the zsh wrapper sourced from your ~/.zshrc — a child process can’t mutate its parent shell’s environment. Every other command works from any shell.

​
ccp create <name> --type <type>

Create a new profile and complete its login flow.
Flags:
  • -t, --type <type> (required) — one of subscription, api_key, gateway, bedrock, vertex, foundry.
Profile names must match [a-z0-9-] and start with a letter or number, because they become file and directory names. The command prompts for whatever the auth type needs (OAuth browser flow, API key, gateway URL + token, or nothing for the cloud types). Secrets are masked on input. The profile’s CLAUDE_CONFIG_DIR (default ~/.claude-<name>) is created if it doesn’t exist.

​
ccp list

List every profile.
Each row shows: active marker (*), profile name, auth type, and CLAUDE_CONFIG_DIR. The active profile is whichever CCP_ACTIVE_PROFILE points to in the current shell.

​
ccp show <name>

Print the full profile record as JSON — name, auth type, gateway base URL (if any), CLAUDE_CONFIG_DIR, and Keychain account reference.
Secrets are never printed. There is no --reveal flag; if you need to inspect a secret directly, query the Keychain with security find-generic-password -s ccp-profile-manager -a <account-ref>.

​
ccp switch <name>

Switch the current shell to a profile — a full unset-then-apply of every routing variable Claude Code knows about.
This only actually changes your environment when the zsh wrapper (shell/ccp-init.zsh) is sourced from your ~/.zshrc. Without the wrapper, ccp switch prints the shell script that would be applied, but a child process can’t mutate the parent shell — the same reason nvm and pyenv ship shell functions. After a switch, CCP_ACTIVE_PROFILE is exported so prompts and scripts can display the active profile.

​
ccp doctor <name>

Preflight-check a profile before you rely on it mid-task.
Doctor checks are auth-type-aware:
  • subscription — presence and freshness of credentials.json in the profile’s config dir
  • api_key / gateway — the Keychain entry exists and is readable
  • bedrock — aws sso login session is active
  • vertex — gcloud ADC is reachable
  • foundry — az CLI session is active
Every check prints ✓ or ✗ with a short detail line. The command exits non-zero if any check fails.

​
ccp mcp-apply <name> <mcp-file>

Replace a profile’s user-scope MCP server set from a JSON file.
The file shape:
ccp mcp-apply writes to .claude.json inside the profile’s CLAUDE_CONFIG_DIR — the file Claude Code actually reads for user-scope MCP servers. It’s a full replace of the mcpServers block; everything else in .claude.json (onboarding state, project history) is preserved.

​
ccp export <name>

Print a profile’s shape as JSON, with no secrets and no machine-specific paths.
Flags:
  • -o, --out <file> — write to a file instead of stdout.
Exported files are safe to commit, share, or paste — they contain only the profile’s name, auth type, gateway base URL, and MCP server shape. Secrets and Keychain references are excluded by construction.

​
ccp import <file>

Import a profile shape produced by ccp export.
Import always re-collects credentials on the target machine: a fresh OAuth login for subscription profiles, a new key prompt for API-key profiles, a new bearer token for gateway profiles, or nothing for cloud profiles.

​
ccp delete <name>

Remove a profile record and its Keychain entry (if any).
The profile’s CLAUDE_CONFIG_DIR is left in place — session history and CLAUDE.md aren’t deleted with the record. Remove the directory manually if you want a clean slate.