live smokes call down on an unenforced sandbox assumption: a broken sandbox tears down the operator's mesh and still reports a pass

[davidfarah2003]

Nine live smokes call a down path. All of them sandbox correctly. None of them verifies the
sandbox actually held before running the destructive verb, and that gap is the whole issue: a
sandbox that silently fails to apply turns cotal down into a teardown of whatever mesh the
ambient registry happens to point at, while the suite still reports a pass.

The current shape is good, which is what makes the gap easy to miss

The guard is real, not a naming convention. dogfood-live.smoke.ts builds

const env = { ...process.env, XDG_CONFIG_HOME: configDir, COTAL_HOME: home };
const cotalAt = (cwd: string, args: string[], timeout = 180_000) => …

and runs every CLI call with cwd: root under a temp root. orca-extension-live.smoke.ts does the
same. Env and cwd, both set. On a correctly-constructed run there is no path from these suites to
an operator's mesh.

The problem is that nothing checks. If the temp root is missing, if a helper is called before the
sandbox is built, if a refactor drops env from one spawnSync among many, or if a future wrapper
overwrites COTAL_HOME, then cotal down resolves the real registry. And down's own behaviour
at that point is documented and total, in implementations/cli/src/commands/down.ts:95:

bare cotal down always stops this folder's stack

So the failure is: destructive, silent, and green. The suite tears the operator's stack down, its
own assertions still pass because the CLI did what it was asked, and nothing in the output
distinguishes "torn down my sandbox" from "torn down your fleet".

Affected files

backup-faults-live, backup-conservation-live, backup-usermode-live, backup-restore-live,
ext-live, dogfood-live, orca-extension-live, up-tls-routes-live, up-stack-live.

Grepping each for anything resembling a pre-down mesh assertion: four have zero,
three have one incidental match, one has two, and only up-tls-routes-live has a meaningful
count. So this is not one careless file, it is an unstated assumption nine files share.

Suggested fix: one shared helper, not nine edits

A single guard that resolves the mesh the CLI would act on and refuses unless it is the sandbox's
own, called before any down in a live smoke. Something with the shape of:

assertSandboxMesh(env, root);   // throws naming the resolved root vs the expected one

Nine separate edits would leave the tenth suite, written next month, unguarded. The point is that
the assumption becomes enforced in one place rather than remembered in nine.

The same reasoning applies to any harness outside this repo that drives the installed CLI and calls
down on a teardown path: the guard belongs with the destructive call, not with the convention
that is supposed to keep it away.

Related: the one-word blast-radius difference

Worth considering in the same change, because it is the same root: a destructive verb whose scope
is not confirmed before it acts. cotal down and cotal down manager differ by one word and by
their entire blast radius: the first stops broker, manager, delivery daemon and web dashboard, the
second stops the manager alone. --dry-run is the only preview and it is opt-in.

down.ts already knows the difference and explains it clearly in an error message for a different
mistake (--space with no components). The bare form gets no such narration.

Measured, since it prompted this: a scoped cotal down manager on a live fleet is a cheap re-seat;
broker, JetStream, delivery daemon and channel registry all survive. The bare form on the same
folder is a full outage. Nothing at the call site marks that difference, in the smokes or at an
operator's prompt.

Why this is worth fixing rather than noting

A destructive command that is correctly scoped by an unenforced assumption is indistinguishable, in
every log it produces, from one that is scoped by an enforced one, right up until the assumption
does not hold. The suites are green either way.

Correction to the file list above: the count was wrong, and the way it was wrong is the issue itself

The nine files named above were found by matching *live*.smoke.ts on FILENAME. That is a naming
convention, and it does not classify this set correctly. Neither does the obvious replacement.

Three separate attempts to enumerate the affected suites produced three different answers, and each
one looked complete to the person who made it:

• Filter by filename containing "live" and you miss two suites that invoke the verb:
  implementations/auth/smoke/down-manifest-usermode.smoke.ts ("down" at 186, 240, 255) and
  implementations/auth/smoke/user-auth-launch.smoke.ts ("down" at 313, 339).
  smoke:down-manifest-usermode:live is in the check gate; smoke:user-auth-launch:live is not.
  Line 255 and line 339 are each a bare cotal down on a CLEANUP path, which is the
  worst position in the set: cleanup runs when the suite is already failing, and a suite that is
  already failing is exactly the case where the sandbox is least likely to have held.
• Filter by script name containing :live or -live instead, and you miss
  bin/smoke/up-tls-routes-live.smoke.ts, whose script is plain smoke:up-tls-routes with no live
  suffix at all. That file is in the original list of nine, so this rule drops a suite the issue
  already knew about.
• Neither filter can see implementations/auth/smoke/_ps-arm2.smoke.ts, which invokes the verb
  and is reached by no package.json script at all (another suite invokes it).

Measured on the tree: 41 scripts carry a live-ish name, 14 of those point at a file that invokes the
quoted down verb, and 23 smoke files invoke it in total. The set can be re-derived rather than
trusted:

node -e 'const fs=require("fs"),cp=require("child_process");
const p=require("./package.json").scripts;
const all=cp.execSync("grep -rl \"[\\\"'\"'\"']down[\\\"'\"'\"']\" --include=*.smoke.ts . --exclude-dir=node_modules",{encoding:"utf8"}).trim().split("\n").map(s=>s.replace(/^\.\//,""));
const byFile={};
for (const [k,v] of Object.entries(p)) for (const f of (v.match(/[\w./-]+\.ts/g)||[])) (byFile[f] ||= []).push(k);
for (const f of all.sort()) console.log(f.padEnd(62), (byFile[f]||["(NO SCRIPT)"]).join(","));'

Why this belongs in the issue and not only in the fix

A reader who implements the nine named files produces a change that looks complete, passes review,
and leaves two suites tearing down on a cleanup path. An issue that undercounts is a trap for
whoever picks it up next.

There is a sharper point. This issue is about an assumption that was remembered rather than
enforced, and its own file list was produced by an unenforced assumption: that a live suite is
spelled "live". Every classifier reached for so far has been a naming convention, and the defect ate
its own investigation twice before this was noticed.

So the fix should not hand-maintain a list of eleven, or fourteen, or twenty-three. A list is the
same defect one generation later: suite number twenty-four gets written next month by someone who
never read this issue, and it is unguarded on the day it lands. The enforcement belongs with the
destructive call, so that coverage is a property of the code path rather than of anyone's
enumeration, and an unguarded down becomes something you cannot write by accident rather than
something a reviewer is expected to notice. That is the same conclusion the section above already
reaches ("the guard belongs with the destructive call, not with the convention that is supposed to
keep it away"), arrived at from the other direction.

Two constraints the fix will hit immediately

Both are places where the convenient repair is a silent degradation, which this repo does not allow:

• user-auth-launch.smoke.ts and down-manifest-usermode.smoke.ts set no XDG_CONFIG_HOME at all.
  If that variable is load-bearing for what down resolves, those suites are under-sandboxed today,
  and the correct outcome is that they refuse until fixed. An optional field, or skipping the check
  when the value is absent, is fail-open: it turns "I cannot establish the sandbox" into a pass.
• user-auth-launch.smoke.ts:41, down-manifest-usermode.smoke.ts:40 and
  backup-usermode-live.smoke.ts:34 mutate process.env.COTAL_HOME globally rather than passing a
  per-spawn env, so a correctly sandboxed call can carry no env key at all. A guard that reads
  options.env sees nothing there, and "absent therefore fine" is the same fail-open.

[davidfarah2003]

Correcting my own filing: the containment variable for bare down is cwd, not COTAL_HOME

I filed this pointing at COTAL_HOME and suggested a guard shaped like assertSandboxMesh(env, root).
Having traced the resolution, that guard would have been aimed at the wrong variable: it would pass
while the sweep hit the operator's root. The correction is worth more than the original.

Bare cotal down never consults the mesh registry

down.ts resolves two contexts lazily. Only components explicitly named on the command line and
declared rootedAt: "target" (the web dashboard) go through resolveMeshTarget, which is the
registry path. Everything else, including every bare cotal down, uses the folder context:

const folderCtx = () => (folderContext ??= { root: cotalRoot(), space: resolveSpace(process.cwd()) });

Both fields come from a cwd walk. resolveSpace is soleSpaceOf(authDir(findCotalRoot(cwd)))
(packages/workspace/src/space.ts:9-11). So COTAL_HOME relocates the registry, the current-mesh
pointer and the onboard marker, and none of those are read on this path. It buys exactly zero
containment for the destructive verb, which is the opposite of what the sandbox construction in
these suites implies.

homeCotalDir's own docstring already says this in general terms ("setting only COTAL_HOME does
not redirect those paths"). What is new here is that it applies to down specifically, which is the
one command where getting it wrong is unrecoverable.

The resolver fails open, so there is no backstop

packages/workspace/src/auth-paths.ts:399-407:

if (parent === dir) return resolve(start);

When the walk finds no .cotal anywhere, it returns the starting directory rather than throwing.
Containment is therefore whatever the walk happens to land on. Measured, by transcribing that
function and running it against three real directories on a normal install:

A  mkdtemp under tmpdir(), no marker  ->  SELF (contained, by the fallback)
B  mkdtemp under $HOME,   no marker  ->  ESCAPED to /Users/<me>
B  same dir + mkdir .cotal           ->  SELF (contained, by the marker)
C  mkdtemp inside the checkout        ->  ESCAPED to the checkout root

B escapes because ~/.cotal exists on every install: it is where the mesh registry lives. So the
home directory is always a valid walk target.

The asymmetry is the real finding. Fail-open is defensible for up, which is about to create the
root it was handed. It is not defensible for down, which acts on whatever it lands on. The same
resolver serves a creating verb and a destroying verb, and only one of them can survive being wrong.

Per-suite, containment comes from two different mechanisms and neither is asserted

Eight of the nine build their root with mkdtemp(join(tmpdir(), ...)). Those are contained by the
fallback (case A), which holds only while tmpdir() has no .cotal ancestor. That is a property
of the runner's TMPDIR, not of the suite. Point TMPDIR under $HOME, which is a legal thing for
a CI image or a developer to do, and all eight resolve $HOME (case B) with no code change and no
diff to review.

orca-extension-live.smoke.ts is the interesting one. Its root is mkdtemp(join(REPO, ...)), inside
the checkout, so its walk is case C. It is contained, correctly, by an explicit marker created three
lines later:

const root = mkdtempSync(join(REPO, ".cotal-orca-e2e-"));
...
mkdirSync(join(root, ".cotal"), { recursive: true });

and its comment names this exact hazard. I want to be precise that this is not a live bug: I
checked before writing, and today it is right. But its two bare down calls (:237, :263) are
protected by one unasserted mkdirSync, and if that line is ever dropped, reordered after the first
CLI call, or separated from the mkdtemp by a refactor, the down sweeps the developer's own checkout
stack. Nothing would catch it: the down succeeds, the assertions pass, and the suite reports green.

That is this issue's thesis with the clearest possible example, which is why I am correcting the
filing rather than closing it.

The knowledge already exists in the repo, in one file out of nine

up-tls-routes-live.smoke.ts states the rule in its header ("COTAL_HOME alone only relocates the
mesh registry; broker policy, the NATS store, and pidfiles follow findCotalRoot from cwd") and
threads cwd explicitly through its cotal(args, home, cwd) helper. One suite of nine has both the
understanding and the plumbing. That is the argument for a single helper rather than nine edits:
the tenth suite, written next month, will not inherit a header comment.

So the guard changes shape

Not "resolve the mesh the CLI would act on" but "resolve the root the walk would land on, and
refuse unless it is the sandbox's own":

assertSandboxRoot(cwd);   // findCotalRoot(cwd) must be cwd, or it names both and throws

On refusal it should print the resolved root, the expected root, and the fact that COTAL_HOME does
not govern this, since that last part is the belief the failure will have been built on.

One claim to be careful with

A related generalization is circulating in roughly this form: a down that cannot reach its own mesh
and can reach yours is not containment, it is a delete, so the call should be removed. The direction
is right, but the premise does not transfer to the bare form. Bare down does not resolve a mesh at
all; registry reachability is irrelevant to it, and a teardown call that "resolves nothing" by that
test can still sweep a folder's pidfiles. Deleting the call is the correct edit when the teardown is
target-addressed. When it is bare, the correct edit is to pin the cwd, because the call is doing
something regardless.

[davidfarah2003]

The lead finding, replacing the walk-escape I filed: a seat's own state directory is inside a live mesh root

I filed this about sandbox construction, then corrected it to be about the cwd walk. Both were
downstream of the real thing, which another operator on this machine found and I then verified
independently. Putting it at the top because it is strictly worse than either.

Every agent sandbox on this machine is inside the live mesh root

Seat private state is created under the manager's own workspace root:

/Users/david/cotal-mac-fleet/.cotal/jcode/<space>-<seat>-<hash>/

There are 31 of these on this box right now. Transcribing findCotalRoot and running it against a
real one:

sandbox : /Users/david/cotal-mac-fleet/.cotal/jcode/<space>-<seat>-<hash>
resolves: /Users/david/cotal-mac-fleet
FLEET?  : YES - live fleet root

The walk goes up through .cotal/jcode to .cotal, finds no .cotal/.cotal, reaches
/Users/david/cotal-mac-fleet, and stops on the live mesh's own marker. So a process running from a
seat's sandbox does not have to escape anywhere to reach a mesh root. It starts inside one, and the
one it starts inside is the live fleet. Root resolves to the fleet, resolveSpace resolves to the
fleet's space, and the pidfiles it would read are the live broker, manager and delivery daemon.

That is the whole of what this issue was trying to describe, arrived at without any sandbox being
mis-built and without COTAL_HOME being involved at any point.

--cwd does not close it, and it is worth being precise about why

The obvious mitigation is to root every seat somewhere else. Two things defeat it.

First, the default. implementations/manager/src/manager.ts:3763:

const cwd = opts.cwd ? resolve(this.workspaceRoot, opts.cwd) : this.workspaceRoot;

A seat spawned without an explicit cwd is rooted at workspaceRoot, which is the mesh root
itself. No walk required at all: the resolution is direct.

Second, and less obvious: --cwd moves the seat's shell, while the sandbox is where the seat's own
machinery lives. Passing --cwd does not relocate the private state directory, so anything the
runtime itself launches from that directory still resolves the fleet. Both roads arrive at the same
root by different mechanisms.

Observed rather than theorised: a nats-server is running on this box right now, launched from
inside one of those sandboxes, holding the fleet's own auth/server.conf, with its Store Directory
pointed at the live JetStream store. That is this path in use, not a hypothetical.

Where that leaves the two earlier framings

Both still hold, and both are now the milder cases:

• A sandbox under $HOME with no marker resolves $HOME, whose .cotal exists on every install.
  On a developer box that is a real root, and the blast radius there is larger than the three
  daemons it looks like. Counted on this machine: 32 pidfiles under ~/.cotal, every one of them
  naming a dead pid. Three are the broker, manager and delivery daemon; the rest are per-agent
  serve.pid files left by previous sessions. So the failure there is not "tears down the wrong
  mesh", it is "sends SIGTERM to 32 pid numbers that have been unowned for a fortnight". After
  enough process churn those belong to something else, and the kill is unattributable, unbounded,
  and invisible in every log the run produces.
• A sandbox under tmpdir() is contained by the fail-open return at auth-paths.ts:404, which is a
  property of where TMPDIR points rather than of the suite.

So the guard cannot live in the suites

My original suggestion was a helper the live smokes call. That is now clearly insufficient, because
neither of the two paths found here is a suite constructing a sandbox. One is the spawn default and
one is the runtime's own state directory. A helper only guards callers that remember to call it, and
neither of these has a caller to instrument.

The assertion has to be made where the resolution happens, against the cwd the process actually
gets, including an inherited default. Concretely, the two edits that would have closed both paths:

1. Give each seat sandbox its own .cotal marker at creation, so the walk terminates inside the
   sandbox instead of at the fleet root. This is precisely what orca-extension-live.smoke.ts
   already does deliberately, and the comment there names this hazard by name:

   const root = mkdtempSync(join(REPO, ".cotal-orca-e2e-"));
   mkdirSync(join(root, ".cotal"), { recursive: true });

   One suite in the repo understood this. Nothing else in the repo does it, though at least one
   downstream consumer driving the installed CLI arrived at the same pattern independently, running
   the mkdirSync unconditionally at module top level before any cotal invocation, so there is
   never an ordering window between creating the root and marking it. That ordering is the part
   worth copying: the marker has to exist before the first CLI call, not merely somewhere in the
   file.

2. Make down refuse a root it was not told about. up may keep fail-open, since it is about to
   create the root it was handed. down should not, because it acts on whatever it lands on. That
   asymmetry is the root cause under all three framings: one resolver serves a creating verb and a
   destroying verb, and only one of them survives being wrong.

Credit where the code earns it

Two guards do fire and are worth not regressing. soleSpaceOf throws when an auth dir holds more
than one space rather than picking one, and assertSingleSpaceBroker refuses a broker-wide down
on a multi-space root and names the blast radius. Neither helps in any case described here, because
every root involved holds exactly one space. They are the right shape aimed at a different failure.

[davidfarah2003]

Three corrections from actually reading the nine suites, one of which weakens this issue's original premise

I filed this saying nine live smokes call a down path on an unenforced assumption. Having now read
their teardowns rather than their sandbox construction, one third of that framing was wrong and
should not be inherited.

The nine suites do not resolve anything by the walk

Control first, since this is a negative: spawnSync appears in 8 of the nine files and mkdtemp in
9, so the instrument reads them.

Six of the nine do have the dangerous shape at a glance, reading pidfiles and signalling:

backup-restore-live   8 signals /  4 pidfile reads
ext-live              3 / 15
dogfood-live          4 /  7
orca-extension-live   3 / 10
up-tls-routes-live    6 /  6
up-stack-live         5 /  4

But every pid path is built from the suite's own sandbox variable, never from a resolution:

join(root, ".cotal", "nats.pid")      join(cwd, ".cotal", "delivery.pid")
join(dir,  ".cotal", "web.pid")       join(parent, ".cotal", "nats.pid")

Only two files reference walk resolution at all, and neither performs one. backup-restore-live's
five hits are all authDir(root), passing its own sandbox root explicitly. up-tls-routes-live's
single hit is inside a comment.

So under correct sandbox construction these suites cannot reach an operator's mesh. Reaching it
requires the sandbox variable itself to be wrong, which is this issue's thesis but is not a teardown
defect in these files. The guard is still worth having; the suites are better than I described them.

The real exposure is an instruction, not a suite

The shape that actually reaches a live mesh needs no suite at all: a person or an agent exercising
up and down by hand from a cwd that resolves the operator's root. That is a plain SIGTERM to the
real broker, which is indistinguishable in the log from an intended teardown.

Worth stating because it generalises past this repo: a runbook, a review checklist or an agent
instruction that says "check that down reaps what up detached" is, on a machine where the
default working directory resolves a live root, a destructive instruction. It does not read like
one. The missing half is always "from where", and no amount of guarding the suites supplies it.

A hermeticity proof that hunts public addresses says nothing about loopback

The strongest correction came from someone instrumenting a suite that was believed hermetic. Its
standing proof of hermeticity is a syscall trace looking for public addresses on 443. Under
instrumentation the suite turned out to open a NATS client to 127.0.0.1:4222, the operator's own
broker, because its runtime config defaults to that when its env override is unset, and it held the
connection until a timeout killed the child rather than closing it.

The connection was not the cause of anything. The lesson is the instrument: "it passed the
hermeticity trace" is not evidence about loopback. A trace built to catch exfiltration to the
public internet is structurally blind to a dial at the operator's own machine, which is exactly the
direction that matters for a local control plane. Any suite in this repo claiming hermeticity on
that basis has the same blind spot.

That is the same failure this issue is about, one level up: a check that cannot fail on the case you
care about is indistinguishable, in every log it produces, from one that passed.

[davidfarah2003]

Retracting my own recommendation: up is the more dangerous verb, not the safe one

Earlier in this issue I wrote that the fail-open resolver is defensible for up:

up may keep fail-open, since it is about to create the root it was handed. down should not,
because it acts on whatever it lands on.

That is backwards, and it has now been demonstrated on a live machine rather than argued. Retracting
it, with the reasoning, because the wrong half of that sentence is the half people would have built
on.

A fresh root cannot be marked at the moment up needs it to be

The marker guard proposed above works by giving the intended root its own .cotal so the walk
terminates inside it. That works for a test suite, which can mkdirSync the marker before its first
CLI call.

It cannot work for cotal up itself. A freshly created root has no .cotal yet, because up is
the thing that creates it. So at the instant up resolves, the walk from its intended root
necessarily fails to stop there and climbs to the nearest ancestor holding a marker. On any
machine where a live mesh root sits above the intended one, that ancestor is the live mesh.

up then performs its teardown half against the root it resolved, and only afterwards creates its
own marker and brings up the intended stack. The observable sequence is: the operator's broker takes
a SIGTERM, the manager deregisters cleanly, and roughly twenty seconds later a correctly sandboxed
stack rises. Nothing in that output distinguishes it from a normal up.

So the asymmetry runs the other way from what I wrote. down at least usually acts on a root that
already carries a marker. up's intended root never does, by construction. The creating verb
contains the destroying verb, and it is the one that cannot be protected by marking. Fail-open has
to be removed from up first, not last.

The guard that failed did so while reporting success

Worth recording precisely, because the failure mode is this issue's whole thesis turned on the fix.

A guard was added requiring the operator to create a marked directory, resolve it with a transcribed
findCotalRoot, and paste the result before running any stack verb. It was followed exactly. The
pasted proof read:

resolves: /private/tmp/<name>-stack

correct, in the right order, with the /tmp → /private/tmp canonicalization on macOS noted. The
live mesh went down anyway.

The reason is that the proof described the shell's working directory, while the suite under test
built its own root with mkdtemp somewhere else entirely. Resolving that second path afterwards
returns the live mesh root. The guard was true, verifiable, pasted, and irrelevant to the path that
mattered.

Two things follow that are worth more than the incident:

1. A containment proof must name the path the destructive call will actually resolve, not a path
   the operator controls and believes is representative. Proving the wrong path produces a confident
   green and is worse than no proof, because it converts a suspicion into a settled question.
2. A suite's own mkdtemp root is a second, independent resolution surface. Guarding the
   invoking context does not guard it, and on a machine where the temp directory itself sits under a
   marked ancestor, mkdtemp(tmpdir()) yields a root that resolves to that ancestor. The earlier
   comment in this issue noted this as a TMPDIR-under-$HOME hypothetical. It is not
   hypothetical; it is the default inside an agent sandbox.

What actually closes this

Marking roots is a mitigation for callers and cannot be the fix. The fix is that a verb which stops
a stack must refuse a root it was not explicitly given, rather than accepting whatever the walk
returns. That applies to up's teardown half first, since it is the one whose intended root can
never carry a marker at decision time.

[davidfarah2003]

Partially fixed, current recurrence reproduced at exact main SHA 43e9dd303f71528ece5e13b169838b29cfff2de5. After a green full build, pnpm smoke:sandbox-guard passed its foreign/missing/replaced identity and CLI-parser controls, then failed the tree census naming three unguarded destructive suites: up-adopt-resume-lock-live, up-restore-reentry-live, and up-resume-render-lock-live. Each uses a proven-clean scratch root and sanitized env, but its real-CLI wrapper calls down / down --preserve-state without recordSmokeSandbox + assertSmokeSandboxDown; containment is claimed in comments, not enforced. Merged PR #913 implemented the original guard/census and remains the positive control. Open PR #1103 touches these three files for another concern but does not repair the guard. Recommend bug, triage:confirmed, area:ci, severity:critical. Implementation-ready regression: guard all three wrappers before any CLI call, preserve the census/mutation proof, and coordinate the refold with #1103.

[davidfarah2003]

Fixed by #913 (fix(smoke): enforce recorded sandbox identity before smoke-suite teardown, merged
2026-08-28, 96edee12f). It carried no closing keyword, so this stayed open.

Verified against main by reading the shipped tree, not by re-running the live suites:

The shared helper exists, which was the ask ("one shared helper, not nine edits") -
packages/smoke-kit/src/sandbox-guard.ts, exporting recordSmokeSandbox,
assertSmokeSandboxDown and assertSmokeSandboxTargetDown.

All nine named files call it, 3 to 5 call sites each (22 files repo-wide):

backup-faults-live 5   backup-conservation-live 3   backup-usermode-live 3
backup-restore-live 5  ext-live 4                   dogfood-live 4
orca-extension-live 3  up-tls-routes-live 3         up-stack-live 5

It binds at the CLI wrapper, not at each teardown site, which is stronger than what this issue
asked for. In dogfood-live.smoke.ts the anchor is recorded at construction and every cotal(...)
call is routed through the guard:

const sandboxAnchor = recordSmokeSandbox({ root, cotalHome: home, xdgConfigHome: configDir });
...
if (args[0] === "down" && args[1] === "web") assertSmokeSandboxTargetDown(sandboxAnchor, args, options);
else assertSmokeSandboxDown(sandboxAnchor, args, options);

So a future down added to one of these suites is guarded by default. The original failure mode
here - "a refactor drops env from one spawnSync among many" - no longer has a silent path,
because the check is on the route rather than on the call site.

The guarantee is mutation-proofed, bin/smoke/mutations/sandbox-guard.json, 10 mutations. Two
are worth naming because they cover the ways a guard like this usually rots rather than the happy
path: raw down spawn is not immediately guarded (a call site bypassing the shared helper) and
check reaches smoke:sandbox-guard before its first environment-dependent live suite (the proof
being moved behind the thing it protects).

And it is gated: smoke:sandbox-guard is in check, positioned ahead of every :live suite.

Stated plainly: this is a read of the shipped tree and its fixture, not an execution of the live
suites or the mutation run. What that leaves unverified is whether the fixture currently passes on
main; the gate above is what is supposed to keep that true.