crew send reports 'not delivered' for messages that were actually delivered — false negative recommends a harmful re-send

[tu11aa]

Symptom

squadrant crew send reports delivery failure for messages that were in fact delivered and submitted.

Observed twice on 2026-08-05, same session, same crew (tmpl-contract, opencode):

$ squadrant crew send squadrant tmpl-contract "<multi-line review feedback>"
Message not delivered to crew 'tmpl-contract' — the paste/submit could not be confirmed.
Re-send with 'squadrant crew send squadrant tmpl-contract'.

Both times, reading the crew screen immediately afterward showed the crew actively working the delivered content:

$ squadrant crew read squadrant tmpl-contract
  ⠋ Thinking: Addressing Specific Issues
  I'm focusing on those four key issues. I've got to commit the changes to the
  crew/tmpl-contract branch first. Secondly, I'm working on #653 item 4...

The message landed and submitted. Only the confirmation was wrong.

Why this matters

The advice in the failure message is "re-send". Following it would deliver the same instruction twice — for a review-feedback message that means a duplicate work run, and for anything non-idempotent it is worse. The captain has to spot-read the crew screen to find out whether the report was true, which defeats the point of having a confirmation.

A false negative here is more dangerous than no confirmation at all, because it actively recommends a harmful recovery action.

Notes

• Both instances were multi-line messages (~6-10 lines). A short single-line follow-up sent between them confirmed cleanly. Possible correlation with paste-mode handling — cf. BUG: crew DONE → captain Enter sometimes inserts newline instead of submitting (intermittent, not yet reproduced) #339 (paste-strand: paste → settle → separate Enter) and Daemon-direct delivery silently drops an undelivered terminal event (CREW DONE) when daemon restarts >5min after it was enqueued (stale-skip) #474 (delivery confirmation).
• Crew agent was opencode; not yet checked whether claude/codex crews show the same behaviour.
• Not reproduced deliberately — this is a report from live use with the screen evidence above, not a controlled repro. A repro harness would want to vary message length and agent.

Suggested direction

Either make the confirmation trustworthy, or — if the signal is inherently unreliable for multi-line pastes — stop recommending a blind re-send and instead direct the operator to verify via squadrant crew read before deciding.

[tu11aa]

More evidence — 4 occurrences on 2026-08-05, and the multi-line hypothesis is weaker than first reported

The original report speculated the false negative correlates with multi-line messages. Two further occurrences on crew tmpl-audit (also opencode) show that is at best incomplete:

• Occurrence 3: multi-line review feedback → reported not-delivered, actually delivered.
• Occurrence 4: single-line message (~250 chars, no newlines) → still reported not-delivered, actually delivered.

So message shape is not a sufficient explanation. All four occurrences were opencode crews; claude/codex still untested.

Useful detail: the screen shows QUEUED

Reading the crew screen right after occurrence 4:

  ┃  review.
  ┃   QUEUED

The message had been accepted and queued by the agent while the CLI was reporting delivery failure. That suggests the confirmation check is looking for a submitted/echoed state and does not recognise the queued state as success — i.e. it may be a timing/state-recognition bug in the confirmation probe, not a delivery bug at all. Delivery appears to work every time; only the observation of it fails.

If that holds, the fix is likely in the acceptance predicate rather than the send path — and QUEUED (or whatever the equivalent is per agent) should count as delivered.

Operational impact, restated

Across one session a captain saw 4/4 sends reported as failures while 4/4 actually succeeded. A confirmation with a 100% false-negative rate in this session is worse than none, because the printed advice is to re-send.

[tu11aa]

Note for scope: #667 proposes adopting Claude Code's new cross-session messaging (v2.1.224+) as a real delivery channel with documented delivered/held/refused receipts — which would eliminate this false-negative class on the claude path only.

It does not fix this issue. Cross-session messaging is Claude Code only, and this is the opencode path — which is also our current crew default. #667 is explicitly gated on building it behind an AgentDriver capability seam so we don't repeat the v0.13.3 Claude-only mistake one layer down. This stays open and separately prioritised.

[tu11aa]

Reproduced live 2026-08-13 with the marker visible, captain → opencode crew.

squadrant crew send returned:

Message not delivered to crew 'config-perms' — the paste/submit could not be confirmed.
Re-send with 'squadrant crew send squadrant config-perms'.

A crew read immediately after showed the message present in the crew's input, rendered with a QUEUED marker below it. It was delivered; only the confirmation failed. Happened on 2/2 sends in the same session.

This is the predicate gap named in the #514/#657 analysis: confirmedSendToPane (packages/workspaces/src/crew-pane.ts) infers delivery from box empty + paste seen, and opencode's post-submit state is neither — it renders QUEUED with the text still on screen. So the predicate reads a successful submit as a failure.

Two notes for whoever picks this up:

1. The recommended recovery in the error string is actively harmful. Re-sending here would have queued the message twice. The remediation text should not advise a blind re-send while the false negative exists.
2. QUEUED looks like a usable positive signal for opencode, but opencode crew: first-turn silently dropped — false-positive 'delivered' from splash-marker drift (residual of #235) #499 is the cautionary tale — that fix broke because a marker glyph (… vs ASCII ...) never matched. If QUEUED is adopted, pin it to opencode's actual emitted bytes and add a test that fails when the marker drifts, rather than trusting a literal.

[tu11aa]

Two more live occurrences today (2026-08-17), captain → opencode crews, both false negatives:

squadrant crew send squadrant slice1-liveness "..."
→ Message not delivered to crew 'slice1-liveness' — the paste/submit could not be confirmed.

squadrant crew send squadrant slice2-channel "..."
→ Message not delivered to crew 'slice2-channel' — the paste/submit could not be confirmed.

Both messages did arrive. Verified by crew read immediately after: each crew was already acting on the content of the message it was reported not to have received (slice1 was inspecting the exact resolve() lines the message flagged; slice2 was reading the spec's open-unknowns table the message asked it to record).

Had I followed the CLI's own remediation ('Re-send with ...'), both crews would have received duplicate instructions mid-task.

Environment: opencode 1.18.18, squadrant 0.18.1, crews running in isolated worktrees.

Relevant to #667 slice 2: this is exactly the pane/channel disagreement that shadow mode is built to count. The control channel's probe() would have returned reachable for both sessions while the pane path reported not-delivered — i.e. a DISAGREEMENT — pane=not delivered, channel=deliverable log line. Two data points toward the evidence-based shadow→on cutover.