fix: getCliClient() token not passed through

[rexxars]

Description

sanity exec --with-user-token was not passing the token to the client returned by getCliClient().

The old approach used a configClient.worker.ts that was loaded via --import in the child process. The worker imported getCliClient via a relative path and mutated its __internal__getToken property. But the user's script imports getCliClient from sanity/cli, which re-exports from @sanity/cli through package exports. These two import paths can resolve to different module instances (e.g. src/ vs dist/ during development, or duplicate packages in node_modules), so the mutation never reaches the instance the script uses.

The fix resolves the token in the parent process and passes it to the child via the SANITY_AUTH_TOKEN environment variable. getCliClient() now falls back to that env var when __internal__getToken returns nothing.

What to review

• execScript.ts - Token resolution moved from the child process worker to the parent. Throws CLIError (no stack trace) if no token is found.
• cliClient.ts - One-line change: getCliClient() falls back to process.env.SANITY_AUTH_TOKEN.
• configClient.worker.ts - Deleted, no longer referenced.
• exec-with-user-token.test.ts - New test file (separate from exec.test.ts to avoid getCliToken cache ordering issues). Tests both the error path and the token-passing path.
• exec-get-user-token.ts - Test fixture script that verifies the token reaches the client config.

Testing

Two new tests in exec-with-user-token.test.ts:

• Error case: --with-user-token with no configured token throws CLIError with actionable message
• Success case: Token from CLI config reaches getCliClient() in the spawned script (uses a fake token, no real API call needed)

[claude]

Claude finished @rexxars's task in 3m 16s —— View job

---

Review

Two issues to consider:

---

1. Test order fragility in exec-with-user-token.test.ts

getCliToken() has a module-level cache (let cachedToken). Within the same test file, the error test works correctly only because it runs first (before any token is cached). If the success test runs first, it sets cachedToken = 'test-fake-token-abc123', and the error test would then return that cached token instead of throwing.

The comment at the top of the file explains the cross-file isolation rationale, but the intra-file ordering dependency is still fragile. Consider resetting the module between tests:

beforeEach(() => {
  vi.resetModules() // clears getCliToken's cachedToken
})

Or reorder so the success test (which sets the cache) always runs last — which it currently does, but relies on implicit ordering.

exec-with-user-token.test.ts lines 67–96

---

2. exec.test.ts line 106: SANITY_AUTH_TOKEN not cleared before --with-user-token test

getCliToken() checks SANITY_AUTH_TOKEN before reading from the config file. The new exec-with-user-token.test.ts correctly stubs it to '' in setupTestAuth. The existing test at line 106 in exec.test.ts does not, meaning if SANITY_AUTH_TOKEN is set in CI (different from SANITY_API_TOKEN), the config-file token written by setupTestAuth(TEST_TOKEN) is silently bypassed and the test uses the env token instead.

The fix from the new test file should be applied here too:

vi.stubEnv('SANITY_AUTH_TOKEN', '') // add to setupTestAuth in exec.test.ts

exec.test.ts line 41–51

---

The core logic changes in execScript.ts and cliClient.ts are correct and clean.

[github-actions]

Coverage Delta

File	Statements
packages/@sanity/cli/src/actions/exec/execScript.ts	75.6% (+ 2.6%)
packages/@sanity/cli/src/util/cliClient.ts	100.0% (±0%)

Comparing 2 changed files against main @ aee2e6e8395e0584b7233fe37b41dba954fff7e0

Overall Coverage

Metric	Coverage
Statements	81.8% (+ 0.1%)
Branches	70.6% (+ 0.1%)
Functions	80.0% (+ 0.1%)
Lines	82.2% (+ 0.1%)