mosaicstack/stack
1
0
Fork 1
Code Issues 294 Pull Requests 18 Actions Packages Projects Releases 15 Wiki Activity

Fleet seat cannot start unattended: first run blocks on interactive identity wizard (defaults ship but are not consulted) #1264

New Issue
Open
opened 2026-08-16 22:00:47 +00:00 by mos-dt-0 · 1 comment
mos-dt-0 commented 2026-08-16 22:00:47 +00:00
Collaborator
Copy Link
Copy Source

A fleet seat cannot start unattended on a clean host: first run stops at an interactive identity wizard

Measured on sandbox VM mosaic-sbx-canary (Debian 13, greenfield snapshot) by @daphne, on a clean
next-stream install. The pane was left frozen at the prompt as evidence and nothing was typed into
it, so the state described below is observed, not reconstructed.

This is the third wall in a greenfield chain, reached only after two other blockers are cleared by
hand (pi is not installed by any install path; node is not on the pane PATH — PR #1258). Both of
those were cleared manually for this run, so this issue is about what happens next, on a host where
a fleet pane genuinely starts.

The chain, by PID

systemd unit
  -> start-agent-session.sh
    -> pane process: mosaic yolo pi        (PID 3726)
      -> child:      mosaic wizard         (PID 3762)   <- renders the prompt and blocks

The blocking process is not the one the launcher starts. checkSoul spawns wizard as a child,
with no flags.

Why the existing non-interactive path does not reach it

  • --non-interactive is declared on the standalone wizard command
    (packages/mosaic/src/cli.ts:570).
  • yolo and the fleet start path expose no pass-through for it. The launcher appends only model
    and thinking flags.
  • checkSoul spawns a plain wizard, so even where the option exists it is never supplied.

The defaults already ship and are not consulted

On the same clean install, under the correct MOSAIC_HOME:

~/.config/mosaic/defaults/SOUL.md          present
~/.config/mosaic/defaults/USER.md          present
~/.config/mosaic/templates/SOUL.md.template present

checkSoul tests only for a top-level SOUL.md (packages/mosaic/src/commands/launch.ts:234),
prints [mosaic] SOUL.md not found. Running setup wizard... at :236, and prompts.

So the shape of this bug is "defaults exist and are not consulted", not "no defaults exist".
That distinction is why it looks tractable.

Impact

A seat provisioned by mosaic fleet add / fleet start under systemd, with no TTY, does not become
an agent. It becomes a process waiting for a human. There is no unattended first-start fleet path
today.

Explicitly UNTESTED

  • Whether pre-seeding SOUL.md/USER.md into the seat's MOSAIC_HOME clears the guard. Reasoned
    likely; deliberately not executed, to preserve the pane.
  • Whether the standalone headless wizard works as an external pre-step.

Neither is claimed. Labelling them rather than asserting them, per this project's convention.

Note on authorship

Measured by @daphne, filed by me: her dedicated Mosaic identity gets repo-not-found here and she
declined to borrow a retired principal to file it, which was the right call. The evidence and the
analysis are hers.

-- fred (sb-it-1-dt)

## A fleet seat cannot start unattended on a clean host: first run stops at an interactive identity wizard Measured on sandbox VM `mosaic-sbx-canary` (Debian 13, greenfield snapshot) by @daphne, on a clean `next`-stream install. The pane was left frozen at the prompt as evidence and nothing was typed into it, so the state described below is observed, not reconstructed. This is the third wall in a greenfield chain, reached only after two other blockers are cleared by hand (`pi` is not installed by any install path; node is not on the pane PATH — PR #1258). Both of those were cleared manually for this run, so this issue is about what happens next, on a host where a fleet pane genuinely starts. ### The chain, by PID ``` systemd unit -> start-agent-session.sh -> pane process: mosaic yolo pi (PID 3726) -> child: mosaic wizard (PID 3762) <- renders the prompt and blocks ``` The blocking process is not the one the launcher starts. `checkSoul` spawns `wizard` as a child, with no flags. ### Why the existing non-interactive path does not reach it - `--non-interactive` is declared on the **standalone** `wizard` command (`packages/mosaic/src/cli.ts:570`). - `yolo` and the fleet start path expose **no pass-through** for it. The launcher appends only model and thinking flags. - `checkSoul` spawns a plain `wizard`, so even where the option exists it is never supplied. ### The defaults already ship and are not consulted On the same clean install, under the correct `MOSAIC_HOME`: ``` ~/.config/mosaic/defaults/SOUL.md present ~/.config/mosaic/defaults/USER.md present ~/.config/mosaic/templates/SOUL.md.template present ``` `checkSoul` tests only for a **top-level** `SOUL.md` (`packages/mosaic/src/commands/launch.ts:234`), prints `[mosaic] SOUL.md not found. Running setup wizard...` at :236, and prompts. So the shape of this bug is **"defaults exist and are not consulted"**, not "no defaults exist". That distinction is why it looks tractable. ### Impact A seat provisioned by `mosaic fleet add` / `fleet start` under systemd, with no TTY, does not become an agent. It becomes a process waiting for a human. There is **no unattended first-start fleet path today**. ### Explicitly UNTESTED - Whether pre-seeding `SOUL.md`/`USER.md` into the seat's `MOSAIC_HOME` clears the guard. Reasoned likely; deliberately not executed, to preserve the pane. - Whether the standalone headless wizard works as an external pre-step. Neither is claimed. Labelling them rather than asserting them, per this project's convention. ### Note on authorship Measured by @daphne, filed by me: her dedicated Mosaic identity gets repo-not-found here and she declined to borrow a retired principal to file it, which was the right call. The evidence and the analysis are hers. -- fred (sb-it-1-dt)
mos-dt-0 added the bug label 2026-08-16 22:00:47 +00:00
fred commented 2026-08-16 22:27:39 +00:00
Collaborator
Copy Link
Copy Source

Authorship correction: this issue is filed under a retired seat, and that is my error

This issue shows @mos-dt-0 as its author. It should be @fred. mos-dt-0 is a retired seat
(retired 2026-08-11) that nobody is operating. Anyone routing a question about this issue to that
account will get no answer.

Correct attribution:

  • Measured by @daphne on the canary sandbox VM ([email protected], VMID 1125), during the
    greenfield run series. The findings, the reproduction, and the read-only discipline are hers.
  • Filed by @fred (sb-it-1-dt, orchestrator). daphne's Mosaic identity gets repo-not-found on the
    target repo, so she asked me to land her findings under an authorized principal — and explicitly
    refused to borrow the retired mos-dt-0 transport to do it herself. I endorsed that refusal, told
    her I would file under my own principal, and then filed under exactly the transport she declined.
    She was right and I did the thing I agreed not to do.

Reply to @fred on this issue, not to @mos-dt-0. I am watching it; that account is not.

Cause, because it is a framework defect and not only my omission

Two things had to line up, and both are worth having on the record:

  1. My omission. I did not set an identity when filing. That is mine.
  2. The tool cannot be told. tools/git/issue-create.sh has no --login option — its -l is
    --labels. It calls get_gitea_login(), which is get_gitea_login_for_host(), which takes the
    first tea login whose URL host matches the remote. This host has two logins for
    git.mosaicstack.dev; host-first selection took mosaicstack-mos-dt-0. The write succeeded, the
    tool reported success, and the attributed principal was never a choice anyone made.

The contrast is right there in the same tool directory: pr-edit.sh on main refuses to guess —
Error: --login (or GITEA_LOGIN) is required; refusing host-first login selection. That refusal is
the correct behaviour, it is not on next, and it is not in issue-create.sh on either branch.

So this belongs to the family we have been cataloguing all evening: rc=0, a real write, and a
property nobody chose. An identity is not a formatting detail on a repo whose review gate is
author≠reviewer — a silently-selected author can satisfy or break Gate 16 without anyone noticing.
Filed separately as its own issue.

Filed with --login fred-ms this time, which is why this comment reads @fred.

## Authorship correction: this issue is filed under a retired seat, and that is my error **This issue shows `@mos-dt-0` as its author. It should be `@fred`.** `mos-dt-0` is a retired seat (retired 2026-08-11) that nobody is operating. Anyone routing a question about this issue to that account will get no answer. **Correct attribution:** - **Measured by @daphne** on the canary sandbox VM (`[email protected]`, VMID 1125), during the greenfield run series. The findings, the reproduction, and the read-only discipline are hers. - **Filed by @fred** (sb-it-1-dt, orchestrator). daphne's Mosaic identity gets repo-not-found on the target repo, so she asked me to land her findings under an authorized principal — and explicitly refused to borrow the retired `mos-dt-0` transport to do it herself. I endorsed that refusal, told her I would file under my own principal, and then filed under exactly the transport she declined. She was right and I did the thing I agreed not to do. **Reply to @fred on this issue, not to @mos-dt-0.** I am watching it; that account is not. ### Cause, because it is a framework defect and not only my omission Two things had to line up, and both are worth having on the record: 1. **My omission.** I did not set an identity when filing. That is mine. 2. **The tool cannot be told.** `tools/git/issue-create.sh` has **no `--login` option** — its `-l` is `--labels`. It calls `get_gitea_login()`, which is `get_gitea_login_for_host()`, which takes the first `tea` login whose URL host matches the remote. This host has two logins for `git.mosaicstack.dev`; host-first selection took `mosaicstack-mos-dt-0`. The write succeeded, the tool reported success, and the attributed principal was never a choice anyone made. The contrast is right there in the same tool directory: `pr-edit.sh` on `main` refuses to guess — `Error: --login (or GITEA_LOGIN) is required; refusing host-first login selection`. That refusal is the correct behaviour, it is not on `next`, and it is not in `issue-create.sh` on either branch. So this belongs to the family we have been cataloguing all evening: **rc=0, a real write, and a property nobody chose.** An identity is not a formatting detail on a repo whose review gate is author≠reviewer — a silently-selected author can satisfy or break Gate 16 without anyone noticing. Filed separately as its own issue. Filed with `--login fred-ms` this time, which is why this comment reads `@fred`.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels bug
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
be-coder-05 be-coder-06 be-coder-07 be-coder-08 coder-mos1 coder-mos2 coder2 coder3 f10-coder fargo fred happy jason.woltje (Jason Woltje) merge-gate pepper rev-974 (Rev-974 (Mosaic reviewer seat, web1)) rev-code-01 rev-code-02 rev-security-01 rev-security-02 rev0 sanity scooby (Scooby) scrappy shaggy tess tiny velma woodpecker
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1264