A fix for a Windows regression shipped in 1.1.12. If you run agmsg with codex through Git Bash, real-time delivery has not worked since that release: codex fell back to launching plain codex, with no error and no bridge. Claude Code monitor watchers on Windows were affected by the same defect class. macOS and Linux are unaffected.
Reported by NNK-github in #567, with an xtrace that pinned the mechanism to the iteration it broke on, and re-verified on the same Windows machine after the fix landed.
What was wrong
1.1.12 routed every process-liveness check through one helper whose Windows branch asks tasklist, which can only see Windows-side process ids. Most of the pids this codebase probes are minted by bash itself — $!, $$, or read back from a pidfile one of our own shells wrote — and those live in the MSYS pid space, which tasklist can never see. Every such check answered "dead": the codex monitor tore its own app-server down at launch, and watcher lifecycle checks misfired the same way.
What 1.1.13 does
-
The liveness helper is split by where a pid was minted. Pids this codebase created use a shell-local probe (EPERM-aware, with a
pscross-check); pids reached by walking ancestors out of the MSYS subsystem keep the Windows-side probe. All 29 call sites were audited: 18 moved, 11 stayed, each with its reason recorded. Because the two are now separate functions, the wrong probe can no longer be reached by reading past a comment. (#582, #584) -
Windows is now covered by CI. Before this release the Windows leg ran only the install helpers, so nothing in the suite ever executed the Windows runtime path — which is why a 100%-reproducible break shipped. A new job runs the real
codex-monitor.shandcodex-bridge-launcher.shunder Git Bash and asserts both that the bridged handoff is reached and that the launcher goes on to start the bridge. Reverting either call site fails exactly one of them. This is the first release in which delivery on Windows was observed by CI rather than assumed. (#584) -
Codex session seating no longer guesses from rollout history. It required exactly one matching rollout file, which a project used more than once can never satisfy — so on any worked-in project the seat was never written and the bridge never armed. The monitor now asks the app-server which threads it has loaded and subtracts the ones a role already sits in; a unique remainder is recorded, anything else records nothing.
delivery.sh statusalso tells "this role has no seat" apart from "the process is not running", which it previously reported identically. (#583, #579) -
That seating fix could not fire under codex 0.146
--remote. In that mode the agent's shell command runs inside the app-server process, which cannot carry the environment variable naming the app-server — the variable does not exist until after the app-server has been spawned. The monitor now reconstructs the address from the port file it already writes. It is the same string, not an alternative destination, and the port file is written atomically so a reader can never observe a partial one. (#591)
Known limit
The seat subtraction needs at least one recorded seat to subtract. On a machine where the app-server is already holding several threads and no seat has ever been written — the state an upgrade lands in — the count stays ambiguous and nothing is recorded until the app-server is recreated. Once one seat exists it stays consistent. Recreating it deliberately: delivery.sh set off codex <project> then delivery.sh set monitor codex <project> — note this also stops the other codex bridges for that project. Tracked in #579.
1.1.13 - 2026-08-01
Fixed
- Resolve the app-server from the port file when the variable is absent (#591)
- Route every shell-minted pid through the local probe (#567) (#584)
- Seat a role from the app-server's loaded threads, not rollout files (#583)
- Probe the app-server with the local-pid helper, not the tasklist one (#567) (#582)