Summary
When spawning multiple sub-sessions in quick succession via `agent-deck add` + `agent-deck session start` + `agent-deck session send `, some prompts are silently dropped: `session send` returns success but the inner Claude session never receives the input and sits idle.
Reproducer
I spawned three sub-sessions in close succession with these prompt sizes:
| Sub-session |
Prompt size |
Got prompt? |
| Session 1 |
~3 KB |
yes |
| Session 2 |
~7 KB |
no — silently dropped |
| Session 3 |
~2 KB |
no — silently dropped |
Notably the smallest prompt (~2 KB) and the largest (~7 KB) both failed while the middle-sized prompt succeeded — so the failure mode isn't a strict size threshold. My hypothesis is a timing race between `session send` writing to the inner TTY and the inner Claude becoming ready to read from it, but I have not instrumented to confirm.
Version
`Agent Deck v1.7.71` (the docker contexts I have available make upgrading awkward, so this is what's reproduced; happy to retry on latest if you want).
Workaround (works reliably)
Materialize the prompt as a file and send only a short pointer:
```bash
PROMPT_FILE="/tmp/${SUB_TITLE}-prompt.md"
cat > "$PROMPT_FILE" <<'PROMPT'
PROMPT
agent-deck session send "" "Your full brief is at $PROMPT_FILE — read it and proceed."
```
The pointer is small enough to deliver reliably, and the inner Claude reads the file once it processes the message.
Suggestions
Either:
- Document the issue and the workaround in agent-deck's docs.
- Have `session send` block until the inner process is reading from the pipe (so callers can trust send-success means delivery-success).
- Have `session send` return a queryable receipt (so callers can verify delivery without parsing transcripts).
Why this matters for callers
Silent drops are hard to detect — `session send` returns ✓, the session shows as running, but no work happens. Callers have to learn to verify via `session output` after every send, which is friction the workaround above also imposes. A documented contract or a fixed delivery guarantee would make multi-session orchestration more robust.
Filed as a follow-up to a coordination session where I lost ~10 minutes of confused debugging before the user pointed out the workaround.
Summary
When spawning multiple sub-sessions in quick succession via `agent-deck add` + `agent-deck session start` + `agent-deck session send `, some prompts are silently dropped: `session send` returns success but the inner Claude session never receives the input and sits idle.
Reproducer
I spawned three sub-sessions in close succession with these prompt sizes:
Notably the smallest prompt (~2 KB) and the largest (~7 KB) both failed while the middle-sized prompt succeeded — so the failure mode isn't a strict size threshold. My hypothesis is a timing race between `session send` writing to the inner TTY and the inner Claude becoming ready to read from it, but I have not instrumented to confirm.
Version
`Agent Deck v1.7.71` (the docker contexts I have available make upgrading awkward, so this is what's reproduced; happy to retry on latest if you want).
Workaround (works reliably)
Materialize the prompt as a file and send only a short pointer:
```bash
PROMPT_FILE="/tmp/${SUB_TITLE}-prompt.md"
cat > "$PROMPT_FILE" <<'PROMPT'
PROMPT
agent-deck session send "" "Your full brief is at $PROMPT_FILE — read it and proceed."
```
The pointer is small enough to deliver reliably, and the inner Claude reads the file once it processes the message.
Suggestions
Either:
Why this matters for callers
Silent drops are hard to detect — `session send` returns ✓, the session shows as running, but no work happens. Callers have to learn to verify via `session output` after every send, which is friction the workaround above also imposes. A documented contract or a fixed delivery guarantee would make multi-session orchestration more robust.
Filed as a follow-up to a coordination session where I lost ~10 minutes of confused debugging before the user pointed out the workaround.