e2e tests that spawn a real `os serve` under vitest inherit `TEST=true`, which makes better-auth silently skip origin/CSRF validation regardless of `NODE_ENV`

[os-elon]

The gap

Found while writing the regression pin for #11113. Any packages/cli e2e test that
spawns a real os serve child process and constructs its env with
{ ...process.env, ... } — including the shared helper
packages/cli/test/helpers/serve-process.ts's runServe() — carries the vitest
worker's own environment into the child. Vitest sets TEST=true on its worker
process unconditionally, independent of NODE_ENV.

better-auth 1.7.1 reads TEST directly:

// @better-auth/core/env (env-impl.mjs)
const isTest = () => nodeENV === 'test' || toBoolean(env.TEST);

// better-auth/dist/context/create-context.mjs
skipOriginCheck: options.advanced?.disableOriginCheck !== void 0
 ? options.advanced.disableOriginCheck
 : isTest() ? true : false,

So a spawned os serve child that inherits TEST=true has better-auth's own
origin/CSRF validation disabled entirely — independent of what NODE_ENV the
test explicitly sets on the child, and independent of anything plugin-auth's own
trustedOrigins computation does. A test asserting a "closed" security posture
(origin rejected, CSRF enforced) against such a child cannot fail no matter what the
code under test does: the assertion is vacuously satisfied by better-auth's own
test-mode skip, one layer below anything serve.ts or plugin-auth control.

Measured

packages/cli/test/serve-node-env-production-default.e2e.test.ts (#11113) hit this
directly: a boot-real-server-and-probe-the-origin-check pin passed identically with
the fix applied and with the fix reverted, until the child's env explicitly unset
TEST (the same way it already had to unset NODE_ENV). Full repro in that PR's
description and the pin file's own header comment.

Why this is worth its own card

• It is not local to the one test above — runServe() in
  packages/cli/test/helpers/serve-process.ts spreads ...process.env the same
  way, so every e2e file that imports it inherits the same leak. None of today's
  users of that helper appear to assert origin/CSRF-sensitive behavior (checked
  the ones grepped while writing this card), so the gap is currently latent rather
  than an active false-green — but it is silent and structural, not something a
  future author would have any reason to suspect.
• The failure mode is the dangerous direction: a security-posture assertion that
  can never go red for the reason it's supposed to test is worse than no
  assertion, because it reads as coverage.

Not claimed

I did not audit every e2e test that spawns a real CLI process for whether it
happens to touch auth/CSRF-sensitive behavior today, and I did not assess whether
VITEST=true (also inherited) has a similar effect anywhere else in the
dependency tree — that survey is the bulk of the work and belongs to whoever
takes this.

Options, not recommended here

1. Strip TEST (and maybe VITEST, VITEST_WORKER_ID, VITEST_POOL_ID,
   VITEST_MODE) in runServe()'s own env construction, once, so every current
   and future caller is covered without having to know the trap exists.
2. Document the trap at runServe()'s call site and leave each e2e author to
   handle it themselves (what Dev-only gates spelled NODE_ENV !== 'production' still open in a real production deployment that never sets NODE_ENV (os serve does not force it, os start does) #11113's pin does, since it doesn't use
   runServe()).
3. Leave it — the gap is latent today per the measurement above.

Related: #11113 (where this was found and worked around locally, not fixed
repo-wide).

[os-zhuang]

Triage: lands in packages/cli/test/helpers/serve-process.ts (runServe() env construction) ⇒ domain:cli, type Task, → pm:queue.

Scope as queued = option 1: strip the vitest-worker env family (TEST, VITEST, VITEST_WORKER_ID, VITEST_POOL_ID, VITEST_MODE) once in runServe()'s own env construction, so every current and future caller is covered without knowing the trap; document the trap in the helper's header. The rationale is the invariant this restores: a security-posture assertion against a spawned os serve must be able to go red — better-auth 1.7.1's isTest() reads TEST directly and disables origin/CSRF checking one layer below anything the code under test controls (measured in #11113's pin: passed identically with the fix reverted until the child env unset TEST).

In-card verification, not a separate survey card: after stripping, grep the e2e files that import runServe() and confirm none relied on inherited test-mode behavior (the card's own check found none asserting origin/CSRF today, so expect zero behavior change; if one goes red, that red is the finding). The broader "does VITEST=true have a similar effect elsewhere in the dependency tree" survey is out of scope here — file what surfaces as findings.

Serial note: #11113 is in-flight (pm:dispatched, cli lane) and its pin file handles this locally without runServe() — file surfaces don't intersect, but the cli seat should land this after #11113 so the pin's local workaround and the helper fix don't cross. Size/model suggestion: S–M mechanical, sonnet/opus.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 31

• Session: session_019siH5jDmk5hrayvfyojUqR (domain:cli lane execution seat, post [PM seat] domain:cli — 🟢 os-zhuang (session_019siH5jDmk5hrayvfyojUqR) · R32 · 落地 15 卡 / 13 PR · 在飞 4 · 待复审 1 · 待人工合并 1 · 决策箱 2 #6024)
• Branch: claude/issue-11267-vitest-test-env-leak
• Worktree: objectstack-issue-11267
• Domain: domain:cli
• File surface: packages/cli/test/helpers/serve-process.ts and the e2e tests that spawn a real os serve while spreading ...process.env (stop on breach; explain in the report)
• Container & model: M, mode:subagent, model: opus
• Clause-②: no — test-harness environment hygiene. No product behaviour changes, no contract accept/reject moves, no public surface widens. ⚠️ Re-derive on the actual diff: if closing this needs a change in plugin-auth or better-auth wiring rather than in the test harness, that flips the answer — stop and report.
• Serial constraints cleared: packages/cli/test/** was HELD by fix(cli): os serve defaults NODE_ENV to production when unset #11268 for this entire round. fix(cli): os serve defaults NODE_ENV to production when unset #11268 merged at 918988ad, so the hold is released and this card is dispatchable for the first time.

Premise re-verified on the merged ref — ⛔ not assumed from the card

#11268 landed minutes ago into this card's exact surface, so the card's framing had to be re-checked rather than trusted. Measured at origin/main after the merge:

reading	value
packages/cli/test/helpers/serve-process.ts:60	still ...process.env,
TEST handling in that helper	none — the spread is unguarded
importers of the helper	8 files under packages/cli/test/
did #11268 touch the helper?	no — its five files were the changeset, serve.ts, its own new pin, vitest.config.ts, turbo.json

⇒ Premise intact, and the blast radius is now a measured 8 importing test files, not an estimate.

What #11268 already established, so it is not re-derived here

This card was filed by #11268's own dev while building the pin that hit it. That PR's regression pin already unsets TEST for its spawned child and documents the mechanism inline: better-auth 1.7.1 reads TEST directly (@better-auth/core/env's isTest = () => nodeENV === 'test' || toBoolean(env.TEST)), and create-context.mjs defaults skipOriginCheck: isTest() ? true : false — independent of NODE_ENV. A child inheriting TEST=true has origin validation disabled by better-auth itself.

⇒ The mechanism is settled. This card is the repo-wide fix that PR deliberately scoped out.

⚠️ Two live cautions from this round, both measured

1. packages/cli e2e tests that spawn bin/run.js as "the SHIPPED entrypoint" never reach dist/ — oclif's ts-path reroutes them to src/ under NODE_ENV=test|development #11317 (filed today) records that three of packages/cli's "SHIPPED entrypoint" e2e tests set NODE_ENV: 'development' in the child env, which enables oclif's tsPath() reroute — so they resolve through src/, not dist/. ⛔ Do not assume every spawner in this directory is exercising the built CLI; check each one you touch, and ⛔ do not fix packages/cli e2e tests that spawn bin/run.js as "the SHIPPED entrypoint" never reach dist/ — oclif's ts-path reroutes them to src/ under NODE_ENV=test|development #11317 here.
2. @objectstack/cli#test now declares dependsOn: ["build"] (landed with fix(cli): os serve defaults NODE_ENV to production when unset #11268). A test in this package that reaches dist/ is now genuinely built first — which is new, and changes what a local run reproduces versus what CI does.

The trap this card is shaped around

⛔ A test that stops leaking TEST must be shown to have been measuring nothing before. Unsetting the variable is trivial; proving it mattered is the work. For any test whose assertions depend on auth/CSRF behaviour, demonstrate the assertion was vacuous with the leak in place — otherwise the fix is unfalsifiable and this card cannot tell a real repair from a no-op.

⚠️ Expect some importers not to care: a spawner that never exercises auth is unaffected by TEST and needs the hygiene fix without a behaviour claim. Say which is which rather than asserting a uniform improvement across all 8.

Required of the report

Machine-checkable fields only: gates, deviations, files_changed, plus a per-file table (leaked / fixed / unaffected-and-why) across the 8 importers. ⛔ Do not restate the PR body. Re-derive gate families with node scripts/pm/dispatch-gates.mjs at your final head; re-run the changeset gates after committing (they diff HEAD, and an untracked changeset yields a green that measured nothing — measured twice in this lane today).

---

Generated by Claude Code