codex monitor never arms when a project has more than one past session: the role-session seat it requires can no longer be written

[pipumin]

On a project that has been worked on more than once, codex monitor delivery can never arm. The role-session record that every layer of the monitor path requires is unwritable there, and each layer fails silently, so the only symptom is Codex bridge: <team>/<name> not running forever.

This is not Windows-specific — the blocking condition is a platform-independent guard in codex-record-session.sh. I only reached it after working around #567 locally, so on Windows the two stack.

Environment: agmsg 1.1.12, codex-cli 0.146.0 (npm), Node v22.14.0, Windows 11 Pro 26200, Git for Windows bash (MINGW64).

The chain

1. scripts/drivers/types/codex/_session-start.sh:108-120 keeps only roles whose role-session record names this project and this thread. A role with no record takes the else at :115-118 and is dropped. With every role dropped, PAIRS is empty and the hook exits at :122 — the bridge request file is never written.
2. scripts/drivers/types/codex/codex-bridge-launcher.sh:331-334 applies the same filter to its own identity set. ids ends up empty, and :340-344 re-execs the child every 0.3s indefinitely.
3. scripts/drivers/types/codex/codex-bridge-launcher.sh:448-454 waits open-endedly for the record as well.

Why the record cannot appear

The only writers are scripts/actas-claim.sh and scripts/drivers/types/codex/codex-record-session.sh. The latter records a seat only when exactly one of the 40 newest rollouts has a session_meta.cwd matching the project (:97-104), and otherwise exits 0 at :110 without writing anything.

On a project used regularly, that count is never one. On mine it is 17:

matching rollouts among 40 newest: 17  distinct ids: 17

So the seat is never written, and nothing downstream can arm.

Every layer is silent

• delivery.sh status reports Codex bridge: <team>/<name> not running, which reads as "the bridge process died", not "this role has no seat".
• The SessionStart hook exits 0.
• The dispatcher's and child's output is sent to /dev/null by codex-monitor.sh:207.

Nothing anywhere says the role has no seat record.

Reproduce

1. Use one project with Codex over several days, so ~/.codex/sessions accumulates more than one rollout whose session_meta.cwd is that project.
2. Enable monitor mode for it and launch Codex through the shim.
3. Run scripts/drivers/types/codex/codex-record-session.sh <team> <agent> — exits 0, writes nothing.
4. ls run/role-session.* — empty. No bridge ever arms, in this or any later session.

Confirmation that this is the only remaining blocker

Writing the record by hand for the live thread makes the whole chain work:

CODEX_THREAD_ID=<live thread uuid> codex-record-session.sh <team> <agent>

SessionStart then writes the request file, the dispatcher spawns the role child, and the bridge logs:

codex-bridge: resumed thread 019fb8ae-...
codex-bridge: armed default/codex
codex-bridge: wakeup 1 for default/codex
codex-bridge: started turn on thread 019fb8ae-...

A message sent from the paired Claude Code session was delivered into the live Codex TUI as a turn, with nothing typed on the Codex side.

Possible directions

Any one of these would fix it:

• (a) Seat the role at SessionStart with the thread agmsg_resolve_codex_thread has already resolved. It takes the newest matching rollout, which Codex writes about a second before the hook fires, so it is this session's thread. This is what I run locally and it has been working. Trade-off: with two Codex windows on the same project under the same role, the newer window takes the seat.
• (b) Let codex-record-session.sh fall back to the newest matching rollout instead of recording nothing when several match.
• (c) Honour the --thread loaded fallback for roles with no record. The file header of codex-bridge-launcher.sh and codex-bridge.js --thread loaded (thread/loaded/list) already describe and implement it, but the guards above mean it is never reached.

Independently of which is chosen, the silent path seems worth a diagnostic: delivery.sh status could distinguish "this role has no seat record" from "not running".

[fujibee]

@pipumin

Thank you for this — the chain you traced is correct, the reproduction is
correct, and the hand-written record proving the rest of the path works was what
made this quick to act on. We are fixing it, but with none of (a), (b) or (c),
so here is what we measured and why each of the three falls down. All numbers
below come from a machine with the same shape as yours (44 rollouts sharing one
project cwd, 6 of them among the 40 newest).

(b) — fall back to the newest matching rollout

The two code paths that pick a rollout do not sort by the same key.
codex-record-session.sh sorts by filename, which is creation time;
agmsg_resolve_codex_thread sorts by mtime, which is last write. On a resume no
new rollout is created — Codex appends to the existing file — so ordering by
creation systematically misses the thread that is actually being used.

At the moment of measurement the two disagreed: filename-newest was a thread
last written 2.7 days earlier, mtime-newest was one written 2 minutes earlier.
So (b), implemented over the ordering that is already in that function, would
record a thread that had been dead for days. Ordering by mtime instead makes (b)
select exactly what (a) selects, which leads to:

(a) — seat with the thread agmsg_resolve_codex_thread already resolved

Reconstructing that resolution at all 77 historical session starts on two
projects (every rollout line carries a timestamp, so this needs no new session),
it returns the right thread at up to 2 seconds of hook delay and starts being
wrong at 3. The margin is real but thin: the shortest gap between a session
starting and a different session in the same project writing was 2.6 seconds.

The part that decided it, though, is that the retry loop does not protect this.
It returns the first match in mtime order and only sleeps when there are zero
matches — and a project with history always has matches. If this session's
rollout is not on disk yet, it returns a stale thread immediately.

Today that costs nothing: a wrong resolution fails the seat comparison, the role
is dropped, delivery stops. Writing it into the seat turns the same wrong value
into a resume that wakes the wrong conversation. The identical error changes
from harmless to harmful, which is the trade the existing guard was written to
avoid.

(c) — honour the --thread loaded fallback

We recommended this internally before testing it, and testing it is what killed
it. Against a live app-server:

• thread/loaded/list returned 3 ids while only 2 Codex windows were running.
  The third belonged to a role whose window was gone; the app-server keeps a
  thread loaded after its window closes. "Loaded" does not mean "live".
• The order is stable and ascending by thread id, which for UUIDv7 is creation
  order (cross-checked against thread/list, which is the same key descending).
  So ids[0] in codex-bridge.js is the oldest loaded thread — on that
  machine, another running agent's live session.

So (c) would hand an unseated role someone else's conversation, which is worse
than no delivery.

That is not a criticism of the code you pointed at. thread/loaded/list is the
only view that contains the currently-running session, and it returns bare ids —
no cwd, no name, no status. thread/list carries all of that, but we measured
that it does not contain the session that is running: it appears there only
after the session ends. The guessing in that function is structural, not an
oversight.

What landed

#583, on main and going out in the next release.

It keeps the "exactly one candidate or record nothing" rule — the bias toward a
fresh boot over a resume mis-fire is right — and change what is counted. Instead
of rollouts matching the cwd, count the app-server's loaded threads minus the
threads some role already sits in. The leftovers are exactly the sessions that
have not been seated, because the stale entries are precisely the seated ones.
A unique remainder is recorded; anything else records nothing.

The bridge then rewrites the seat once it has armed, so the recorded value is
one the app-server confirmed rather than one anything inferred.

A known limit, stated plainly: the subtraction needs at least one seat to
subtract. If the app-server is already holding several threads and no seat has
ever been written — which is the state an upgrade lands in — the count is
ambiguous and nothing is recorded until the app-server is recreated. Once one
seat exists it stays consistent from then on. Recreating it deliberately:

delivery.sh set off codex <project>
delivery.sh set monitor codex <project>

That stops the other Codex bridges for the project too, so it is a deliberate
step, not a background one. We could not confirm whether simply reopening Codex
is enough, so we are not claiming that it is.

On the diagnostic

Your closing point was right and it is in the same change. delivery.sh status
now separates "this role has no seat" from "the process is not running", and in
the ambiguous case reports how many threads are loaded and what to do about it.

Two notes for whoever reads this next:

• Still open, and not fixed here. While a role has no seat,
  codex-bridge-launcher.sh re-execs itself every 0.3s for as long as the Codex
  session lives — nothing is running, but something is very much looping, and it
  costs CPU the whole time. That loop is deliberate: a seat can be written by
  actas later in the same first turn, so waiting is right. With this change the
  normal path reaches a seat and the loop ends.

  It does not end in the ambiguous state described above. There the seat is
  never written, so the loop spins for the life of the session and stops only
  when Codex exits. Leaving a non-converging case under a loop that assumes
  convergence is a real gap; it is left here rather than changed, because
  altering the retry is a behaviour change that does not belong in the same
  change as the fix.

• We did not measure whether Codex writes session_meta before or after firing
  the SessionStart hook. It does not matter for the approach above, but it would
  settle (a) if anyone proposes it again. A temporary second SessionStart entry
  that only records a timestamp, in a scratch project, is enough to get it.

[NNK-github]

@fujibee Follow-up after the v1.1.13 fix (#591), reporting here per your routing in #567 ("the seat behaviour belongs in #579"). The resolution-layer blocker this issue tracked is fixed — and with it out of the way, the next layer down became visible on Windows. Happy to refile as a separate issue if you'd rather track it apart.

What #591 fixed, confirmed on this machine: thread resolution no longer needs the environment variable, and an external codex-record-session.sh <team> <agent> call (plain, no env) now seats the correct thread; the bridge arms and push → idle codex → reply passes.

What still fails — the in-session path (actas from the spawned agent's own shell_command, codex 0.146 --remote, Windows): the seat still cannot be written, now for a different reason further down — the filesystem write itself.

Where it dies — agmsg_role_session_record (lib/role-session.sh):

mkdir -p "$dir" 2>/dev/null || return 0

Traced with bash -x from inside the session: thread resolution succeeds (CODEX_THREAD_ID is present in that context), the record path is resolved, then the function returns at that line. Every failure is a silent no-op by design, so the only symptom is "no seat".

Probe from the same in-session context:

mkdir -p ~/.agents/skills/agmsg/run
# exit 1: mkdir: cannot create directory /c/Users/NNK: Permission denied

mktemp ~/.agents/skills/agmsg/run/.probe.XXXX
# exit 0 — file created

So the leaf directory exists and IS writable; only the mkdir -p walk fails. The sandbox answers EACCES (instead of EEXIST) while mkdir -p probes the intermediate path components, and coreutils treats that as fatal.

Suggested fix (one line, same best-effort semantics):

[ -d "$dir" ] || mkdir -p "$dir" 2>/dev/null || return 0

The dir always exists in practice (the skill created it long before any seat is written), so this unblocks in-session seeding on Windows without changing behaviour anywhere else.

Environment: agmsg v1.1.13, codex-cli 0.146.0, Node v22/v24, Windows 11 Pro 26200, Git for Windows bash. Sandbox scope: the failing session ran sandbox_policy: workspace-write with the standard agmsg writable_roots (db/teams/run) and [windows] sandbox = "elevated" — verified from the session rollout's turn_context, so this should reproduce wherever the Windows codex sandbox is active; without it the mkdir walk is not intercepted.

Distinct from #539: that one is PID resolution killing the actas lock (cc-instance never written, claude side); this is the sandbox blocking the seat record write (role-session, codex side). Independent failures that can co-present on Windows.

Workaround in use: one external codex-record-session.sh <team> <agent> call after spawn — much simpler than the pre-1.1.13 env dance, thanks for #591. Full bash -x traces (in-session vs external) available on request.

[fujibee]

@NNK-github

Taking you up on the offer to track this apart: your follow-up is now filed as #608. This issue stayed closed because the layer it tracked — thread resolution — really was fixed in #591, and reopening it would have made a resolved defect look unresolved and pulled its original reporter into a thread that is no longer theirs.

The fix is on main as of #602: agmsg_role_session_record no longer treats a mkdir -p failure as fatal, so the existing mktemp call is the only thing deciding whether the directory is usable. Your probe is what made that the obvious shape — mkdir -p exiting 1 while mktemp on the same directory exits 0 says the guard was refusing under a condition that does not actually block the write. It is not in a tagged release yet.

Two things are worth saying plainly. No CI job exercises the real trigger: the regression test added with the fix stubs mkdir to fail while the directory stays usable, which reproduces the mechanism but not a Windows sandbox returning EACCES. And nobody has walked the symptom again on real hardware since it landed.

If you are willing, the check that would close this is the one you are already set up for: drop the external codex-record-session.sh <team> <agent> call you have been using as a workaround and see whether the in-session actas path seats on its own. No rush, and from main or from the next release, whichever suits you.