[amitbardos]

Note

Description

Adds support for BASE44_ACCESS_TOKEN being set without BASE44_REFRESH_TOKEN. Previously that combination was ignored entirely — seeding no-opped and the CLI fell back to whatever login was in ~/.base44/auth/auth.json. Now the lone access token is held in memory for the current process and used as the bearer, which is what the MCP run_command tool needs when it injects a short-lived token into a shared app sandbox for a single command. The token is never written to disk, so the next command in that sandbox does not inherit the identity, and any pre-existing stored login is left untouched.

Related Issue

None

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Other (please describe):

Changes Made

• core/auth/config.ts: added a process-scoped envAccessTokenAuth holder. seedAuthFromEnv() now splits its validation — a token still requires sub/exp claims, but a missing refresh token no longer aborts seeding; instead it builds an in-memory AuthData (empty refreshToken, expiresAt from exp) rather than writing auth.json.
• readAuth() returns the in-memory env auth ahead of the stored file, so all downstream callers use the injected token with no other call-site changes.
• refreshAndSaveTokens() short-circuits to null when an env access token is active: there is nothing to refresh with, and auth.json belongs to a different identity, so it is never refreshed, rewritten, or deleted. On expiry the 401 simply surfaces.
• The paired BASE44_ACCESS_TOKEN + BASE44_REFRESH_TOKEN path is unchanged — it still writes a standard auth.json and participates in normal refresh/self-heal.
• docs/api-patterns.md: documented the lone-token path alongside the existing paired-credential behavior.
• tests/cli/env-token-auth.spec.ts: replaced the now-obsolete "incomplete env credentials are ignored" test with four cases — no auth.json is created from a lone token; the token is sent as the bearer while a stored login is left byte-identical; a 401 neither triggers a refresh call nor deletes the stored login; and a token missing sub/exp is still ignored in favor of the stored login.

Testing

• I have tested these changes locally
• I have added/updated tests as needed
• All tests pass (`npm test`)

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (if applicable)
• My changes generate no new warnings
• I have updated `docs/` (AGENTS.md) if I made architectural changes

Additional Notes

Behavior change worth calling out: when BASE44_ACCESS_TOKEN is set with valid sub/exp claims and no refresh token, it now takes precedence over an existing base44 login for the duration of the process. Before this PR the env var was ignored in that case. Precedence relative to BASE44_API_KEY (workspace keys) is unchanged.

---

_{🤖 Generated by Claude | 2026-10-25 15:40 UTC | 1d316b6}

[github-actions]

🚀 Package Preview Available!

---

Install this PR's preview build with npm:

npm i @base44-preview/cli@0.2.3-pr.681.1d316b6

Prefer not to change any import paths? Install using npm alias so your code still imports base44:

npm i "base44@npm:@base44-preview/cli@0.2.3-pr.681.1d316b6"

Or add it to your package.json dependencies:

{
  "dependencies": {
    "base44": "npm:@base44-preview/cli@0.2.3-pr.681.1d316b6"
  }
}

• 📦 Preview Package: @base44-preview/cli@0.2.3-pr.681.1d316b6
• 🔗 View this commit on GitHub

---

_{Preview published to npm registry — try new features instantly!}