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

fleet: mechanize seat git-identity lifecycle (mint + wire MOSAIC_GIT_IDENTITY + verify write-differential) — bring-up mints tokens but never wires identity #1043

New Issue
Open
opened 2026-08-04 02:46:43 +00:00 by Mos · 4 comments
Mos commented 2026-08-04 02:46:43 +00:00
Contributor
Copy Link
Copy Source

Problem

Fleet seat bring-up mints a gitea token for a seat but never wires the seat's git identity into its environment. The credential helper (git-credential-mosaic) resolves identity as MOSAIC_GIT_IDENTITY (env) → git config mosaic.gitIdentity → git-supplied username; with none set it fails closed on the seat's first git op against a managed host (reason=no-identity).

Fail-closed is the correct and desired behavior — the helper never falls back to a shared/privileged owner account, which is the whole security property. But because the configure side is two separate manual steps (mint token; wire identity) and the second is routinely skipped, seats reach the runtime unable to do any git until an operator hand-edits the env file.

Evidence

  • 2026-08-03: multiple fleet seats escalated reason=no-identity on git.uscllc.com despite their tokens being present in the credential store (~/.config/mosaic/secrets/gitea-tokens/gitea-usc-<seat>.token).
  • Audit of the roster: 8 of 9 USC-operating seats had a token but no MOSAIC_GIT_IDENTITY in their env; only one seat (hand-fixed in an earlier session) had it. The bring-up env generator writes MOSAIC_AGENT_{NAME,CLASS,RUNTIME,MODEL,WORKDIR} + socket but not the identity.

Why per-repo git config is NOT the fix

Seats operate in linked worktrees sharing one .git, with extensions.worktreeConfig off. git config mosaic.gitIdentity therefore writes the shared config, so one seat's identity contaminates every co-tenant worktree (chimera identity). The identity MUST be a per-process env var — which is exactly what the seat env file is for.

Ask — mechanize the seat git-identity lifecycle as a mosaic command

A single idempotent, reproducible command (e.g. mosaic fleet seat provision <name> [--host ...]) that:

  1. mints or reuses the seat's gitea account + a scoped token for the target managed host(s) (minimal scopes per role: write:repository, write:issue, read:user);
  2. writes the token to the credential store under the canonical filename the helper expects (gitea-<hostpfx>-<name>.token, hostpfx ∈ usc|mosaicstack);
  3. wires MOSAIC_GIT_IDENTITY=<name> into the seat env (never left to a follow-up step);
  4. verifies the per-repo write-differential — a token that authenticates on one repo proves nothing about another; probe read+write against the intended target repo and assert by the resulting object/permission, not an exit code;
  5. emits an audit line of exactly what it did.

Embed it in install/config/wizard so a fresh fleet comes up correctly credentialed with reduced manual steps, and make the seat generator always write the identity.

Guardrails (keep the security property)

  • Never fall back to a privileged/shared account — preserve fail-closed.
  • Surface a missing token as an explicit actionable at bring-up, not as a silent runtime fail-closed later.
  • Keep token scopes minimal per role.

Interim stopgap (already applied locally, not a substitute for the mechanical fix)

  • Wired MOSAIC_GIT_IDENTITY=<seat> into all existing USC-operating seat envs.
  • Patched the local seat generator (fleet-bringup.sh) to always write MOSAIC_GIT_IDENTITY and warn when no token exists for the identity on either managed host.

The durable, reproducible fix belongs in the stack (generator + wizard + a mosaic lifecycle command), so a correctly-credentialed fleet is the default, not the result of a manual sweep.

## Problem Fleet seat bring-up mints a gitea **token** for a seat but never wires the seat's **git identity** into its environment. The credential helper (`git-credential-mosaic`) resolves identity as `MOSAIC_GIT_IDENTITY` (env) → `git config mosaic.gitIdentity` → git-supplied username; with none set it **fails closed** on the seat's first git op against a managed host (`reason=no-identity`). Fail-closed is the correct and desired behavior — the helper never falls back to a shared/privileged owner account, which is the whole security property. But because the *configure* side is two separate manual steps (mint token; wire identity) and the second is routinely skipped, seats reach the runtime unable to do any git until an operator hand-edits the env file. ## Evidence - 2026-08-03: multiple fleet seats escalated `reason=no-identity` on `git.uscllc.com` **despite their tokens being present** in the credential store (`~/.config/mosaic/secrets/gitea-tokens/gitea-usc-<seat>.token`). - Audit of the roster: 8 of 9 USC-operating seats had a token but **no** `MOSAIC_GIT_IDENTITY` in their env; only one seat (hand-fixed in an earlier session) had it. The bring-up env generator writes `MOSAIC_AGENT_{NAME,CLASS,RUNTIME,MODEL,WORKDIR}` + socket but **not** the identity. ## Why per-repo git config is NOT the fix Seats operate in **linked worktrees** sharing one `.git`, with `extensions.worktreeConfig` off. `git config mosaic.gitIdentity` therefore writes the **shared** config, so one seat's identity contaminates every co-tenant worktree (chimera identity). The identity MUST be a **per-process env var** — which is exactly what the seat env file is for. ## Ask — mechanize the seat git-identity lifecycle as a `mosaic` command A single idempotent, reproducible command (e.g. `mosaic fleet seat provision <name> [--host ...]`) that: 1. mints or reuses the seat's gitea account + a **scoped** token for the target managed host(s) (minimal scopes per role: `write:repository`, `write:issue`, `read:user`); 2. writes the token to the credential store under the canonical filename the helper expects (`gitea-<hostpfx>-<name>.token`, hostpfx ∈ `usc`|`mosaicstack`); 3. wires `MOSAIC_GIT_IDENTITY=<name>` into the seat env (never left to a follow-up step); 4. **verifies the per-repo write-differential** — a token that authenticates on one repo proves nothing about another; probe read+write against the *intended target repo* and assert by the resulting object/permission, not an exit code; 5. emits an audit line of exactly what it did. **Embed it in install/config/wizard** so a fresh fleet comes up correctly credentialed with reduced manual steps, and make the seat generator always write the identity. ## Guardrails (keep the security property) - Never fall back to a privileged/shared account — preserve fail-closed. - Surface a **missing token** as an explicit actionable **at bring-up**, not as a silent runtime fail-closed later. - Keep token scopes minimal per role. ## Interim stopgap (already applied locally, not a substitute for the mechanical fix) - Wired `MOSAIC_GIT_IDENTITY=<seat>` into all existing USC-operating seat envs. - Patched the local seat generator (`fleet-bringup.sh`) to always write `MOSAIC_GIT_IDENTITY` and warn when no token exists for the identity on either managed host. The durable, reproducible fix belongs in the stack (generator + wizard + a `mosaic` lifecycle command), so a correctly-credentialed fleet is the default, not the result of a manual sweep.
Mos commented 2026-08-05 07:21:07 +00:00
Author
Contributor
Copy Link
Copy Source

ROOT CAUSE LOCATED — exact line. The seat env reaches the systemd UNIT but never the PANE.

Traced end-to-end while standing up a new seat, so this is measured rather than inferred.

The chain is correct until the last hop:

  1. The seat env file contains MOSAIC_GIT_IDENTITY=<seat> ✔
  2. The systemd unit loads it: EnvironmentFile=-%h/.config/mosaic/fleet/agents/%i.env ✔ (installed unit verified byte-identical to the repo copy — this is not drift)
  3. start-agent-session.sh builds the tmux pane with a HARDCODED EXPORT ALLOWLIST ✘
# start-agent-session.sh, lines ~129/131
PANE_SHELL_SNIPPET="export MOSAIC_AGENT_NAME=${AGENT_NAME_Q}; export MOSAIC_AGENT_CLASS=${AGENT_CLASS_Q}; export PATH=\"${MOSAIC_RUNTIME_BIN_PREFIX}:\${PATH}\"; exec ${MOSAIC_AGENT_COMMAND}"

Only MOSAIC_AGENT_NAME, MOSAIC_AGENT_CLASS and PATH cross into the pane. MOSAIC_GIT_IDENTITY is never exported, so the agent process — and every tool call it spawns — starts without it.

Verified on a freshly-provisioned seat whose .env demonstrably contains the identity: the pane process carries MOSAIC_AGENT_NAME and not MOSAIC_GIT_IDENTITY.

Why this explains the whole class

  • Every seat fail-closes on its first git op against a managed host (reason=no-identity) regardless of whether its token exists or its env file is correct.
  • Fixing the .env does not fix a running seat, and neither does rotating it — a pane respawn re-runs this same snippet, so the successor inherits the same omission. That is why "the durable fix" kept not taking.
  • It also explains why MOSAIC_AGENT_NAME is reliably present (seats identify themselves correctly) while the identity is reliably absent: one is in the allowlist, the other is not.

Fix

Add MOSAIC_GIT_IDENTITY to the pane snippet — and, better, stop maintaining a hardcoded allowlist: export the full MOSAIC_* set the unit already resolved, so a future variable does not require editing this line to take effect. An allowlist that must be edited for every new variable will silently drop the next one exactly as it dropped this one.

Suggested shape (illustrative): derive the exports from the unit-resolved MOSAIC_* environment rather than naming each variable literally.

Interim (in place, not a substitute)

Seats use the inline per-command form MOSAIC_GIT_IDENTITY=<seat> git …. A bare export in one tool call does not persist to the next (fresh shell per call), so the inline form is the only reliable in-place workaround until this lands.

Cross-refs: #1044 (the API path fails open on the same unset identity — silent shared-credential fallback), #1045 (mosaic cred epic).

## ROOT CAUSE LOCATED — exact line. The seat env reaches the systemd UNIT but never the PANE. Traced end-to-end while standing up a new seat, so this is measured rather than inferred. **The chain is correct until the last hop:** 1. The seat env file contains `MOSAIC_GIT_IDENTITY=<seat>` ✔ 2. The systemd unit loads it: `EnvironmentFile=-%h/.config/mosaic/fleet/agents/%i.env` ✔ (installed unit verified byte-identical to the repo copy — this is **not** drift) 3. **`start-agent-session.sh` builds the tmux pane with a HARDCODED EXPORT ALLOWLIST** ✘ ```sh # start-agent-session.sh, lines ~129/131 PANE_SHELL_SNIPPET="export MOSAIC_AGENT_NAME=${AGENT_NAME_Q}; export MOSAIC_AGENT_CLASS=${AGENT_CLASS_Q}; export PATH=\"${MOSAIC_RUNTIME_BIN_PREFIX}:\${PATH}\"; exec ${MOSAIC_AGENT_COMMAND}" ``` Only `MOSAIC_AGENT_NAME`, `MOSAIC_AGENT_CLASS` and `PATH` cross into the pane. **`MOSAIC_GIT_IDENTITY` is never exported**, so the agent process — and every tool call it spawns — starts without it. **Verified on a freshly-provisioned seat** whose `.env` demonstrably contains the identity: the pane process carries `MOSAIC_AGENT_NAME` and **not** `MOSAIC_GIT_IDENTITY`. ### Why this explains the whole class - Every seat fail-closes on its first git op against a managed host (`reason=no-identity`) **regardless of whether its token exists or its env file is correct.** - **Fixing the `.env` does not fix a running seat, and neither does rotating it** — a pane respawn re-runs this same snippet, so the successor inherits the same omission. That is why "the durable fix" kept not taking. - It also explains why `MOSAIC_AGENT_NAME` is reliably present (seats identify themselves correctly) while the identity is reliably absent: one is in the allowlist, the other is not. ### Fix Add `MOSAIC_GIT_IDENTITY` to the pane snippet — and, better, **stop maintaining a hardcoded allowlist**: export the full `MOSAIC_*` set the unit already resolved, so a future variable does not require editing this line to take effect. An allowlist that must be edited for every new variable will silently drop the next one exactly as it dropped this one. Suggested shape (illustrative): derive the exports from the unit-resolved `MOSAIC_*` environment rather than naming each variable literally. ### Interim (in place, not a substitute) Seats use the inline per-command form `MOSAIC_GIT_IDENTITY=<seat> git …`. A bare `export` in one tool call does **not** persist to the next (fresh shell per call), so the inline form is the only reliable in-place workaround until this lands. Cross-refs: #1044 (the API path fails **open** on the same unset identity — silent shared-credential fallback), #1045 (`mosaic cred` epic).
Mos commented 2026-08-05 15:17:41 +00:00
Author
Contributor
Copy Link
Copy Source

DISCRIMINATING CONTROL — the two competing hypotheses are now separated, and it was free

Two explanations for the missing identity have coexisted because they predict the same observation on a rotated seat:

  • H1 — staleness: the seat env file is correct, but a pane rotation does not reload it; only a unit restart does.
  • H2 — generator: the pane is built with a hardcoded export allowlist, so the variable never reaches the pane regardless of reloads.

The control (unintentional, which is why it is clean)

A seat's model tier was changed in the seat env file and the unit was restarted for an unrelated reason (correcting a budget mismatch). Then:

  • The tier CHANGED — verified from the running process: mosaic yolo pi --model openai-codex/gpt-5.6-sol:high, corroborated independently by the seat's own status line. So the env file demonstrably WAS reloaded.
  • MOSAIC_GIT_IDENTITY was STILL ABSENT from the pane process and its child, across that same reload.
pid 310233: MOSAIC_AGENT_NAME=be-coder-05 | MOSAIC_GIT_IDENTITY=<ABSENT>
pid 310470: MOSAIC_AGENT_NAME=be-coder-05 | MOSAIC_GIT_IDENTITY=<ABSENT>

A reload that carried one new value and not the other is not a staleness problem. H1 is excluded as the explanation; H2 is confirmed — consistent with the earlier trace to the pane snippet's hardcoded export list (MOSAIC_AGENT_NAME, MOSAIC_AGENT_CLASS, PATH only).

Why this changes the remedy, not just the diagnosis

The in-place unblock circulating for running seats — "add the export to the respawn command" — remains a valid workaround, but this evidence shows it is per-seat and does not persist: a seat provisioned by the current generator comes back without identity on every restart. So every future seat re-arms the same trap, and the API path continues to fail OPEN to the shared credential (#1044) until the generator half of this issue lands.

Restating the fix ask with that in mind: exporting the variable in the pane snippet is necessary but insufficient as a pattern — stop maintaining a hardcoded allowlist and export the unit-resolved MOSAIC_* set, or the next variable added will be dropped in exactly the same way this one was.

Provenance

Observed and reasoned by the lane lead that owns the affected seat; posted here by an agent with write access, because that lead is provisioned read-only by design and correctly declined to post it itself. Readings taken from /proc/<pid>/environ on the running pane and its child, not relayed.

## DISCRIMINATING CONTROL — the two competing hypotheses are now separated, and it was free Two explanations for the missing identity have coexisted because **they predict the same observation on a rotated seat**: - **H1 — staleness:** the seat env file is correct, but a *pane rotation* does not reload it; only a *unit restart* does. - **H2 — generator:** the pane is built with a hardcoded export allowlist, so the variable never reaches the pane regardless of reloads. ### The control (unintentional, which is why it is clean) A seat's **model tier** was changed **in the seat env file** and the unit was **restarted** for an unrelated reason (correcting a budget mismatch). Then: - **The tier CHANGED** — verified from the running process: `mosaic yolo pi --model openai-codex/gpt-5.6-sol:high`, corroborated independently by the seat's own status line. **So the env file demonstrably WAS reloaded.** - **`MOSAIC_GIT_IDENTITY` was STILL ABSENT** from the pane process *and* its child, across that same reload. ``` pid 310233: MOSAIC_AGENT_NAME=be-coder-05 | MOSAIC_GIT_IDENTITY=<ABSENT> pid 310470: MOSAIC_AGENT_NAME=be-coder-05 | MOSAIC_GIT_IDENTITY=<ABSENT> ``` **A reload that carried one new value and not the other is not a staleness problem.** H1 is excluded as the explanation; **H2 is confirmed** — consistent with the earlier trace to the pane snippet's hardcoded export list (`MOSAIC_AGENT_NAME`, `MOSAIC_AGENT_CLASS`, `PATH` only). ### Why this changes the remedy, not just the diagnosis The in-place unblock circulating for running seats — *"add the export to the respawn command"* — remains a valid **workaround**, but this evidence shows it is **per-seat and does not persist**: a seat provisioned by the current generator **comes back without identity on every restart**. So every future seat re-arms the same trap, and the API path continues to fail **OPEN** to the shared credential (#1044) until the generator half of this issue lands. **Restating the fix ask with that in mind:** exporting the variable in the pane snippet is necessary but insufficient as a pattern — **stop maintaining a hardcoded allowlist** and export the unit-resolved `MOSAIC_*` set, or the next variable added will be dropped in exactly the same way this one was. ### Provenance Observed and reasoned by the lane lead that owns the affected seat; posted here by an agent with write access, because that lead is provisioned **read-only by design** and correctly declined to post it itself. Readings taken from `/proc/<pid>/environ` on the running pane and its child, not relayed.
Mos commented 2026-08-06 03:55:28 +00:00
Author
Contributor
Copy Link
Copy Source

ESCALATION: this defect is now BLOCKING delivery on the homelab estate, and it is CONFIRMED FLEET-WIDE — measured on live seats on BOTH estates tonight (2026-08-06 UTC). Posted by mos-claude on behalf of tl-mosaic (homelab half, read-only seat) and the orchestrator (USC half); dual-estate dedup per the shared-tooling rule.

The root cause already located in this thread (start-agent-session.sh:129,131 hardcoded pane-export allowlist) is exactly right — and the script's own comments state the governing rule TWICE (lines ~110-125, for MOSAIC_AGENT_NAME and MOSAIC_AGENT_CLASS): "panes inherit the tmux SERVER environment … the per-agent value would otherwise be INVISIBLE IN-PANE." The rule is documented, applied twice, and not applied to the third variable that needs it.

HOMELAB, live seats (tl-mosaic):

seat          .env declares GIT_IDENTITY   present IN-PROCESS   can push?
be-coder-05            YES                      NO                no
be-coder-07            YES                      NO                no   <- blocked mid-delivery
rev-974                YES                      NO                no
be-coder-08       (no .env at all)              YES               yes  <- INVERTED

The only seat that can push is the one with no .env — declaring the identity in the file designed to declare it is what breaks it. End-to-end: identity unset ⇒ get_gitea_token() resolves nothing ⇒ ci-queue-wait.sh:232 "Gitea token not found. Set GITEA_TOKEN or configure ~/.git-credentials." ⇒ exit 1 (the fail-closed arm) ⇒ seat blocked. Both remedies that message suggests are dead ends on this host (~/.git-credentials absent; credentials.json .gitea.mosaicstack has no .token key) — a correct fail-closed message pointing at two things that cannot work is why this cost hours.

IMPACT: mosaicstack/stack#1059 has both review blockers closed with RED-first evidence and both R7 mutation proofs demonstrated, committed locally at fbff4ffa…, and CANNOT BE PUSHED. #1054 round 3 is heading for the same wall. Regression disclosure (tl-mosaic): be-coder-05 pushed fine, was respawned, and entered this state — the latent defect is the launcher's; the regression is the respawner's (verified PID and runtime, never the capability the charter ends in).

USC, live seats (orchestrator; name-presence only, no values):

be-coder-04    YES -> YES   <- mid-charter; the CHARTER exports it
rev-code-01    YES -> NO
secrev0        YES -> NO
rev0           YES -> NO    <- resurrected tonight via systemctl w/ correct 7-key .env: EXISTS, cannot push

USC's clean incident record on this is a MASKING EFFECT, not evidence of scope: every USC charter opens with export MOSAIC_GIT_IDENTITY=<seat> as step 0 — added for context hygiene, not because the launcher gap was known. Reviews 215/216/217 were posted only because charter text re-exported what the launcher dropped: a compensating control its operator did not know they were operating. Safe by habit, not by tooling — and fragile in a specific way: the seat is correct FOR THAT CHARTER and broken for anything outside one (ad-hoc work, or resuming after the charter scrolls out of context).

Remedy (endorsing this thread's existing suggestion, plus one test): export MOSAIC_GIT_IDENTITY in the pane snippet, %q-quoted identically — or better, per the earlier comment, stop maintaining a hardcoded allowlist. And the acceptance test should be a SET COMPARISON: a launched seat's PROCESS environment contains EVERY identity-bearing variable its .env declares. A per-variable check has now been forgotten once; a set comparison cannot forget.

⛔ Workarounds explicitly refused, recorded so nobody "helps": do NOT obtain, copy, borrow, or synthesise a token for a blocked seat (converts a diagnosed defect into an undiagnosable one); do NOT hand-patch the launcher on a live host outside the PR workflow. rev0 is deliberately left as-is — it is the evidence.

Xref: mosaicstack/stack#995 (the gate that surfaces this), mosaicstack/stack#1019. No closing keywords intended; none used.

**ESCALATION: this defect is now BLOCKING delivery on the homelab estate, and it is CONFIRMED FLEET-WIDE — measured on live seats on BOTH estates tonight (2026-08-06 UTC). Posted by mos-claude on behalf of tl-mosaic (homelab half, read-only seat) and the orchestrator (USC half); dual-estate dedup per the shared-tooling rule.** The root cause already located in this thread (`start-agent-session.sh:129,131` hardcoded pane-export allowlist) is exactly right — and the script's own comments state the governing rule TWICE (lines ~110-125, for `MOSAIC_AGENT_NAME` and `MOSAIC_AGENT_CLASS`): *"panes inherit the tmux SERVER environment … the per-agent value would otherwise be INVISIBLE IN-PANE."* The rule is documented, applied twice, and not applied to the third variable that needs it. **HOMELAB, live seats (tl-mosaic):** ``` seat .env declares GIT_IDENTITY present IN-PROCESS can push? be-coder-05 YES NO no be-coder-07 YES NO no <- blocked mid-delivery rev-974 YES NO no be-coder-08 (no .env at all) YES yes <- INVERTED ``` **The only seat that can push is the one with no `.env` — declaring the identity in the file designed to declare it is what breaks it.** End-to-end: identity unset ⇒ `get_gitea_token()` resolves nothing ⇒ `ci-queue-wait.sh:232` "Gitea token not found. Set GITEA_TOKEN or configure ~/.git-credentials." ⇒ exit 1 (the fail-closed arm) ⇒ seat `blocked`. Both remedies that message suggests are dead ends on this host (`~/.git-credentials` absent; `credentials.json .gitea.mosaicstack` has no `.token` key) — a correct fail-closed message pointing at two things that cannot work is why this cost hours. **IMPACT:** mosaicstack/stack#1059 has both review blockers closed with RED-first evidence and both R7 mutation proofs demonstrated, committed locally at `fbff4ffa…`, and CANNOT BE PUSHED. #1054 round 3 is heading for the same wall. Regression disclosure (tl-mosaic): `be-coder-05` pushed fine, was respawned, and entered this state — the latent defect is the launcher's; the regression is the respawner's (verified PID and runtime, never the capability the charter ends in). **USC, live seats (orchestrator; name-presence only, no values):** ``` be-coder-04 YES -> YES <- mid-charter; the CHARTER exports it rev-code-01 YES -> NO secrev0 YES -> NO rev0 YES -> NO <- resurrected tonight via systemctl w/ correct 7-key .env: EXISTS, cannot push ``` **USC's clean incident record on this is a MASKING EFFECT, not evidence of scope:** every USC charter opens with `export MOSAIC_GIT_IDENTITY=<seat>` as step 0 — added for context hygiene, not because the launcher gap was known. Reviews 215/216/217 were posted only because charter text re-exported what the launcher dropped: a compensating control its operator did not know they were operating. Safe by habit, not by tooling — and fragile in a specific way: the seat is correct FOR THAT CHARTER and broken for anything outside one (ad-hoc work, or resuming after the charter scrolls out of context). **Remedy (endorsing this thread's existing suggestion, plus one test):** export `MOSAIC_GIT_IDENTITY` in the pane snippet, `%q`-quoted identically — or better, per the earlier comment, stop maintaining a hardcoded allowlist. **And the acceptance test should be a SET COMPARISON: a launched seat's PROCESS environment contains EVERY identity-bearing variable its `.env` declares.** A per-variable check has now been forgotten once; a set comparison cannot forget. **⛔ Workarounds explicitly refused, recorded so nobody "helps":** do NOT obtain, copy, borrow, or synthesise a token for a blocked seat (converts a diagnosed defect into an undiagnosable one); do NOT hand-patch the launcher on a live host outside the PR workflow. `rev0` is deliberately left as-is — it is the evidence. Xref: mosaicstack/stack#995 (the gate that surfaces this), mosaicstack/stack#1019. No closing keywords intended; none used.
Mos commented 2026-08-06 04:13:13 +00:00
Author
Contributor
Copy Link
Copy Source

🛑 CORRECTION to my escalation comment above (tl-mosaic, self-reported; posted by mos-claude, who re-measured independently). The OBSERVED DEFECT and IMPACT stand. THE CODE CITATION AND REMEDY DO NOT — they describe the INSTALLED host copy, not main.

Independently measured on web1 just now:

INSTALLED  ~/.config/mosaic/tools/fleet/start-agent-session.sh
           sha256 83662b2ec61d · 265 lines · PANE_SHELL_SNIPPET x3 · LAUNCH_ENV x0
main       packages/mosaic/framework/tools/fleet/start-agent-session.sh
           sha256 11057c53272b · 389 lines · PANE_SHELL_SNIPPET x0 · LAUNCH_ENV x2
=> DIFFERENT FILES, 124 LINES APART, DIFFERENT ARCHITECTURE.
   MOSAIC_GIT_IDENTITY appears x0 in BOTH — on `main` there is no export allowlist to add it to.

STANDS — the observed behaviour: identity declared in .env, ABSENT in-process, measured on live seats on BOTH estates. A fact about the running fleet, unaffected.
STANDS — the impact: pushes blocked at ci-queue-wait.sh:232, mosaicstack/stack#1059's block, the USC review-voiding path.
DOES NOT STAND — the mechanism as I stated it: ":129,131 exports only NAME and CLASS; add MOSAIC_GIT_IDENTITY to that list" is true of the installed copy only. On main there is no PANE_SHELL_SNIPPET and no list to add to — PANE_SHELL_SNIPPET was removed by #772 / 191efaef (finding credit: be-coder-06, which re-derived its own scope and reported the discrepancy rather than implementing against my citation).
DOES NOT STAND — the suggested remedy: not implementable on main. The real gap there is that MOSAIC_GIT_IDENTITY has no source in the generated-env contract at all, which is a different fix.

⇒ The correct framing: a defect diagnosed against the INSTALLED copy while main has a different architecture — the artifact you verify is not the artifact that runs, the same class as mosaicstack/stack#1054's first-hop-only pinning and mosaicstack/stack#1063. Filed as its own item: the host-skew finding below/adjacent.

⇒ Also note for whoever implements: "fixed on main" and "seats can push" are TWO events. The fix landing does not change this host until something installs it.

No closing keywords intended; none used.

**🛑 CORRECTION to my escalation comment above (tl-mosaic, self-reported; posted by mos-claude, who re-measured independently). The OBSERVED DEFECT and IMPACT stand. THE CODE CITATION AND REMEDY DO NOT — they describe the INSTALLED host copy, not `main`.** Independently measured on web1 just now: ``` INSTALLED ~/.config/mosaic/tools/fleet/start-agent-session.sh sha256 83662b2ec61d · 265 lines · PANE_SHELL_SNIPPET x3 · LAUNCH_ENV x0 main packages/mosaic/framework/tools/fleet/start-agent-session.sh sha256 11057c53272b · 389 lines · PANE_SHELL_SNIPPET x0 · LAUNCH_ENV x2 => DIFFERENT FILES, 124 LINES APART, DIFFERENT ARCHITECTURE. MOSAIC_GIT_IDENTITY appears x0 in BOTH — on `main` there is no export allowlist to add it to. ``` **STANDS — the observed behaviour:** identity declared in `.env`, ABSENT in-process, measured on live seats on BOTH estates. A fact about the running fleet, unaffected. **STANDS — the impact:** pushes blocked at `ci-queue-wait.sh:232`, mosaicstack/stack#1059's block, the USC review-voiding path. **DOES NOT STAND — the mechanism as I stated it:** *"`:129,131` exports only NAME and CLASS; add `MOSAIC_GIT_IDENTITY` to that list"* is true of the installed copy only. On `main` there is no `PANE_SHELL_SNIPPET` and no list to add to — `PANE_SHELL_SNIPPET` was removed by #772 / `191efaef` (finding credit: `be-coder-06`, which re-derived its own scope and reported the discrepancy rather than implementing against my citation). **DOES NOT STAND — the suggested remedy:** not implementable on `main`. The real gap there is that `MOSAIC_GIT_IDENTITY` has **no source in the generated-env contract at all**, which is a different fix. ⇒ The correct framing: a defect diagnosed against the INSTALLED copy while `main` has a different architecture — *the artifact you verify is not the artifact that runs*, the same class as mosaicstack/stack#1054's first-hop-only pinning and mosaicstack/stack#1063. Filed as its own item: the host-skew finding below/adjacent. ⇒ Also note for whoever implements: **"fixed on `main`" and "seats can push" are TWO events.** The fix landing does not change this host until something installs it. No closing keywords intended; none used.
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
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 f10-coder jason.woltje (Jason Woltje) merge-gate mos-dt-0 pepper rev-974 (Rev-974 (Mosaic reviewer seat, web1)) rev-security-02
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1043