The roster lane and the harness-homes lane did not touch. start-agent-session.sh
ran `mosaic yolo "$RUNTIME"` with HOME set to the operator's home, so every fleet
seat on a host shared the operator's harness home and, for Claude, the operator's
own ~/.claude credentials. Nothing in framework/ called `mosaic fleet launch` at
all, which meant ~/.mosaic was a directory nothing read.
The pane now runs `mosaic fleet launch "$AGENT_NAME"` when a scaffolded seat
exists at $PANE_HOME/.mosaic/fleet/agents/<name>/profile.json, and the historical
command otherwise. Detection uses $PANE_HOME/.mosaic rather than MOSAIC_DATA_HOME
because the pane environment is cleared with env -i; the composition resolves the
same root from HOME, so the two cannot disagree.
Additive by construction: a host with no scaffolded seats launches exactly as
before, so this can land ahead of any seat being enrolled.
- fleet launch gains --dangerous, threaded to launchFleetRuntime. Without it a
seat launched from the roster would drop the permissions footing `mosaic yolo`
gave it and prompt at a pane with nobody at it. The roster launcher asks for it
explicitly so it stays visible in the process table instead of becoming a
profile default.
- A caller's --model replaces the profile's instead of being appended after it.
The roster carries a model per seat and is the surface operators edit; emitting
both flags would leave the choice to each harness's argument parser.
- Claude workdir trust is written into the seat's .claude.json when the pane will
run in a seat home. It previously always went to the operator's ~/.claude.json,
which would leave the seat prompting on its first turn.
Covers Jason's scope amendment for web1: without this seam, "multiple
authentication accounts and agent pegging to auth" cannot be demonstrated on a
roster-managed seat.
terra
c1a42cdb81