fix(export): pair a long-lived Claude token with its profile home - #5
Merged
Merged
Conversation
`aas export` printed `CLAUDE_CODE_OAUTH_TOKEN` *instead of* `CLAUDE_CONFIG_DIR` for an account that carries a long-lived token, so `eval "$(aas export k-june@claude)"` left the shell authenticated as the account while `claude` wrote its history, settings and todos into `~/.claude`. The profile isolation quietly disappeared for exactly the accounts that use a long-lived token. The two answer different questions and both have to be answered. Claude Code takes a long-lived token only from the environment and prefers it over whatever the config dir holds, which is why `aas exec` has always installed both for the same account — and why the module's own summary is "the shell env needed to use a profile". `grok` already exported `GROK_HOME` and `XAI_API_KEY` together; `claude` was the one provider where the credential displaced the home. The variable list moves into `profile_env_vars`, a pure function over (provider, system, home, secret), so the pairing is covered by tests rather than by reading the match arms. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
aas exportprintedCLAUDE_CODE_OAUTH_TOKENinstead ofCLAUDE_CONFIG_DIRfor an account carrying a long-lived token — anelse if, not two pushes:So
eval "$(aas export k-june@claude)"left the shell authenticated as the account whileclaudewrote its history, settings and todos into~/.claude. Profile isolation quietly disappeared for exactly the accounts that use a long-lived token.Why both belong
They answer different questions — one says who you are, the other says where the session lives — and Claude Code takes a long-lived token only from the environment, preferring it over whatever the config dir holds. Three things already say so:
aas execinstalls both for the same account (exec.rstoken injection + profile home), and that is the path the long-lived flow is built on.grokalready exportsGROK_HOMEandXAI_API_KEYtogether.claudewas the one provider where the credential displaced the home.Change
The variable list moves into
profile_env_vars(key, system, home, secret), a pure function, so the pairing is covered by tests rather than by reading match arms. Four tests: long-lived + profile, long-lived + system profile, ordinary OAuth credential, and grok as the existing precedent.Behaviour for every other provider is unchanged.
🤖 Generated with Claude Code