[FEATURE] Support per-project organization switching for multiple Team plans

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When a user belongs to two different Team plan organizations, there’s no way to configure Claude Code to automatically use a specific organization per project. Currently, authentication is global (~/.claude/), so switching organizations in one terminal session affects all sessions.

Requested feature: Allow per-project organization binding, either through project-level settings.json configuration or environment variable support for OAuth-based Team plan auth.

Proposed Solution

I'd like to be able to configure per-project organization binding in .claude/settings.json or .claude/settings.local.json. For example:

{
"auth": {
"organizationId": "org_abc123"
}
}

When Claude Code starts in a project directory, it should read this setting and automatically authenticate with the specified organization, without affecting other running sessions.

Alternatively, an environment variable like CLAUDE_ORGANIZATION_ID could work, which would allow setting it per-project in JetBrains IDE run configurations or shell profiles.

The interface should show which organization is active in the status line (e.g., Sonnet 4 · Team: CompanyA) so users can quickly confirm they're using the correct plan.

Alternative Solutions

I've tried using multiple terminal windows with separate Claude Code sessions, each logged into a different Team plan. However, since auth state is stored globally in ~/.claude/, logging into one organization overwrites the other session's auth, making simultaneous use unreliable.

Currently I work around this by manually running /logout and /login every time I switch between projects for different organizations, which is time-consuming and error-prone.

Other tools solve this by supporting per-project configuration files or workspace-scoped auth tokens (e.g., npm's .npmrc with per-project registry auth, or git's per-repo credential helpers).

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

Use case: A freelance developer working on projects for two different companies, each with their own Team plan. They need to use the correct Team plan for each project simultaneously.

Step-by-step scenario:

1. Open WebStorm with Project A (Company A's Team plan) in one window
2. Open WebStorm with Project B (Company B's Team plan) in another window
3. Run claude in each project's integrated terminal
4. Expect each session to automatically use the correct organization based on project-level config
5. Work on both projects simultaneously without needing to /logout and /login when switching windows

Current behavior: Auth is global (~/.claude/), so logging into Org B overwrites Org A's session. Only one organization can be active at a time across all terminals.

Expected behavior: Each project directory maintains its own organization binding, allowing concurrent sessions with different Team plans.

Additional Context

• This is especially relevant for freelancers and contractors who belong to multiple Team plan organizations
• Similar per-project auth scoping exists in other developer tools:
• git: per-repo credential helpers via .gitconfig
• npm: per-project .npmrc with scoped registry auth
• AWS CLI: per-project profiles via AWS_PROFILE env var
• kubectl: per-project context via KUBECONFIG env var
• Related issue: #12740 (Claude Code connects to wrong organization with multiple accounts)
• A simple env var approach (e.g., CLAUDE_ORGANIZATION_ID) would also integrate well with JetBrains run configurations and direnv