spawn_agent reports FAILURE while creating a live, working agent — boot prompt typed but not submitted

[EtanHey]

Etan caught this live in the golemsflip lead's pane, 2026-08-14. Not previously filed.

spawn_agent({repo:"golems", cli:"codex", role:"worker", effort:"high", force_new:true}) returned a hard error:

{"ok":false,
 "error":"Boot prompt delivery failed after 258 chars: Enter submit could not be verified for surface:855 within 5000ms",
 "delivered":false,"terminal":false,"typed":true,
 "submit_attempted":true,"submit_verified":false,
 "submit_verification_reason":"input_still_pending","retry_safe":false,
 "agent_id":"golemsCodex-4db3349d","surface_id":"surface:855","workspace_id":"workspace:1",
 "delivered_chars":258}

But the agent was created, booted, and is now working. Verified minutes later:
surface:855 → agent_type:"codex", status:"working", control_state:"busy", model:"gpt-5.6-sol high", actively reading files in ~/Gits/golems. The boot text was sitting in the composer unsubmitted at the moment of the error, and went through afterwards.

Why this is a defect, not a cosmetic message

This is the same family as the #409 B1 blocker — side effects commit while the call reports failure — on the spawn path:

• The caller is told the spawn failed. A live worker exists anyway.
• With force_new:true, a lead that retries gets a second agent. The natural response to "failed" is exactly the wrong action.
• retry_safe:false is present and correct, which is the only thing preventing this from being worse — but it is a field buried in an error payload whose headline says the operation failed.

The receipt fields themselves are honest (typed:true, submit_verified:false, delivered:false) — that is the #404/#409 contract working. The bug is the framing: a partially-successful operation is reported as a total failure.

Suggested

ok:true with an explicit unsubmitted state, since the agent genuinely exists: return the identity triple plus something like boot_prompt: {typed:true, submitted:false} and a named next action ("the agent is live; its brief is typed but unsent — resend or press Return"). Reserve ok:false for spawns where no agent was created. The caller needs to distinguish "nothing happened, retry" from "an agent exists, finish delivering to it" — today it cannot.

Likely contributing cause

delivered_chars: 258 and the composer contents show the payload that failed to submit was the mailbox contract preamble, not the task brief — the same verbose boot text filed in #400. A shorter boot payload would reduce exposure to this 5000ms verification window, though it would not fix the framing.

Related

#400 (boot-prompt verbosity), #409 B1 (side effects commit while call reports failure), ledger #20/#21 (paste-no-submit class).

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

[EtanHey]

Still live on v0.4.48 — with a twist: the receipt is HONEST, the engine is not

spawn_agent({repo:"cmuxlayer", cli:"codex", worktree:{reuse:true}, boot_prompt_path:"…lane-497-iterate-brief.md"})
2026-08-20 07:20Z:

Boot prompt delivery failed after 223 chars: Timed out after 60000ms waiting for boot prompt
submit evidence on surface:539
typed:true  submit_attempted:true  submit_verified:false
submit_verification_reason:"working_status_not_observed"  retry_safe:false

Unlike the original #415 report, this receipt is correct. read_screen(surface:539) showed
status:"idle", control_state:"ready", and the pointer sitting UNSENT in the composer:

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

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

Both lines typed, neither submitted. One manual send_to({mode:"key", key:"return"}) started the
work immediately (control_state → busy).

So the failure is not verification here — it is the boot Return never being pressed. The engine
typed 223 chars and then waited 60s for working status that could not arrive, because nothing
submitted. retry_safe:false leaves the caller with a spawned, named, idle worker that will sit
there forever unless a human or lead notices and presses Return. That is the same silent-idle-worker
outcome as #415 even though the receipt told the truth this time.

Two asks:

1. Press the Return. After typing the boot pointer, submit it — and if submit evidence does not
   appear, retry the Return before failing (send_to succeeds on exactly that Return one call later).
2. retry_safe should be true here. The surface exists, the agent is idle, nothing has run;
   re-sending is safe and is exactly the recovery the caller needs.

Note the pointer is two paragraphs (prompt line + contract line, blank line between). #500 and the
multi-paragraph submit guard are both in this neighbourhood — worth checking whether the blank line
is what stops the boot Return.

Reproduced on package.json version 0.4.48.

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