하나의 컴퓨터에서 여러 계정을 사용하는 Claude Code

If you want two Claude Code entry points, one for your normal Claude Team or Enterprise login and one for an alternative API provider like z.ai, the cleanest answer is not two installs. Tested with Claude Code 2.1.72. What you actually want is one Claude install, one neutral global config, and two explicit commands: claude-team for your normal first-party Claude loginclaude-zai for the z.ai gateway using a token sourced outside Claude settings The names are arbitrary. You could call them claude-default and claude-zai if you prefer. The important part is the pattern: use one Claude install and one global Claude config, and select the provider with wrapper scripts instead of swapping config files or maintaining a second install. If you want to try z.ai itself, here is the same referral link I used before: Get GLM Coding Plan. Most of the confusion around this topic comes from the fact that Claude Code has two different layers of state. Your saved first-party login lives separately from settings.json , but global env overrides still affect every session. That sounds harmless until you realise it means you can be correctly logged into your normal Claude account and still accidentally route every request through z.ai if you set gateway variables globally. # The mistake to avoid If you put this in ~/.claude/settings.json : { "env": { "ANTHROPIC_AUTH_TOKEN": "...", "ANTHROPIC_BASE_URL": "https://api.z.ai/api/anthropic" } } then every Claude session goes through that gateway. You have effectively made z.ai the default for every Claude Code session on that machine. That is the trap most people hit. The clean fix is: - keep ~/.claude/settings.json provider-neutral - source the z.ai token outside Claude settings - use claude-team when you want the normal Claude path - use claude-zai when you want the z.ai path # What to build instead This is the target end state: ~/.claude/settings.json is provider-neutral- z.ai token is sourced outside Claude settings claude-team andclaude-zai live in~/bin - no repo-local Claude config is required - no ~/claude-zhipu install is required - no legacy claude-zhipu wrapper is required If you keep shell tools in dotfiles, the wrappers can live there and be symlinked into ~/bin . Example: ~/dev/dotfiles/claude/.claude/settings.json ~/dev/dotfiles/bin/bin/claude-team ~/dev/dotfiles/bin/bin/claude-zai Before changing anything, make sure Claude Code is installed and reachable as claude , and that ~/bin is on your PATH . claude --version echo $PATH | tr ':' '\n' | grep -x "$HOME/bin" # Where the z.ai token should live The key rule is simple: do not put the token in ~/.claude/settings.json . You have a few reasonable options: pass , if you already use password-store- a local secret file such as ~/.config/claude/zai-token - an environment variable such as CLAUDE_ZAI_TOKEN pass is the most security-conscious option in this guide, but it is not required. If you want to use pass , this guide uses: pass show api/zhipu If you do not have one yet: pass insert api/zhipu The broader point is simple: Claude settings should stay clean, and the z.ai credential should only be injected when you intentionally choose the z.ai path. # Keep global Claude settings boring Your global Claude settings should keep only normal defaults such as status line, plugins, model preference, and harmless flags. Example: { "$schema": "https://json.schemastore.org/claude-code-settings.json", "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" }, "model": "opus", "statusLine": { "type": "command", "command": "input=$(cat); current_dir=$(echo \"$input\" | jq -r '.workspace.current_dir // .cwd'); model=$(echo \"$input\" | jq -r '.model.display_name'); dir_name=$(basename \"$current_dir\"); printf \"%s %s\" \"$dir_name\" \"$model\"" } } Once global settings are neutral, the rest of the setup becomes straightforward. You create one wrapper that clears provider-specific overrides and one wrapper that opts into the z.ai gateway. # The normal path: claude-team This wrapper clears provider-specific env vars and launches the normal Claude binary. #!/usr/bin/env bash set -euo pipefail unset ANTHROPIC_API_KEY unset ANTHROPIC_AUTH_TOKEN unset ANTHROPIC_BASE_URL unset ANTHROPIC_DEFAULT_HAIKU_MODEL unset ANTHROPIC_DEFAULT_SONNET_MODEL unset ANTHROPIC_DEFAULT_OPUS_MODEL unset ANTHROPIC_MODEL unset API_TIMEOUT_MS unset CLAUDE_CONFIG_DIR exec claude "$@" Save it as: ~/bin/claude-team chmod +x ~/bin/claude-team The entire purpose of this wrapper is to make sure an old API key, gateway URL, or model mapping does not bleed into the first-party Claude path. # The z.ai path: claude-zai This wrapper resolves the token from an env var, a local token file, or pass , then points Claude at the z.ai gateway and sets the model mapping env vars. #!/usr/bin/env bash set -euo pipefail PASS_ENTRY="${CLAUDE_ZAI_PASS_ENTRY:-api/zhipu}" TOKEN_FILE="${CLAUDE_ZAI_TOKEN_FILE:-$HOME/.config/claude/zai-token}" if [[ -n "${CLAUDE_ZAI_TOKEN:-}" ]]; then ZAI_TOKEN="$CLAUD