Summary
The Codex monitor bridge only supports one codex identity per project. If a project has two or more registered codex identities — e.g. after actas-ing into a second role in the same project — the bridge does not launch at all, so monitor delivery silently stops for that project.
Where
session-start.sh (codex path):
pair_count=$(printf '%s\n' "$PAIRS" | awk 'NF >= 2 { c++ } END { print c + 0 }')
[ "$pair_count" = "1" ] || exit 0With pair_count != 1 the hook exits before writing the request file / launching the bridge.
Why it's not just the guard
Even if the pair_count guard were relaxed, the architecture is per-project, not per-identity:
- The app-server socket is keyed by project hash (one shared app-server per project).
- A monitored project has one interactive TUI on one thread; the bridge injects turns into that single thread.
- So N codex identities in one project can't each get their own delivery stream into the one TUI — there's only one thread to inject into.
actas (multiple roles, one running TUI) therefore doesn't map onto the current bridge model.
Impact
actas-ing a second codex role in a monitored project disables the bridge for that project (no error surfaced; messages just stop arriving as turns). This is the "effectively one monitored TUI per project" constraint, made concrete.
Proposed directions
- Multiplex identities into one thread (real fix): when a project has multiple codex identities, the bridge subscribes to all of them (via the shared
lib/subscription.sh) and injects each unread message into the single project thread, labeling which identity it's for. Drop the pair_count == 1 guard; resolve --name/--team to the full set.
- Pick the active actas identity: if the session has an "active FROM" actas role, launch the bridge for just that one (and re-point on actas switch). Narrower but matches how a user thinks about "who am I right now".
- At minimum, document + warn:
delivery set monitor / the actas flow should tell the user that codex monitor is single-identity-per-project today, instead of silently not launching.
Related
#41 (Codex monitor bridge), #149 (bridge teardown/orphan). Different projects run concurrently fine — this is specifically about multiple identities within one project.
Summary
The Codex monitor bridge only supports one codex identity per project. If a project has two or more registered codex identities — e.g. after
actas-ing into a second role in the same project — the bridge does not launch at all, so monitor delivery silently stops for that project.Where
session-start.sh(codex path):With
pair_count != 1the hook exits before writing the request file / launching the bridge.Why it's not just the guard
Even if the
pair_countguard were relaxed, the architecture is per-project, not per-identity:actas(multiple roles, one running TUI) therefore doesn't map onto the current bridge model.Impact
actas-ing a second codex role in a monitored project disables the bridge for that project (no error surfaced; messages just stop arriving as turns). This is the "effectively one monitored TUI per project" constraint, made concrete.Proposed directions
lib/subscription.sh) and injects each unread message into the single project thread, labeling which identity it's for. Drop thepair_count == 1guard; resolve--name/--teamto the full set.delivery set monitor/ theactasflow should tell the user that codex monitor is single-identity-per-project today, instead of silently not launching.Related
#41 (Codex monitor bridge), #149 (bridge teardown/orphan). Different projects run concurrently fine — this is specifically about multiple identities within one project.