submit_verified:true is a FALSE POSITIVE on boot — agent shows 0 tokens with the prompt still sitting in its composer

[EtanHey]

Two independent reproductions, two machines, same shape. This breaks the one receipt field that was verified as never-wrong in the #409 review.

Evidence A — M1 Pro, mimirClaude surfaces 4 and 5, both panes

spawn_agent returned:

"boot_prompt_receipt": {
  "delivered": true, "terminal": true, "typed": true,
  "submit_attempted": true, "submit_verified": true,
  "delivery": "submitted", "delivery_state": "submitted", "bytes": 369
}

The panes at that moment:

› Read and follow /Users/happycampr/Gits/mimir/docs.local/plans/…/S1-HYGIENE-BRIEF.md
  cmuxlayer mailbox contract for mimirClaude-e9f217f8: monitor with tail -n0 -F …
                                                                        0 tokens
  Fable 5 | $0.00 | 0m

Prompt still in the composer. 0 tokens. $0.00. 0m. The agent never processed anything. Both surfaces, independently.

Evidence B — this Mac, surface:1068, ~90 minutes earlier

Same: spawn_agent reported the boot prompt submitted; the pane showed › Res[Pasted Content 1038 chars] unsubmitted. Distinguishing detail captured there: an MCP server (computer-history) timed out after 30 seconds during boot, and the codex banner showed MCP startup incomplete.

Why this is worse than the earlier receipt bugs

submit_verified: true is the strong claim — it is supposed to mean the composer was observed to clear. The #404/#409 work made the weak fields honest and the #409 reviewer explicitly verified "a delivered:true receipt was never wrong — zero false positives on the strong claim, under every adversarial condition I could build." These are counter-examples, and they were not reachable by that reviewer's method because they require a slow real boot, not a constructed screen.

Consequence in practice: a lead spawns a worker, gets a fully-verified receipt, walks away — and the worker sits at 0 tokens forever with its entire brief unsent. That is the "spawned worker idle with its whole assignment unsent" failure we have hit repeatedly, now with a mechanism.

Likely mechanism

A boot-timing race: the submit verification window elapses while the CLI is still initialising (MCP servers connecting, banner rendering), so the check inspects a composer that is not yet in its post-submit state and reads that as success. It is not machine-specific — the M1 case had no MCP timeout in view, so slow boot alone appears sufficient.

The cheap discriminator we should be using

0 tokens is definitive. An agent that was handed a prompt and has consumed zero tokens did not receive it, whatever the receipt says. Token count is already parsed and displayed (read_screen returns token_count). Post-boot verification should require evidence of consumption — a nonzero token count or an observable turn start — not merely a composer that looks clear.

Suggested

1. Boot-prompt verification must not accept a composer state observed before the CLI is ready; gate it on readiness, not on elapsed time.
2. Require positive evidence of consumption (token_count > 0, or a parsed turn start) before emitting submit_verified: true for a boot prompt.
3. Add a probe that spawns against a deliberately slow boot (stall an MCP server) and asserts the receipt does not claim verified while the prompt sits unsent. The existing tests cannot catch this — they do not boot a real slow CLI.

Related: #415 (spawn reports failure while creating a live agent — the mirror of this), #424 (prompt_text bloat, visible in the same receipt), skillcreator's defect #1 (3 occurrences reported 2026-08-13).

— cmuxlayerClaude (lead) · claude-code/claude-opus-5

[EtanHey]

Live on v0.4.50: boot_prompt_submit_verified:true while the prompt sits unsent in the composer

Two spawns, ~20 minutes apart, both on v0.4.50 (the build that fixed #500):

spawn_agent({repo:"cmuxlayer", cli:"codex", worktree:{reuse:true},
             boot_prompt_path:".../lane-496-round8-brief.md"})
→ boot_prompt_delivered: true
  boot_prompt_receipt: { delivered:true, terminal:true, typed:true,
                         submit_attempted:true, submit_verified:true,
                         delivery:"submitted", delivery_state:"submitted", bytes:222 }

read_screen immediately after, on surface:571:

status: "idle"   control_state: "ready"

› Read and follow /Users/etanheyman/Gits/cmuxlayer/docs.local/tasks/lane-496-round8-
  brief.md

  cmuxlayer contract for cmuxlayerCodex-4a37806a: Read and follow …/contract.md

Both lines typed, neither submitted, agent idle. One manual
send_to({mode:"key", key:"return"}) started it (control_state → busy).

This is the exact inverse of the bug just fixed. #500 was a false FAILURE on a delivery that landed;
this is a false SUCCESS on a delivery that did not. delivery_state:"submitted" is a terminal claim
the engine did not observe — the same shape #483 exists to forbid, on the one path where nobody is
watching, because the caller has just spawned and moved on.

Why it is worse than the #415 variant: #415 at least reported failure
(working_status_not_observed, retry_safe:false), so a lead knew to look. Here the receipt says
submitted, so a lead that trusts it walks away and the worker sits idle forever with its brief in
the composer. I only caught it because I now read the screen after every spawn.

Frequency, honestly: not every spawn. Earlier today on this same build a throwaway Codex spawn
receipted submit_verified:true and genuinely WAS working, verified by screen
(• PROBE_READY). So this is intermittent, and the difference I can see between the two is payload
size and shape — the working one was a single short inline prompt; the failing ones were
boot_prompt_path pointers, which send TWO paragraphs (pointer line, blank line, contract line).
That blank-line/multi-paragraph shape is the same neighbourhood as the multi-paragraph submit guard,
and worth checking first.

Ask: verify the boot submit the way #503 taught key mode to verify — by an observed state
transition (idle → working), not by the send returning. If no transition is observed within the
window, receipt it as nonterminal and RETRY the Return; send_to({mode:"key"}) succeeds on exactly
that Return one call later, every time I have done it.

Observed twice on v0.4.50, agents cmuxlayerCodex-4a37806a (surface:571) and
cmuxlayerCodex-67b3b5a6 (surface:543, earlier build-identical spawn).

— cmuxlayerClaude (lead) · claude-code/claude-opus-5