[BUG] OAuth credentials shared across CLAUDE_CONFIG_DIR profiles causing data isolation failure (compliance risk)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code uses the same macOS Keychain service name (Claude Code-credentials) for all profiles, regardless of CLAUDE_CONFIG_DIR setting. This causes OAuth token conflicts when using multiple accounts.

When two profiles with different OAuth accounts are used:

• Profile A logs in → stores tokens in Claude Code-credentials
• Profile B logs in → overwrites the same entry with different account's tokens
• Profile A tries to refresh → uses Profile B's refresh token → fails (wrong account)

Both profiles eventually require re-login

What Should Happen?

Keychain entries should be namespaced by config directory or account UUID to allow multiple OAuth accounts to coexist:

Claude Code-credentials-{md5(CLAUDE_CONFIG_DIR)[:8]}
# or
Claude Code-credentials-{accountUuid[:8]}

Why profile separation matters (business/security case):

• Work profile: Access to company systems, customer PII, proprietary code, strategic documents - subject to enterprise data retention and compliance policies
• Personal profile: Access to personal health information, family data, private projects - should not flow through work-governed systems

This is a compliance issue, not just an inconvenience. When OAuth tokens collide, users cannot guarantee which account processed which data. Personal health information or family data may inadvertently flow through a work account subject to enterprise audit/retention, or vice versa. For users handling sensitive data under GDPR, HIPAA, or SOC2 requirements, this lack of isolation creates real compliance risk.

Error Messages/Logs

When one profile's tokens are overwritten by another:

2026-01-22T23:50:57.658Z [ERROR] e3T: e3T: Invalid refresh token
2026-01-23T00:10:02.518Z [ERROR] e3T: e3T: Invalid refresh token


Followed by token expiration:

2026-01-23T22:40:06.814Z [ERROR] Error: 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth token has expired. Please obtain a new token or refresh your existing token."}}

Steps to Reproduce

1. Set up two profiles with different CLAUDE_CONFIG_DIR values pointing to different directories
2. Login to Profile A with OAuth Account A (/login)
3. Login to Profile B with OAuth Account B (/login)
4. Use Profile A for a few hours
5. Observe "Invalid refresh token" errors in debug logs (~/.claude-work/debug/)
6. Eventually both profiles require /login again (~8 hours)

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.19

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Related Issues:

• #19456 - OAuth token refresh fails due to Keychain permission errors (my earlier report - the ACL issue is separate but compounds this problem)
• #15670 - CLAUDE_CONFIG_DIR doesn't completely isolate installations (same class of isolation bugs)
• #16103 - Cannot resume sessions when using CLAUDE_CONFIG_DIR
• #3833 - CLAUDE_CONFIG_DIR behavior unclear

Workaround:
Use API key authentication for one profile to avoid OAuth collision:

aclaude() {
    export ANTHROPIC_API_KEY=$(cat ~/.secrets/anthropic-api-key)
    CLAUDE_CONFIG_DIR=~/.claude-work command claude "$@"
    unset ANTHROPIC_API_KEY
}

This is not a viable workaround for me though as we have an Enterprise subscription to Claude Code and I have a Claude Code subscription. API key access just significantly increases cost/wastage.

Claude Code-credentials                   ← legacy global entry
Claude Code-credentials-85be987d          ← sha256("<repo-a>/.claude-config")[:8]
Claude Code-credentials-806dff44          ← sha256("<repo-b>/.claude-config")[:8]

entry 1 (decrypt/read):
    applications (1): /usr/bin/security        ← only Apple's security CLI

entry 3 (partition_id):
    description: apple-tool:                    ← only Apple-signed binaries