Summary
delivery.sh status <... codex ...> reports "watch processes: 0 alive" for a Codex project even when the Codex monitor bridge is alive and armed. The line counts only the Claude Code watch.sh pidfiles — it has no awareness of the Codex bridge (codex-bridge.<team>.<name>.pid/meta). For Codex the count is therefore always 0, which reads as "monitor is dead."
This is not cosmetic: it actively causes misdiagnosis. A Codex agent (and the user) running $agmsg mode / delivery.sh status sees watch processes: 0 alive, N stale pidfiles, concludes the monitor never started, and goes chasing PATH / shim / restart problems — when the bridge was actually up and delivering the whole time.
Repro (observed 2026-06-17, oma/main-co, zeals/omakase-dev-cs)
$ delivery.sh status codex <project>
mode: monitor
watch processes: 0 alive, 15 stale pidfiles
Yet at the same moment:
codex-bridge.js --project .../omakase-dev-cs --type codex (pid 4480) alivewatch-once.sh armed for oma/main-co (polling unread)- bridge log:
started turn / turn completed on thread 019ed26e…
- a fresh test message produced
wakeup + started turn → delivered live into the TUI
So the bridge was healthy; only the status line lied.
Root cause
delivery.sh status enumerates run/watch.<sid>.pid (Claude Code watchers) and reports their liveness. Codex monitor doesn't use watch.sh; it uses the app-server bridge with run/codex-bridge.<team>.<name>.pid (+ .meta, .log) and an armed watch-once.sh. The status code path never looks at those.
Proposed fix
When type == codex, status should report the bridge instead of (or in addition to) the watcher count:
- Resolve identities for the project, and for each
<team>/<name> read run/codex-bridge.<team>.<name>.pid; print bridge: alive (pid …) / armed thread … from the pid + .meta + last .log line, or bridge: not running.
- Suppress / relabel the Claude
watch processes line for Codex so it cannot be read as "monitor dead."
- Bonus: surface "armed / waiting" vs "no watch-once" so a stuck bridge is distinguishable from a healthy idle one.
Related
#41 (Codex monitor bridge), #153 (launcher/request-file redundancy), #151 (enable-needs-restart). Also recorded in the bridge design notes as a known landmine ("status counts Claude watch.sh only → misleading for Codex").
Summary
delivery.sh status <... codex ...>reports "watch processes: 0 alive" for a Codex project even when the Codex monitor bridge is alive and armed. The line counts only the Claude Codewatch.shpidfiles — it has no awareness of the Codex bridge (codex-bridge.<team>.<name>.pid/meta). For Codex the count is therefore always 0, which reads as "monitor is dead."This is not cosmetic: it actively causes misdiagnosis. A Codex agent (and the user) running
$agmsg mode/delivery.sh statusseeswatch processes: 0 alive, N stale pidfiles, concludes the monitor never started, and goes chasing PATH / shim / restart problems — when the bridge was actually up and delivering the whole time.Repro (observed 2026-06-17, oma/main-co, zeals/omakase-dev-cs)
Yet at the same moment:
codex-bridge.js --project .../omakase-dev-cs --type codex(pid 4480) alivewatch-once.sharmed foroma/main-co(polling unread)started turn/turn completed on thread 019ed26e…wakeup+started turn→ delivered live into the TUISo the bridge was healthy; only the status line lied.
Root cause
delivery.sh statusenumeratesrun/watch.<sid>.pid(Claude Code watchers) and reports their liveness. Codex monitor doesn't usewatch.sh; it uses the app-server bridge withrun/codex-bridge.<team>.<name>.pid(+.meta,.log) and an armedwatch-once.sh. The status code path never looks at those.Proposed fix
When
type == codex, status should report the bridge instead of (or in addition to) the watcher count:<team>/<name>readrun/codex-bridge.<team>.<name>.pid; printbridge: alive (pid …) / armed thread …from the pid +.meta+ last.logline, orbridge: not running.watch processesline for Codex so it cannot be read as "monitor dead."Related
#41 (Codex monitor bridge), #153 (launcher/request-file redundancy), #151 (enable-needs-restart). Also recorded in the bridge design notes as a known landmine ("status counts Claude watch.sh only → misleading for Codex").