Skip to content

Environment variables had to be unset to recognize correct plan #4187

Closed as not planned
Closed as not planned
Environment variables had to be unset to recognize correct plan#4187
Labels
area:autharea:modelautocloseIssue will be closed automaticallybugSomething isn't workinghas reproHas detailed reproduction stepsplatform:macosIssue specifically occurs on macOS

Description

@mikedotexe
mikedotexe
opened on Jul 23, 2025

[Original] Bug Description
Darn, I've tried quite a bit, but cannot get my MAX plan to use Opus 4. Claude Code believes I have a Pro account instead. I tried logging out, logging in, claude setup-token, checking my env vars, echoing them. I think there's a bug here, friends. Great work, this thing is amazing

Extended thoughts

UPDATE: so I was able to get it to recognize the MAX plan, and think I have some useful information I'll share while it's in my head.

I'll explain this how I'm imagining it after several attempts, and present it as such. I'll admit I don't know this codebase, but maybe it'll help anway.

So there seems to be two ways I was trying to accomplish this, and perhaps this is why I encountered this "bug" that I now believe to be partially (or perhaps fully) my fault.

First (setup-token CLI command)

On my terminal, I have run claude setup-token, which finishes by displaying the CLAUDE_CODE_OAUTH_TOKEN with instructions. So in my bash file (for me ~/.zshrc) I added:

export CLAUDE_CODE_OAUTH_TOKEN=sk-ant-…

And along the way in my journey, I also had two other environment variables in there:

  • CLAUDE_CODE_MAX_OUTPUT_TOKENS
  • ANTHROPIC_MODEL

Second (/login command)

After running claude and entering the interactive mode, there is a slash command /login that seems to do similar work as the CLI's setup-token except it doesn't print the OAuth token, it just tells you it's finished.

My solution

I was trying /logout and /login and it seems that the CLI setup-token command might have interfered with what I should have stuck to, which is the /login interactive command.

The silly mistake I made was to comment out the Anthropic-related env vars, and source my bash file. But I forgot to unset the env vars, so I could still echo $CLAUDE_CODE_OAUTH_TOKEN and see it. After running:

unset CLAUDE_CODE_OAUTH_TOKEN
unset CLAUDE_CODE_MAX_OUTPUT_TOKENS
unset ANTHROPIC_MODEL

I was able to use /login and when I ran the /status command, confirmed that it had successfully recognized my plan.

Potential leads to fix

First, this may be an obscure problem I ran into. It might also be some low-hanging fruit if there's some logic in here that checks environment variable values and compares them against incorrect account plan information. So perhaps there's more being done while validating env vars than should be.

Another potential consideration is whether we want to have two avenues for linking your account. It seems reasonable to consider removing the CLI setup-token command, or deprecate it with a message saying, "Run claude and use the /login command to connect your account, please. Friendly deprecation notice."

Assets

Image

Environment Info

  • Platform: darwin
  • Terminal: iTerm.app
  • Version: 1.0.58
  • Feedback ID:

Errors

[{"error":"Error: Command failed: security find-generic-password -a $USER -w -s \"Claude Code\"\nsecurity: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.\n\n    at genericNodeError (node:child_process:959:22)\n    at checkExecSyncError (node:child_process:458:27)\n    at execSync (node:child_process:278:31)\n    at eY (/$bunfs/root/claude:687:5945)\n    at <anonymous> (/$bunfs/root/claude:583:5727)\n    at W (/$bunfs/root/claude:435:14413)\n    at f3 (/$bunfs/root/claude:583:3474)\n    at xK (/$bunfs/root/claude:583:2341)\n    at X2 (/$bunfs/root/claude:583:8262)\n    at sHZ (/$bunfs/root/claude:583:8420)","timestamp":"2025-07-23T04:25:24.599Z"},{"error":"Error: Command failed: security delete-generic-password -a $USER -s \"Claude Code\"\nsecurity: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.\n\n    at genericNodeError (node:child_process:959:22)\n    at checkExecSyncError (node:child_process:458:27)\n    at execSync (node:child_process:278:31)\n    at eY (/$bunfs/root/claude:687:5945)\n    at aHZ (/$bunfs/root/claude:583:6754)\n    at rHZ (/$bunfs/root/claude:583:6660)\n    at bB1 (/$bunfs/root/claude:1752:2567)\n    at startOAuthFlow (/$bunfs/root/claude:1752:3766)\n    at processTicksAndRejections (native:7:39)","timestamp":"2025-07-23T04:25:41.963Z"},{"error":"Error: Command failed: security find-generic-password -a $USER -w -s \"Claude Code\"\nsecurity: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.\n\n    at genericNodeError (node:child_process:959:22)\n    at checkExecSyncError (node:child_process:458:27)\n    at execSync (node:child_process:278:31)\n    at eY (/$bunfs/root/claude:687:5945)\n    at <anonymous> (/$bunfs/root/claude:583:5727)\n    at W (/$bunfs/root/claude:435:14413)\n    at f3 (/$bunfs/root/claude:583:3474)\n    at xK (/$bunfs/root/claude:583:2341)\n    at X2 (/$bunfs/root/claude:583:8262)\n    at tu (/$bunfs/root/claude:599:5583)","timestamp":"2025-07-23T04:25:42.014Z"},{"error":"Error\n    at Hq (/$bunfs/root/claude:466:1076)\n    at B1 (/$bunfs/root/claude:467:9963)\n    at emit (node:events:92:22)\n    at endReadableNT (internal:streams/readable:862:50)\n    at processTicksAndRejections (native:7:39)\n    at request (/$bunfs/root/claude:469:2098)\n    at processTicksAndRejections (native:7:39)","timestamp":"2025-07-23T04:27:06.651Z"}]

Activity

  1. github-actions
    added
    bugSomething isn't working
    has reproHas detailed reproduction steps
    platform:macosIssue specifically occurs on macOS
    area:auth
    area:model
    on Jul 23, 2025
  2. mikedotexe
    changed the title [-]Incorrect Account Plan Detection for Opus 4 Model Access[/-] [+]Environment variables had to be `unset` to recognize correct plan[/+] on Jul 23, 2025

  3. mikedotexe commented on Jul 23, 2025

    @mikedotexe
    mikedotexe
    on Jul 23, 2025
    Author

    Thought Claude Code binary might be open source, but tried a little investigation. Summary from Opus 4:

    Claude Code Authentication Bug - Technical Investigation Summary

    After experiencing the authentication bug where Claude Code incorrectly identified my MAX plan as a Pro account, I conducted a thorough investigation to help the Anthropic team locate and fix this issue. Here's what I found:

    Bug Summary

    • Issue: Claude Code incorrectly validates MAX plan accounts as Pro accounts when environment variables are set
    • Root Cause: Environment variable persistence interfering with authentication flow
    • Affected Variables: CLAUDE_CODE_OAUTH_TOKEN, CLAUDE_CODE_MAX_OUTPUT_TOKENS, ANTHROPIC_MODEL

    Investigation Findings

    1. Analysis of Claude Code Package Structure

    I analyzed the npm package (@anthropic-ai/claude-code v1.0.58) and found:

    📦 Package Contents:
📄 cli.js (8.33 MB - minified/bundled)
📄 sdk.mjs (9.40 KB)
📄 sdk.d.ts (3.37 KB)
📁 vendor/ (contains ripgrep binaries and IDE plugins)

    2. Authentication Patterns Found in cli.js

    Using pattern matching on the minified code, I discovered:

    • 11 occurrences of CLAUDE_CODE_OAUTH_TOKEN
    • 13 occurrences of setup-token
    • 16 occurrences of /login command references
    • 151 occurrences of environment variable access patterns (process.env.CLAUDE_CODE_* / process.env.ANTHROPIC_*)
    • 3 occurrences of Pro/Max plan validation logic
    • 1 occurrence of keychain access code

    3. Error Context from Logs

    The authentication flow encounters macOS keychain errors:

    Error: Command failed: security find-generic-password -a $USER -w -s "Claude Code"
security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.

    This suggests Claude Code uses the macOS keychain for credential storage, but the authentication flow fails when environment variables interfere.

    4. Two Authentication Methods Identified

    The investigation revealed Claude Code has two distinct authentication paths:

    1. CLI method: claude setup-token - Sets authentication via environment variable
    2. Interactive method: /login command within Claude Code - Sets authentication internally

    These two methods can conflict when environment variables persist in the shell session.

    Technical Leads for Anthropic Team

    1. Environment Variable Validation Logic

    The bug appears to be in the code that validates environment variables against account plan information. When CLAUDE_CODE_OAUTH_TOKEN is set via environment variable, it seems to bypass or incorrectly validate the account plan type.

    Search for: Code that checks environment variables and validates them against account plan data. Look for logic that might default to "Pro" when plan validation fails.

    2. Authentication Flow Priority

    The /login command should likely take precedence over environment variables, but currently environment variables seem to override or interfere with the interactive login flow.

    Recommendation: Consider implementing a clear hierarchy where /login authentication supersedes environment variables, or provide warnings when both are present.

    3. Plan Validation Endpoint

    The error message mentioning "Claude Opus 4 is not available with the Claude Pro plan" suggests there's plan validation happening. This validation might be using cached or incorrect plan data when environment variables are present.

    Search for: API calls or validation logic that determines user plan type, especially when environment variables are set.

    4. Keychain Integration

    The keychain errors suggest the authentication system tries to read from macOS keychain even when environment variables are set, creating a conflict.

    Recommendation: Review the keychain access logic to ensure it properly handles cases where environment variables are present.

    Reproduction Steps for Internal Testing

    1. Set environment variables in shell config:

      export CLAUDE_CODE_OAUTH_TOKEN="<token>"
export CLAUDE_CODE_MAX_OUTPUT_TOKENS="200000"
export ANTHROPIC_MODEL="claude-3-5-sonnet-20241022"

    2. Source the shell config and start Claude Code

    3. Attempt to use /login command

    4. Observe that even after successful login, the system may incorrectly identify the account plan

    Suggested Fixes

    1. Deprecation Option: Consider deprecating setup-token in favor of /login to avoid confusion
    2. Clear Environment Variables: Add logic to clear or warn about existing environment variables when using /login
    3. Improve Error Messages: Provide clearer error messages when authentication conflicts occur
    4. Plan Validation Fix: Ensure plan validation uses fresh data from the API rather than cached or assumed values

    Additional Notes

    • The issue is specifically in the Claude Code CLI binary (cli.js), not in the @anthropic-sdk-typescript package
    • The bug manifests even after commenting out environment variables in shell config because they persist in the session
    • Users must explicitly unset the variables to resolve the issue

    I hope this investigation helps locate and fix the bug. The key insight is that environment variable persistence creates an authentication state conflict that the current validation logic doesn't handle correctly.

  4. randallb commented on Jul 26, 2025

    @randallb
    randallb
    on Jul 26, 2025

    I also have this issue, fwiw.

  5. scald commented on Aug 12, 2025

    @scald
    scald
    on Aug 12, 2025

    same issue, reported in #5625 and closed dupe

  6. github-actions commented on Dec 3, 2025

    @github-actions
    github-actionsbot
    on Dec 3, 2025 – with GitHub Actions

    This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

  7. github-actions
    added
    autocloseIssue will be closed automatically
    on Dec 3, 2025

  8. github-actions commented on Jan 3, 2026

    @github-actions
    github-actionsbot
    on Jan 3, 2026 – with GitHub Actions

    This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.

  9. github-actions
    closed this as not plannedon Jan 3, 2026

  10. github-actions commented on Jan 10, 2026

    @github-actions
    github-actionsbot
    on Jan 10, 2026 – with GitHub Actions

    This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

  11. github-actions
    locked as resolved and limited conversation to collaborators on Jan 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:autharea:modelautocloseIssue will be closed automaticallybugSomething isn't workinghas reproHas detailed reproduction stepsplatform:macosIssue specifically occurs on macOS

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions