Windows (Git Bash): codex bridge respawns every few seconds and old bridges accumulate — launcher and bridge record the pidfile in different PID namespaces

[chemica-tan]

Environment

• agmsg v1.1.10, Windows 11, Git for Windows 2.53 (MSYS2 runtime), Node 22, codex CLI 0.144.5 (npm)
• Repro'd with a single TUI: delivery.sh set monitor codex <project> → shim-launched
  codex → $agmsg actas <role> as the first turn
• Mechanism re-verified against current main (3f87d60) — all code paths cited below are present there

Observed

Within ~2 minutes of the bridge arming:

• a new codex-bridge.js process was spawned every ~7–15 s (launcher backoff cadence),
• none of the old ones were ever killed — 13 live bridges at the 2-minute mark,
  every one of them subscribed (duplicate-delivery risk),
• run/codex-bridge.<team>.<role>.log shows one resumed thread … / armed … pair per
  respawn,
• the pidfile value alternates between two kinds of numbers (large MSYS pids and
  native Windows pids — see below),
• delivery.sh status reports the armed bridge as stale,
• delivery.sh set off cannot kill the live bridges (it believes they are already
  dead and only removes their run files).

The only reason this stays bounded in practice is the bridge's own exit-on-close:
when the TUI quits and the app-server goes away, every accumulated bridge exits on
websocket close. During a long session, the count grows without limit.

(Full respawn timeline / bridge-log excerpts available on request — happy to attach.)

Root cause

The bridge pidfile is written in two different PID namespaces:

writer	value	namespace
launcher, right after spawn (codex-bridge-launcher.sh:324-325 — launched_pid=$! → pidfile)	nohup's $!	MSYS
bridge, on startup (codex-bridge.js writeMeta() — process.pid)	node's pid	native Windows

Every reader then checks liveness in its own namespace only:

• the launcher's reuse check does kill -0 "$bridge_pid" — Git Bash kill only sees
  MSYS pids, so once writeMeta() has overwritten the pidfile with the native pid,
  the check is permanently false. The launcher concludes the bridge is dead,
  removes the pidfile (without killing anything — it "knows" the process is gone)
  and spawns a replacement. Repeat forever: that is the accumulation.
• the bridge's ensureSingleInstance() does process.kill(existing, 0) — node uses
  native pids, so the MSYS pid the launcher recorded raises ESRCH, the guard clears
  the "stale" files and proceeds. The single-instance defence is bypassed in the
  other direction, which is why the replacements never refuse to start. (The Fix Codex bridge self-PID restart loop #444
  self-PID clause doesn't engage here: on Windows the launcher's $! is an MSYS pid
  and never equals the bridge's own process.pid, so the guard always lands in the
  ESRCH branch.)
• stop_codex_bridge() in delivery.sh and the status probe in codex _delivery.sh
  use the same bare kill -0, hence the wrong status output and the no-op set off.

On Linux/macOS $! and process.pid live in the same namespace, so the double write
is harmless — this is Windows-only.

Relation to known issues:

• Codex monitor bridge enters rapid restart loop with codex-cli 0.144.6 #442 / Fix Codex bridge self-PID restart loop #444 (v1.1.10): the macOS rapid-restart loop was the suicide variant —
  the bridge died on its own reservation, so processes never accumulated. This is
  the Windows sibling with the opposite failure mode: the guard is bypassed
  (ESRCH on the MSYS pid), so replacements start and old bridges survive. The Fix Codex bridge self-PID restart loop #444
  fix does not cover it because the namespace split survives the self-PID check.
• delivery.sh status reports 'stale pidfile' for a live bridge on Windows (MSYS kill -0 cannot see native node PIDs) #415 already reported the same kill -0 blindness on the status path
  (stale pidfile for a live bridge). What's new here is that the launcher's reuse
  check shares that blind probe, which escalates a cosmetic status bug into a
  respawn/accumulation loop, and that set off inherits it too (it removes the run
  files of bridges it silently failed to kill). A fix for this issue should resolve
  delivery.sh status reports 'stale pidfile' for a live bridge on Windows (MSYS kill -0 cannot see native node PIDs) #415's kill -0 symptom as a side effect. (Note: on Windows, status has a
  second, independent false-stale layer in the metadata compare that fires before
  the pid probe — filed separately as delivery.sh status (Windows): verbatim metadata project compare labels every live bridge "stale pidfile (metadata mismatch)" — a second false-stale layer independent of #415 #459.)
• Windows/Git Bash: agmsg_agent_pid never resolves (MSYS ppid walk cannot cross into native processes) — cc-instance.* is never written, actas locks always GC as stale, despawn reports no-live-lock #371 is the same MSYS↔native namespace blindness in the opposite direction
  (the MSYS ppid walk cannot cross into native processes). Different code path,
  same underlying fact: on Git for Windows, MSYS tools and native Node do not
  share a PID namespace, and any pid that crosses that boundary unconverted is
  invisible to the other side.
• The codebase already contains the precedent for the correct probe:
  _agmsg_pid_alive() in lib/instance-id.sh (added for Windows compatibility: malformed JSON in delivery.sh + actas_lock_sid_alive() always false #134) falls back to
  tasklist on Windows exactly because of this blindness — the bridge lifecycle
  paths just don't use it.

Suggested fix (happy to send a PR)

Unify the pidfile on the native namespace and reuse the existing helpers:

1. launcher: record _compat_get_winpid "$!" (from lib/compat.sh) instead of $!
   on MSYS; keep $! for wait. Measured on Git for Windows 2.53 with the default
   native Node: the WINPID of $! is the bridge's own process.pid (the MSYS
   "exec" of a native binary maps the MSYS pid to the exec'd child), so the record
   converges with what writeMeta() publishes and ensureSingleInstance()'s
   existing self-PID clause keeps working unchanged. (Non-default wrappers/shims
   would need their own verification.) If the WINPID mapping cannot be resolved,
   fail closed — never publish a raw MSYS pid, since every reader would judge it
   permanently dead.
2. liveness via _agmsg_pid_alive; teardown via taskkill /PID <pid> /T /F on
   MSYS (tree kill also reaps the leftover MSYS exec stub), plain kill elsewhere.
3. stop_codex_bridge() / the launcher reuse check / codex _delivery.sh status:
   same helpers, plus a cmdline identity check before killing (matching the idiom
   the app-server teardown already uses). A live pid whose cmdline cannot be read
   right now (transient CIM failure) must be treated conservatively — neither
   killed nor forgotten — or the failure path quietly re-creates the accumulation.

Off Windows, the pid-conversion paths are MSYS-gated and _agmsg_pid_alive
degrades to kill -0, so the default node …/codex-bridge.js path behaves as
before; the added cmdline identity guard is the one behavioral addition there
(it declines to kill a live pid it cannot attribute to the bridge).

Validation of the fix (we run it downstream)

We have been running this fix on the same Windows machine since 2026-07-20:

• a single bridge stayed stable for the whole observation window — 14 samples over
  3.5 minutes at 15 s intervals, zero respawns (the one pid change observed was
  Codex bridge reuses a live bridge attached to the wrong thread #350's designed rebind when the role-session record arrived, not a respawn);
  a second session showed 90 s from launch with no respawn at all,
• delivery.sh set off now reports Stopped 1 Codex bridge process(es) and the
  process is verifiably gone (tasklist confirms),
• status reports alive (pid N) for the live bridge (this also needs the
  metadata-compare fix from delivery.sh status (Windows): verbatim metadata project compare labels every live bridge "stale pidfile (metadata mismatch)" — a second false-stale layer independent of #415 #459 on Windows),
• accumulation has not re-appeared across multiple sessions.

Happy to turn this into a PR if that's welcome. It should also resolve the
kill -0 side of #415, assuming no further publication-order edge cases surface
in that flow.

[masa6161]

Independent confirmation on a second Windows 11 machine, plus some additional evidence. (I filed #471 for the same defect before finding this report — closed as duplicate; moving the extra evidence here.)

Confirmation — agmsg v1.1.10 (installed skill, mechanism re-checked against current main sources), Windows 11 (10.0.26200), Git Bash (MSYS2 runtime 3.4.7, bash 5.2.15), codex-cli 0.144.6, node v24.14.1, single codex role via codex-monitor.sh + real app-server: strictly monotonic growth to 15 live bridges in 3m56s (~17 s cadence), none ever killed, all armed on the same role. Fully consistent with your 13-in-2-minutes observation.

Live capture of the pidfile namespace alternation (0.5 s polling; kill -0 = what the launcher's reuse check sees, winpid = ground truth via Get-Process):

11:55:40 pidfile=32392 kill-0:FAIL winpid:ALIVE   <- bridge's writeMeta (native pid)
11:55:49 pidfile=29412 kill-0:OK   winpid:none    <- launcher's $! (MSYS pid)
11:56:00 pidfile=62296 kill-0:FAIL winpid:ALIVE
11:56:05 pidfile=30335 kill-0:OK   winpid:none
11:56:17 pidfile=42608 kill-0:FAIL winpid:ALIVE
11:56:22 pidfile=31320 kill-0:OK   winpid:none

Each kill-0:FAIL value equals the newest live bridge's process.pid (verified against the process list), i.e. the writeMeta overwrite is exactly what flips the reuse check to permanently false.

Codex-free minimal reproduction — one fake team registration + a hand-written role-session record + a stub WebSocket server standing in for the app-server, then the unmodified launcher in role-child mode: one child, zero external state changes, one new bridge per ~5 s (6 live after 40 s). A bash -x trace shows every cycle is written pid != read-back pid -> kill -0 ESRCH -> rm pidfile -> nohup replacement. The cycle period tracks how long the fingerprint/identity resolution takes: ~5 s in the stub setup, ~17 s real single-role, ~25 s on a loaded 3-role session (26 bridges in 4 min) — which brackets your ~7-15 s. Happy to share the harness if useful.

Two data points supporting fix step 1 (record _compat_get_winpid "$!"):

• On our setup too, /proc/$!/winpid of the nohup-launched bridge equals the bridge's own process.pid (measured repeatedly; the MSYS exec of the native binary maps the MSYS pid onto the exec'd child). So the launcher's record converges with writeMeta()'s, as you predict.
• Control experiment: kill / kill -0 on the MSYS $! of a nohup'd native node works correctly from the same shell, from a different bash process, and after the launching shell has exited — the failure really is only the namespace of the number stored in the pidfile, not MSYS signal delivery per se.

One more downstream effect worth noting for the teardown part of the fix: force-killing the accumulated bridges leaves their watch-once.sh children orphaned (30+ stray bash processes in our cleanup). Your suggested taskkill /PID <pid> /T /F tree-kill addresses exactly this — +1 to that shape.

The proposed fix direction (reusing _agmsg_pid_alive / _compat_get_winpid, fail-closed when the WINPID cannot be resolved) looks right to us, and cleaner than what we had sketched independently. Glad to test a PR on this machine.