fix(cli): respect SUPABASE_HOME across fallback paths#5624
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 09f5cd36b5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f2936f1b2a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // Golden path: --token persists the access token and reports success. The e2e | ||
| // harness sets SUPABASE_NO_KEYRING=1, so the token lands in the isolated | ||
| // HOME's ~/.supabase/access-token rather than the OS keyring. | ||
| // The Supabase home access-token file rather than the OS keyring. |
There was a problem hiding this comment.
Update the expected legacy token path
In this e2e helper, runSupabase sets SUPABASE_HOME to home.dir, and the changed credentials layer now writes the no-keyring fallback token directly to <SUPABASE_HOME>/access-token; this test still checks home.dir/.supabase/access-token below, so login --token succeeds but the assertion fails whenever the legacy no-keyring e2e runs. Update the assertion to the Supabase home path.
Useful? React with 👍 / 👎.
What changed
SUPABASE_HOMEhandling across Go fallback state, legacy TypeScript auth/profile/telemetry paths, next config state, the stack cache root, and shared binary paths.SUPABASE_HOMEas the global CLI state root in canonical docs, including telemetry/traces and the Go Deno binary path.Why
Some CLI fallback and cache paths still hard-coded
~/.supabase, soSUPABASE_HOMEdid not fully isolate local state in custom home-directory workflows.This intentionally fixes inconsistent behavior for the existing global CLI state root rather than adding a cache-only
SUPABASE_CACHEDIRvariable. Issue #5214 originally asks for a cache-directory override, so the variable choice is still reviewer/maintainer acceptance context for this PR.Closes #5214.