fix(cli): a daemon-provisioned seat is never born unconfined — seat sandbox baseline (TASK-052) + refuse an unread trust value (TASK-059)

[lilyshen0722]

What this closes (C4-6 / TASK-052, with TASK-059 folded in)

A self-serve wrapper install ships no environment at all. The daemon projected that verbatim (environmentFor(row) → null), and the seat spawned with no sandbox — sandbox.mode defaults to 'none' in the adapters, so an absent block means no confinement while the seat takes instructions from everyone in the room. The c4 smoke seat had to be hand-confined through a row PATCH to get the sandbox agent attach would have refused to skip for a public pod.

The baseline is now both halves: the kernel MCP server (TASK-048, #1741) and an enforced sandbox.

Three commits, one policy: a sandbox declaration must never engage nothing — not the derived default, not the declared trust enum, not half of "public".

The stored shape carries no mode

"sandbox": { "trust": "public" }

Deliberately mode-less. The record is platform-independent and the host is not: mode: 'workspace' maps to Seatbelt on macOS and is refused on Linux, while mode: 'bwrap' is meaningless on macOS. Writing either into the row moves a host fact into the database and breaks the day the seat is re-homed (Wren 69545). The mode is resolved at spawn in the new cli/src/lib/sandbox/mode.js: darwin → workspace (Seatbelt), else → bwrap, and an explicit mode in a record still wins.

"public" is one contract, on both platforms

buildPublicClaudePolicyArgs — --setting-sources '', --disable-slash-commands, --strict-mcp-config, --no-chrome, --permission-mode dontAsk, --allowedTools Read(./**) plus the mcp patterns, --disallowedTools with the denied reads — was only reachable inside the Seatbelt branch. So a derived Linux seat ran inside bwrap with Bash, Write and WebFetch intact and on the operator's own Claude settings: the jail bounded the filesystem and nothing bounded the tools (Vera 69578, Wren 69586).

Now a public trust that resolves to bwrap gets the same policy args inside the namespace, and a bwrap seat with no public trust still gets only the jail — asserted in both directions, so the policy is the public contract and not a property of wrapping.

The mechanism is also checked where the mode is chosen: a public seat on a host without bwrap now fails its derivation with bwrap not found on PATH. Install bubblewrap: … instead of every spawn failing with a bare ENOENT. On macOS it reports the same macOS-only message the wrapper would have thrown later, so no existing message changed. (ctx._detectBwrap is a test seam, alongside the existing _spawnImpl.)

Mechanism per platform, stated rather than implied: darwin → /usr/bin/sandbox-exec with the policy args and the isolated per-identity HOME; linux → bwrap (--unshare-all, --die-with-parent) with the policy args inside the namespace and no isolated HOME — claude's Linux credentials live in HOME, so isolating it would break auth, and --setting-sources '' is what protects there.

Why the adapter changes are in this PR and not a follow-up

Measured on the shape alone: { trust: 'public' } with no mode engaged nothing. publicNativeSandbox required a mode in {workspace, read-only}, the "public requires an enforced mode" throw only fired on the literal 'none', and an absent mode fell straight through to the bare unconfined claude spawn — a record claiming confinement it never applied (Vera 69548). Shipping the stored default without the adapter change would have been worse than the hole it closes.

So, in the same PR:

• claude resolves the mode, and refuses any public trust that does not end up enforced (the literal 'none', a typo, a non-string) instead of falling through.
• codex defaults an absent mode to workspace. Its mode is read-vs-write access, not a host mechanism — its permission profiles run on both macOS and Linux — so it needs no platform branch. Before this, a mode-less public record threw got unset and no derived codex seat could spawn at all.
• assertSandboxDeclaredForPublicPod now uses the same predicate as the daemon (a public trust, or an explicit non-'none' mode), so the baseline the daemon writes is not a shape attach would refuse on a public pod. Attach still validates the resolved mode's host mechanism: Seatbelt present, bwrap installed, codex version. A side effect worth naming: mode: 'bwrap' without a trust field is now accepted on a public pod — the old predicate required trust and mode, so a genuinely confined bwrap seat was being refused.

TASK-059, folded in: a trust value no adapter reads (Wren 69585)

sandbox.trust: 'internal' was in the allowed set and read by no adapter: on the daemon path claude fell through to a bare unconfined spawn and codex took --dangerously-bypass-approvals-and-sandbox, so a declaration that reads as "confine me, not as a public agent" meant the opposite of what it said (Vera 69592, correcting my own filed premise — it was refused on the attach path, and bwrap.js reads the network/filesystem sub-blocks; the defect is the asymmetry).

• Refused for new declarations. ALLOWED_SANDBOX_TRUST is now just ['public'], and the message names what does something: sandbox.trust must be 'public' — it marks a seat anyone in the pod can talk to; omit it for your own seat.
• Resolved toward confinement for a record that already carries it. normalizeSandboxTrust reads internal as public, with one line in the spawn log saying what was read and why. The alternative — landing the enum change alone — would have left a record that looks public while still falling through to the bare spawn: the same defect wearing a better label. Its runtime half is this PR's resolver.
• The contract itself moved, and nothing went red to show it (Vera 69668 — the fourth inversion, and the only one that is not a test). Dropping 'internal' from ALLOWED_SANDBOX_TRUST means validateEnvironmentSpec now refuses a declaration it previously accepted on the attach path. No test pinned the old acceptance, so this is a contract change sitting in a two-line constant diff with no red test pointing a reader at it; it is called out here so it is not inferred from the diff. Blast radius measured by Vera, not reasoned: no live record carries internal — the sandbox blocks that exist are 2 dev installations ({trust:'public', mode:'workspace'} and {mode:'none'}) and 2 of 34 local token files, both trust:'public'. So the rejection breaks nothing today and the normalization path is currently theoretical.
• Not a no-op for existing seats; this direction is deliberate and it tightens them. {mode:'bwrap', trust:'internal'} gains the full policy it never had; {mode:'workspace', trust:'internal'} goes from a bare unconfined spawn to Seatbelt on darwin and to a refusal on Linux (public + workspace names a macOS mechanism); a codex seat with that declaration goes from the bypass flag to the public profile. An operator seat that relied on Bash under an internal declaration loses it and must declare public on purpose, or drop the field. A refusal and a stricter jail are both "toward confinement"; nothing here resolves toward the bare spawn.
• The claude adapter resolves the trust once, at the top of spawn, and threads it to both consumers — the public-state preparation and the argv builder. My first cut normalized in the argv builder only, and the seat died with public Claude state was not prepared before argv construction: the two consumers had read one declaration independently. That is this row's own bug reproduced inside its fix.

The pi seat: the default was written for an adapter that refuses it (fourth commit)

The sandbox half piggybacked on ADAPTERS_WITH_DEFAULT_MCP, the set of adapters that consume mcp[] — which is not the set that can enforce a sandbox. pi is in the first and not in the second, and since #1727 it throws before starting on sandbox.trust: 'public' (assertNoSandboxDeclared). So the default did not leave a pi seat unconfined, it left it dead: the daemon writes the record, the spawn refuses, and the record looks correct in the meantime. ADAPTERS_WITH_DEFAULT_SANDBOX (claude, codex) is now the predicate, and a pi seat gets the mcp[] half exactly as it did before this branch.

The stale claim was in the doc comment — "a pi seat gets the block and is NOT confined by it" — which was the opposite of the truth and is replaced by the mechanism. The C4-2 fixture in daemon-supervisor.test.mjs is a pi row and pinned the buggy both-halves shape; it now asserts the mcp half and runs the derived value through pi's own guard, because the invariant is not "no sandbox key" but "the spec this adapter receives is one this adapter accepts". Mutation-proven: reverting the guard to ADAPTERS_WITH_DEFAULT_MCP reds exactly two tests — the new seatBaseline case and that fixture.

This is the fourth thing this PR got wrong the first time and is worth reading as a pattern rather than an incident: each one was found by running the consumer, not the serializer — claude's two consumers of one declaration, codex's throw that would have stopped every derived codex seat, and now pi's refusal. Grepping the readers of a shape before shipping it is the habit; "the tests are green" was true on all four.

The trust boundary

Which environments get the sandbox is the same boundary the daemon already uses: environments it derived —

• a server-declared environment, or
• a seat nobody has authored anything for (fresh mint, a record with no environment, the TASK-048 heal path).

An operator-authored local environment keeps its own choice. A private-pod record with no sandbox is exactly what agent attach permits, and silently confining it would break seats that deliberately run with host reach. withDefaultSandbox replaces an explicitly disengaged mode: 'none' rather than honouring it, because on this path 'none' and absent are the same thing to the spawn.

Honest limits

• Confinement holds for claude and codex, and only they are ever handed the block. A pi seat gets the mcp[] half only: pi has no sandbox path until cli: the pi adapter keeps only stdio MCP servers, so a pi seat holding a room grant never sees the broker tools #1740 and fails closed on a declared sandbox (fix(cli): pi seats — seat token out of the shell env; unenforceable sandbox fails closed #1727), so writing this default onto a pi record does not leave it merely unconfined — it makes the seat unspawnable. That is fixed in the fourth commit below, and the residual is stated with it.
• A derived pi seat therefore still runs unconfined, and the case that matters is not the operator's machine. It is a pi seat in a room containing humans the owner does not control — precisely c4-smoke at 11:34, the configuration that produced the host-gh bypass with an empty grant trail. Vera's recommendation, adopted here as the shape to file rather than to settle in this PR: keep the exclusion (a declaration pi refuses is strictly worse than none, and it costs the seat's availability to no one's benefit), and treat "derive a pi seat into a room with non-owner humans" as a refusal at derive time — loud, naming the seat and the room — instead of a silent unconfined spawn. That is a policy call for Sam and Wren. Filed as TASK-063; not decided here.
• Not verified on a real Linux host. The Linux path is asserted with a mocked process.platform, the adapter's bwrap branch and the _detectBwrap seam. The behaviour of the added policy args inside a real namespace is unmeasured here.
• Not a guard. Nothing is refused and no seat is stopped; an installed seat gains the confinement on its next daemon tick. Refusing a declared command or a foreign-origin token address is layer 2, Wave's fix(cli): the daemon refuses a declared environment that would run a foreign command or ship the seat token off-instance #1744.

Testing

39 suites / 567 passed / 10 skipped; lint:cli clean.

• 6 new in default-environment.test.mjs, including "stores NO mode" and the idempotence that keeps a derived record from being rewritten (and its seat restarted) every tick.
• 5 new in daemon-supervisor.test.mjs: fresh seat confined, a declared environment that names no sandbox gains it, the live c4-smoke shape left byte-identical with no rewrite on the next tick, an operator-authored environment keeps its own choice, a record with no environment is confined.
• 5 new in adapters.claude.environment.test.mjs: mode-less public resolves to Seatbelt on darwin; a derived Linux seat carries the same policy args inside bwrap; a host with no bwrap refuses to derive and spawns nothing; a trust-less bwrap seat gets the jail with no policy args; an unresolvable explicit mode refuses; a legacy trust:'internal' + workspace seat is confined under Seatbelt.
• 2 new in adapters.codex.test.mjs (derived default, and a legacy internal seat getting the public profile and never the bypass flag); 2 new in public-pod-sandbox-gate.test.mjs.
• 4 new in environment.test.mjs (validation refuses internal and names the two declarations that do something; the legacy resolution, including that it leaves an absent sandbox block alone).

Merged tests whose pinned behaviour this change inverts, deliberately — both are in the list because a reader of the diff will find them:

1. The C4-2 baseline assertion from fix(cli): daemon-provisioned seats get the commonly MCP baseline (TASK-048) #1741 asserted the mcp-only baseline — that assertion encoded this gap. It was first inverted to both halves, and is now the pi mcp-half assertion: the fixture is a pi row, and pi is the one adapter that must not receive the sandbox.
2. Codex's "public trust fails closed when no enforced public sandbox mode is declared" asserted the throw that would have stopped every derived codex seat.

Verified on the real writers, not only injected ones (real supervisor tick, real saveAgentToken / loadAgentToken, temp HOME): the self-serve row shape writes {sandbox: {trust: 'public'}, mcp: [commonly], model}, and the hand-confined c4-smoke shape is byte-preserved with no rewrite on the following tick.

Version

cli 0.1.50 → 0.1.51, rebased onto main ac544d5c. The number did not move again for the pi correction: the branch already sits above main and above every in-flight claim, and re-bumping would only re-open a slot somebody else may be holding.

The number kept moving and is the reason for the rebase, so here is the chain read off the tree rather than recalled: d620c25b was 0.1.47, #1726 took 0.1.48, #1727 (ac544d5c) took 0.1.50 — skipping 0.1.49, which Wave's open #1744 branch holds — and this branch had been cut from 48a5ea92 at 0.1.49. Sitting on that base meant Source changed ⇒ version bumped would fail and this PR would have shipped a version below main's. Rebased onto ac544d5c and renumbered to 0.1.51: above main and above every in-flight claim.

Patch identity across the rebase, on the only file where rebasing could matter — cli/package.json, whose version line conflicts:

diff <(git diff 48a5ea92 322c0bba -- cli | grep -v '"version"') \
     <(git diff ac544d5c 40899704 -- cli | grep -v '"version"')

is empty apart from a blob-index line (the base content differs, so the hash must); the version hunk is the only real change, 0.1.48→0.1.49 becoming 0.1.50→0.1.51.

Overlap with #1744, stated rather than hidden: Wave's PR and this one both touch cli/src/lib/daemon-supervisor.js and its test. Different concerns — his is the declared-MCP guard, this is the seat's environment baseline — so they should compose, but whoever lands second rebases into the first and the other should re-read that file rather than assume. I had been holding this PR back so #1744 could take 0.1.49; now that the version question is settled independently (0.1.51 clears both), holding it only hides a conflict, so it is open.

[lilyshen0722]

Merge-order note (measured, not inferred) — git merge-tree --write-tree --merge-base=origin/main, git 2.54.

This PR, #1761 and #1744 each edit cli/package.json's version line from the same base (main = 0.1.50), so they pairwise CONFLICT on that one line. Head versions: #1744 = 0.1.49 (below main, so it fails the version guard as-is and needs a rebase + bump in any order), this PR = 0.1.51, #1761 = 0.1.52. Everything else in the three trees auto-merges cleanly (cli/src/lib/daemon-supervisor.js and cli/__tests__/daemon-supervisor.test.mjs merge without conflict; #1744 + #1760 is clean too).

Cheapest order: land this first, then #1761 rebases and resolves the line to 0.1.52 — which still passes the guard, because 0.1.52 ≥ main's 0.1.51.

Reversed order costs more: if #1761 lands first, main becomes 0.1.52 and this PR's 0.1.51 is below it, so it must be re-bumped to 0.1.53 rather than merely re-resolved. In either order the second PR's head moves, and a head move does not carry the existing clearance — re-ping Vera.

Two clean pairs worth knowing: #1750 + #1757 auto-merge, and #1751 + either of them auto-merges.

[lilyshen0722]

Correction to my own note above, and it is worth reading because the method that produced it was wrong.

I wrote "#1744 + #1760 is clean too". That came from running the simulation as git merge-tree --write-tree --merge-base=origin/main A B. Forcing main as the base is only valid when both branches were cut from main's tip. #1744's is not: its true base predates main's 0.1.50 bump, so pretending main is the base made the version line look single-sided and produced a "clean" that isn't real.

Re-run with the natural merge base (no --merge-base), which is the model that matches how these actually land — B merges into main first, then A merges into the result — the picture is:

• fix(cli): a daemon-provisioned seat is never born unconfined — seat sandbox baseline (TASK-052) + refuse an unread trust value (TASK-059) #1754 × fix(cli): the daemon reports the seat's record, not the row runtime, as what it runs (TASK-065) #1761 → conflict, cli/package.json (version line only). Unchanged.
• fix(cli): the daemon refuses a declared environment that would run a foreign command or ship the seat token off-instance #1744 × every branch cut from main's tip, including docs-only ones → conflict, cli/package.json only. That is the same conflict that makes fix(cli): the daemon refuses a declared environment that would run a foreign command or ship the seat token off-instance #1744 read DIRTY: base 0.1.48, fix(cli): the daemon refuses a declared environment that would run a foreign command or ship the seat token off-instance #1744 0.1.49, main 0.1.50. So fix(cli): the daemon refuses a declared environment that would run a foreign command or ship the seat token off-instance #1744 needs a rebase and a bump to ≥0.1.51 before it can land in any order, and it is not specifically colliding with this PR.
• Everything else is clean: fix(grants): a parked call whose approval resolved stops counting as "awaiting a person" (TASK-058) #1750 × fix(v2): name a human in a grant audience instead of calling them "an agent" (TASK-050) #1757, feat(connectors): push a user-scoped invalidation so a visible tab re-reads (TASK-135) #1751 × either, docs(plans): C4 exit record — stranger run reached; a grant binds only a seat with no ambient credentials (TASK-053) #1749 × anything, test(cli): pin the daemon's reduction of the server podIds union (TASK-019) #1760 × both of mine.

Forced-base is right for the question "can both land from today's main?" only when neither branch is behind main; the natural base is right for reality.

[lilyshen0722]

Coupling worth knowing before these land, measured after the note above. This PR is cleared at 3768fa29 and stays there — no commit follows from this.

kai/1743 (fix/claude-public-sandbox-http-mcp) is the only fix for a live crash on the darwin path: a freshly derived claude seat that carries an HTTP MCP entry in environment.mcp dies at spawn in isAbsolute(undefined) (cli/src/lib/adapters/claude.js:454), reached via prepareArgv. I ran #1743's own test against this branch head in a scratch worktree — it fails there exactly as it does on main — so the two are independent, and this PR does not carry the fix.

They compose textually (clean merge-tree, same function but different regions) and the land order is free and version-clean: this PR at 0.1.51 first, then #1743 at 0.1.53; or #1743 first, in which case this one needs a re-bump rather than a resolution.

One ordering consideration, stated without overstating it: this PR widens the set of seats that are confined by declaration, and confinement is what triggers the crash — so if a daemon-derived seat with a broker HTTP MCP entry exists, this PR is what turns it from "works, unconfined" into "dies at spawn". I could not measure that population (no cluster access here); what I can say is that the one record known to declare the grant broker already declares a public sandbox, so such a seat is already exposed on main today and #1743 is the fix for it. Landing #1743 first is therefore the safer order if the merge queue lets you choose, and the cost of that order is one re-bump on this PR.

[lilyshen0722]

Merge-queue facts, measured just now, because this is the first of four cli/ PRs and the order they land in has a cost.

Nothing technical is blocking any of them. gh api repos/Team-Commonly/commonly/branches/main/protection → required check Test & Coverage only, required_status_checks.strict = true, no required reviews. So all 15 of my CLEAN PRs are mergeable now, by anyone with write access, without an approval.

Two consequences of strict = true worth knowing before starting:

1. Every merge puts the other 14 out of date; each needs an update-branch before it can land. The queue is serialized no matter what order you pick, so pick the order that costs least.

2. Four PRs touch cli/src and therefore bump cli/package.json:

   PR	version
   this one (fix(cli): a daemon-provisioned seat is never born unconfined — seat sandbox baseline (TASK-052) + refuse an unread trust value (TASK-059) #1754)	0.1.51
   fix(cli): the daemon reports the seat's record, not the row runtime, as what it runs (TASK-065) #1761	0.1.52
   fix(cli): a public-sandboxed claude seat survives an HTTP MCP server in its environment #1743	0.1.53
   fix(cli): pi Streamable HTTP MCP transport, a declared transport decides an entry's shape, and a granted pi seat is never given the broker (TASK-054, TASK-063 daemon half) #1764	0.1.54

   I re-ran the six pair-wise merge simulations with natural merge bases (git merge-tree --write-tree A B, no --merge-base): every pair conflicts on cli/package.json and on nothing else — claude.js, daemon-supervisor.js and the test files auto-merge.

So: land them in ascending version order, and each later one resolves by keeping its own version line. The guard's "must increase" rule then stays green and nobody re-bumps. Any other order leaves a lower version under main and the guard fails on that PR with its own message ("version is still X"), which is fixable only by its author bumping again — that is the entire reason the order matters.

The other eleven are docs/tests/frontend only — no version line, no cross-PR conflict: #1750 #1752 #1753 #1755 #1756 #1757 #1758 #1759 #1760 #1762 #1763.