planning: confirm round.sh stop leaves no watch.sh running on Windows Git Bash #5723

Activity

1. kyle-sexton

   added

   priority: lowNice-to-have, cosmetic, or speculative; opportunistic.Nice-to-have, cosmetic, or speculative; opportunistic.

   needs-humanHuman-in-the-loop required; autonomous sessions must not resolve items carrying this.Human-in-the-loop required; autonomous sessions must not resolve items carrying this.

   on Oct 1, 2026
2. kyle-sexton

   added a commit that references this issue on Oct 1, 2026

   feat(planning): interview watcher stop, restatement diff and page pol…

   ...

   864fb61
3. kyle-sexton commented on Oct 1, 2026

   

   kyle-sexton

   on Oct 1, 2026

   MemberAuthor

   More actions

   Windows Git Bash run, 2026-10-01. The first criterion holds. The second does not: one of the two watch.test.sh cases it names fails on Windows, and the cause is the test, not watch.sh. This issue stays open.

   Where and what

   • Host: melo-desk-001, native Windows 11 (build 26200). Git for Windows 2.55.0 (MINGW64_NT-10.0-26200, bash 5.3.15, curl 8.21.0), Python 3.14.7.
   • Code: origin/main at 038c2ae22 (includes feat(planning): interview watcher stop, restatement diff and page polish #5722). I copied plugins/planning out of git into a scratch folder, so the host's own checkout, which is behind main, was not touched.
   • How it was launched: bash.exe from Git for Windows, started from the WSL lane through interop. It is not a Claude Code Bash tool session. The processes are the same Windows ones.
   • Data dir: a throwaway folder under the sandbox, C:/Users/KyleSexton/claude-lane-sandbox/drain-20261001/5723-data.

   1. Operator steps: pass

   I ran the issue's steps as written (ensure-running --port 0, watch.sh in the background, ps -ef | grep -E 'watch\.sh|curl', round.sh stop, sleep 10, the same ps, wait). I also listed the Windows processes by command line, because Git Bash's ps shows only part of them.

   Before round.sh stop (watcher armed, long-poll open). The token is redacted:

   $ ps -ef | grep -E 'watch\.sh|curl'
   AzureAD+  197255  197235 ?  16:44:32 "C:\Program Files\Git\mingw64\bin\curl.exe" -s -w \n%{http_code} --noproxy * --max-time 100 -H "X-Interview-Token: <token>" http://127.0.0.1:60103/api/wait?after=handled&replayed=0&timeout=90&watcher=melo-desk-001-197214&pid=197235
   AzureAD+  197235  197214 ?  16:44:31 bash watch.sh /c/Users/KyleSexton/claude-lane-sandbox/drain-20261001/5723-data
   
   Windows view (command lines naming watch.sh, curl, round.py, server.py or the data dir):
    59212 ppid=8624   python.exe: ...\python.exe ...\plugins\planning\surface\server.py --dir C:\Users\KyleSexton\claude-lane-sandbox\drain-20261001\5723-data --port 0 --nonce 0639a4c4c384773a
     6804 ppid=27964  bash.exe: "C:\Program Files\Git\usr\bin\bash.exe" watch.sh /c/Users/KyleSexton/claude-lane-sandbox/drain-20261001/5723-data
    31312 ppid=6804   bash.exe: "C:\Program Files\Git\usr\bin\bash.exe" watch.sh /c/Users/KyleSexton/claude-lane-sandbox/drain-20261001/5723-data
    44348 ppid=31312  curl.exe: "C:\Program Files\Git\mingw64\bin\curl.exe" -s -w \n%{http_code} --noproxy * --max-time 100 -H "X-Interview-Token: <token>" http://127.0.0.1:60103/api/wait?...
   

   Then bash round.sh --dir "$d" stop printed stopped 59212 and took 2 seconds. The watcher was already gone 0.1 seconds after stop returned. Ten seconds after stop returned:

   $ ps -ef | grep -E 'watch\.sh|curl'
   (no output)
   
   Windows view: none
   

   The watch.sh process exited 3, and watch.err held the interview server was stopped (round.sh stop): not re-arming. So after round.sh stop on Windows, no watch.sh and no curl long-poll was left, and the refused-poll path worked as designed.

   2. bash watch.test.sh: 26 pass, 1 fail

   ok: round.sh stop stops the server
   ok: round.sh stop ended the data dir's watch.sh
   FAIL: watch.sh kept retrying after a clean stop
   PASS=26 FAIL=1
   

   "round.sh stop ended the data dir's watch.sh" passes. "watch.sh exits 3 at once on a refused poll after a clean stop" does not: its case (o) fails with the message above.

   Cause: the test, not watch.sh. Case (o) removes the env file, then stops the server with kill "$spid", where $spid is the pid the server wrote to .interview-session.json. On Windows that is a native Windows pid, and Git Bash's kill only knows its own process numbers. I reproduced the case by hand:

   • kill 42680 (the server's native pid) printed kill: (42680) - No such process. The server kept running and answered HTTP 200, so the watcher's poll kept succeeding and watch.sh never took its refused-poll branch.
   • Bash's built-in kill rejects -f, and /usr/bin/kill -f <native pid> also printed "No such process".
   • taskkill //F //PID 10708 (the server's native pid) with the env file removed, same as the test: watch.sh exited 3 with the interview server was stopped (round.sh stop): not re-arming, inside the 10 second window.

   So the refused-poll behavior holds on Windows Git Bash. The test fails because it cannot kill the server there.

   What this leaves

   • Criterion 1 (no watch.sh or curl left within 10 s, exit 3 with the stop message): met.
   • Criterion 2 (watch.test.sh passes on that host): not met, for the test defect above.
   • Criterion 3 (result posted): this comment. I did not open the README PR, because the suite is not green yet.

   Next step is a code change, not another host run: make case (o) in plugins/planning/surface/watch.test.sh kill the server by native pid on Windows (for example taskkill //F //PID "$spid" when uname -s is MINGW* or MSYS*, kill elsewhere), keeping the POSIX path as is. Then re-run bash watch.test.sh on a Windows host. If it is 27 of 27, a PR can replace the README sentence "That path has not been exercised on Windows Git Bash." with the behavior verified above.
4. kyle-sexton

   closed this as completedin #5748on Oct 1, 2026
5. kyle-sexton

   removed

   needs-humanHuman-in-the-loop required; autonomous sessions must not resolve items carrying this.Human-in-the-loop required; autonomous sessions must not resolve items carrying this.

   on Oct 1, 2026