fix(codex-bridge): give the identity lease a start token on Windows

[joelmitz]

Fixes #977.

The codex bridge could not start on Windows at all: startToken() had two
sources and Windows satisfies neither, so writeLease() failed closed on an
empty token every time and the launcher respawned it into the same wall.

/proc/<pid>/stat   ENOENT
ps -o lstart=      ps: unknown option -- o

The fail-closed is correct (#906) — the missing Windows source is what this adds:
Process.StartTime.Ticks through PowerShell, in both codex-bridge.js
startToken() and codex-bridge-launcher.sh _start_token, with pwsh admitted
to the lease schema.

One source, not a preference list

WMIC's CreationDate is ~2x cheaper (0.36 s vs 0.83 s measured) and was the
first implementation. It is dropped, and not because WMIC may be missing: a
per-side "WMIC, else PowerShell" order lets the writer and the reaper resolve
different sources for the same process whenever only one of them can reach
wmic.exe, and their tokens differ by format — so the reaper reads a live
bridge's lease as another process's. Reproduced with wmic shadowed on one side:

node: src=wmic token=20260824045224.102163+540
bash: src=pwsh token=639231439441021632

powershell.exe → pwsh fallback is safe where WMIC was not: both return
identical Ticks for a pid, so the src label names the format, not the binary.

The Windows branch replaces the /proc branch rather than preceding it

MSYS/Cygwin expose a working /proc, but it is keyed by their own pid space
while the lease records the Windows process.pid, so preferring it would return
an unrelated process's start time with nothing to signal it. Measurements in #977.

Tests

Six cases against _read_lease — the reaper's only gate on a lease, so its
accept/reject set is the contract that widening proc|ps to proc|ps|pwsh
changes. Exercised directly, the way tests/test_remote.bats already does for
_remote_endpoint_display, rather than through the reaper: that path needs a
spawnable bridge and a live pid, which is what does not work under Git Bash
(#567) and has nothing to do with the schema.

Two detect the change; four are guards. Stated as a table rather than a pass
count so a reviewer checking it finds the same thing:

case	with the change	without it
a pwsh lease parses	ok	fails
windows-native: a live pid yields an integer pwsh token	ok	fails
a pwsh token that is not an integer is rejected	ok	ok
an unrecognised startsrc is rejected (wmic included)	ok	ok
proc/ps still parse; proc non-numeric still rejected	ok	ok
POSIX: a live pid yields a proc or ps token	ok	ok

wmic is in the rejection case deliberately, not as an arbitrary bad value: it
pins the decision above, so reintroducing WMIC fails loudly.

Only the case that runs PowerShell carries windows-native in its name, so it
lands on that leg; the rest carry no marker and run everywhere. The two
platform-specific cases complement each other — on either leg one runs and the
other skips.

Verification

• Windows 11 26200 / MINGW64 / node 22 (win32) / codex-cli 0.149.0: the six cases
  pass; re-run against the parent commit's codex/ tree, the two
  change-detecting cases fail as tabled
• Linux (Bats 1.14.0 from a clone): the five non-windows-native cases pass and
  the mutation check reproduces. Run independently on a separate machine by a
  second person, not a re-run of the Windows box
• End to end on Windows: the bridge starts, publishes
  start=639231452158110466 startsrc=pwsh, and a message sent to the role drives
  a turn and gets an answer. Before this change the same sequence produced only
  the token error

Not verified

• bats tests/ green on Windows. That is not achievable and is not new: the
  workflow shards the suite over [ubuntu-latest, macos-latest] only, and the
  Windows leg runs filter: "windows-native". The full file has never been
  expected to pass under Git Bash
• launcher: windows-native starts the bridge (#567) fails on our Windows
  machine with and without this change. It asserts the half of codex bridge on Windows: port-detection liveness probe asks tasklist about an MSYS pid, so it always aborts on iteration 1 #567 that is not
  fixed: the parent-liveness probe asks tasklist about an MSYS pid, and the two
  pid spaces are disjoint (tasklist finds winpid 19568 only; kill -0 finds
  MSYS pid 3994449 only). The workflow already lists windows runtime (#567)
  among its known intermittent reds
• macOS is not covered by our own runs; the POSIX branches are untouched, but
  that is an argument, not a measurement

Unrelated flake, for context

tests/test_codex_bridge_launcher.bats flakes under full-suite load on Linux
independently of this change: baseline produced the same not ok 17 on one of
three full runs, and the failing test moves between runs, while single-test runs
were green 3/3 on both. We are not claiming equal rates — the run count is far
too small — only that the same failure occurs without this change.

[masa6161]

Verified on Windows — #977 resolved

Tested on Windows 11 (26200) / MINGW64_NT-10.0-26200 (MSYS2 Git Bash) / Node 22 / PowerShell 5.1 + 7.

Applied this PR on top of upstream/main (e127b06, v1.2.3 + #1004).

startToken unit

Method	pid	Ticks	Time
JS (process.pid)	43328	639241363342246505	439 ms
Shell (/proc/$$/winpid)	43184	639241363375719470	292 ms

Both return valid integers via (Get-Process -Id <pid>).StartTime.Ticks.

bats (test_codex_bridge_launcher.bats)

PR #978 added tests 30–35: 5 pass + 1 skip (test 34 is POSIX-only, correctly skipped).

Existing tests: 14 pass / 19 fail / 2 skip — matches the upstream/main baseline (12 pass / 16 fail / 1 skip). The 3 flipped tests (bound-thread #350, windows-native starts #567, active storage override) were re-run 3× on both branches and confirmed as non-deterministic on Windows/MSYS2 (consistent with #1000). No regression from this PR.

Bridge real startup

SKILL_DIR=<repo> node codex-bridge.js --team pr978-test --name bridge-tester \
  --app-server ws://127.0.0.1:1 --max-wakes 0

• startToken passed, lease written with startsrc=pwsh / start=639236168498489351
• Reached connect ECONNREFUSED (expected — dummy app-server), exit 0
• No orphan processes

Multi-agent E2E (monitor mode)

Ran a 3-seat codex fan-out (implementer / reviewer / verifier) with this PR applied. All 3 bridges started cleanly, leases acquired with startsrc=pwsh, 4-hop message relay completed with zero manual intervention. No bridge proliferation observed.

[NNK-github]

Additional Windows measurement, one code-level note, and a scope remark — from an independent local fix of the same failure (#977), written before we found this PR.

Environment. Windows 11, Git for Windows 2.55 (MSYSTEM=MINGW64), node 24.19, codex-cli 0.153.4, agmsg main at 948b100 (v1.2.3-21). Codex launched through codex-monitor.sh directly (no shell function / PATH shim).

Reproduction of #977 on this base. Every bridge spawn exited at startup with cannot determine process start token for identity lease (5 attempts per launcher pass, then the spawn-rate cap). Cause as described in #977: ps -o is not available in Git for Windows' ps (ps: unknown option -- o), and a native node.exe has no entry in the MSYS /proc.

Measured with a local patch of the same shape as this PR (PowerShell Get-Process -Id <pid> in both startToken() and _start_token, Windows branch checked before /proc, _read_lease accepting the new source label):

• the bridge starts and publishes its lease; the app-server spawns watch-once.sh under Git Bash;
• idle delivery: a message sent while the Codex TUI was idle became a new turn and the reply came back in ~13 s;
• mid-turn delivery: a message sent during a running turn (sleep 90) was held and delivered ~7 s after the turn ended (turn/completed arrived; the idle watchdog was not needed).

Separately, after adding our local Windows reaper changes (see the scope remark below), three cleanup runs with delivery.sh set off codex <project> left no monitored processes running. These results do not validate this PR alone.

Test condition worth stating: the project already had a role-session record from an earlier session, so the launcher first bound the bridge to that stale thread. Because _reap_orphan_bridges still returns early under MSYSTEM (#458), the stale bridge was stopped by hand for the delivery checks above; a first session in a fresh project would not hit this.

One untested concern on the token expression. StartTime.Ticks represents local time. Could changes to time-zone settings or conversion rules affect token stability between observations? Since the token is also used as evidence of process identity and replacement (the writer publishes it once; the launcher re-reads it later to match a lease and to prove a killed pid is gone), a UTC-based representation such as StartTime.ToFileTimeUtc() or StartTime.ToUniversalTime().Ticks would make that invariant explicit. I have not reproduced a mismatch; this comes from reading the two code paths. Either way, the startsrc label naming the format (as this PR does with pwsh) is the right shape — our local label differs, and I would align to whatever this PR settles on.

Scope remark. With this PR merged, a Windows bridge can start, but _reap_orphan_bridges still returns early under MSYSTEM, so a bridge bound to a stale thread is never replaced there (the launcher waits for an exit proof that only the reaper can produce). We have a local reaper for Windows that keeps the lease checks intact (enumerate via Win32_Process command lines in the Windows pid space, verify host/project/pairs/pid and the start token, then kill through one held Process handle after re-reading the token through it, WaitForExit as the exit proof; a lookup failure defers the tick instead of reading as "gone"). It also needed the lease's project hash compared in the Windows spelling (path.resolve gives D:\... while the launcher hashes /d/...). Measured: replacement in ~6 s after the seat changed, no lingering watch-once. Not included here; happy to open it as a follow-up on top of this PR once the token format is settled. Note that I have not yet rebased it onto this PR's format, so "it applies on top" is expectation, not a verified statement.

Related discussion I read while doing this: #458 (pid spaces), #996 (liveness / absence / unknown contract), #149 (TUI exit leaves the bridge). I am not treating any of them as a blocker for this PR; they are context for the follow-up.

[fujibee]

@joelmitz

Thanks for this, and for the detailed measurements — and thanks to @masa6161 and @NNK-github for the independent Windows verification.

The three macOS failures on the CI run (lease schema admits a pwsh start token, proc and ps leases still parse, a live pid yields a proc or ps start token on POSIX) are not the change itself: the macOS runner's /bin/bash is 3.2, and its $( ) mis-parses the { } inside the quoted sed script in _run_start_token / _lease_verdict, so the launcher functions never get evaled (the log shows sed: 1: "/^_agmsg_is_windows() / ...": invalid command code /). It reproduces locally with PATH=/bin:$PATH bats --filter "lease schema|leases still parse|proc or ps start token" tests/test_codex_bridge_launcher.bats and does not with bash 5.

Moving the pattern out of the command substitution fixes it on both bash 3.2 and 5.x:

diff --git a/tests/test_codex_bridge_launcher.bats b/tests/test_codex_bridge_launcher.bats
index 5c2761e..7973669 100644
--- a/tests/test_codex_bridge_launcher.bats
+++ b/tests/test_codex_bridge_launcher.bats
@@ -715,7 +715,8 @@ _lease_verdict() { # <startsrc> <start> -> prints accept|reject
   printf 'v=1\nproject=%s\npairs=%s\nhost=h\npid=123\nstart=%s\nstartsrc=%s\n' \
     "$h40" "$h40" "$2" "$1" > "$TEST_SKILL_DIR/lease-under-test"
   bash -c '
-    eval "$(sed -n "/^_read_lease() {/,/^}/p" "$1")"
+    pattern="/^_read_lease() {/,/^}/p"
+    eval "$(sed -n "$pattern" "$1")"
     _read_lease "$2" && echo accept || echo reject
   ' _ "$LAUNCHER" "$TEST_SKILL_DIR/lease-under-test" 2>/dev/null
 }
@@ -751,7 +752,8 @@ _lease_verdict() { # <startsrc> <start> -> prints accept|reject
 
 _run_start_token() { # <pid> -> runs _start_token in a subshell
   run bash -c '
-    eval "$(sed -n "/^_agmsg_is_windows() {/,/^}/p;/^_start_token() {/,/^}/p" "$1")"
+    pattern="/^_agmsg_is_windows() {/,/^}/p;/^_start_token() {/,/^}/p"
+    eval "$(sed -n "$pattern" "$1")"
     _start_token "$2"
   ' _ "$LAUNCHER" "$1"
 }

If you can fold that into the branch, the remaining reds on the run are the known intermittent ones (#937, #567) and we can re-run CI. The Windows-side change itself looks right to us.

[fujibee]

@joelmitz

One more thing from a closer read: the new _agmsg_is_windows() matches uname -s against MINGW*|MSYS*|CYGWIN*, while the launcher's existing $MSYSTEM check a few lines below also treats CLANGARM* as Windows. On a clangarm64 MSYS2 the new branch would therefore fall through to the /proc path — the exact pid-space mix-up the change is designed to avoid. Adding CLANGARM* to that case keeps the two checks consistent.

[joelmitz]

Addressed both review comments in 489fb4a51018166f9e134085759b139bd0021c05:

• moved the two sed programs out of command substitutions before eval, matching the suggested Bash 3.2-compatible form;
• added CLANGARM* to _agmsg_is_windows();
• added a regression test proving a CLANGARM64_NT-* uname selects the PowerShell start-token path.

Verification on Linux:

• targeted four tests: 4/4 pass;
• bash -n scripts/drivers/types/codex/codex-bridge-launcher.sh: pass;
• git diff --check: pass;
• enforced-assertion check: baseline unchanged at 638.

The full launcher Bats file also exercised all 34 cases: 30 passed, 2 Windows-only cases skipped, and 2 known intermittent #937 cases failed. Re-running those two alone produced 2/2 pass twice, then 1/2 pass on the third run, consistent with the existing intermittent behavior. The four tests relevant to this update remained green.