You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A wrapper registers its identity before it launches the CLI, so the agent becomes visible while the underlying program (Claude, Codex, Gemini …) is still starting. In that window:
a mention can be routed to a program that cannot yet receive it;
the CLI may in fact be waiting on a login or consent screen, and nothing reports that — it simply looks present and silent.
Proposal: an opt-in readiness gate
The instance registers in a new starting state. It gets the identity details needed to launch, is shown as starting but unavailable, and receives no mentions; a sender gets a visible "not delivered, resend once it shows ready" notice rather than silence. The wrapper watches the real pane and marks the instance ready only once it recognises the CLI's ready screen. A known blocker screen (login, consent) fails fast and is labelled; an unknown screen fails closed on a timeout; either way the pane is left alive when a human could still answer it.
Liveness is tracked separately from readiness: a starting instance keeps heartbeating, so the existing crash sweep can still tell a slow launch from a dead one and reclaim the name if the wrapper is killed mid-start. Being live does not make it available, and every user-facing "who is online" answer masks on state.
Default-off. Unused, registration and delivery behave exactly as they do today. It is Unix-only, since readiness is judged by reading the tmux pane, and the flag is refused on Windows rather than registering an instance nothing could mark ready.
Split into three reviewable PRs
The change has three layers, so it is offered as a stack rather than one large diff. Each lands before the next is opened, so every PR shows only its own work:
Wrapper probe and gate, with a fake-tmux test harness — 8 files, +1428. Depends on 2.
Only #93 is open at this point, deliberately. GitHub diffs a pull request against the branch it targets, so opening 2 and 3 before their parents merge would show you this PR's code again inside them — the same diff two and three times over. They go up as each parent lands, so each shows only its own work. The last of them will close this issue.
Note on ordering
These PRs share a repository with #89, an intermittent 502 in ProxyHeaderForwardingTests. Until that five-line test fix lands, any run of the full suite has a chance of failing for reasons unrelated to the change under review. Merging #89 first makes the rest of this stack read cleanly.
A wrapper registers its identity before it launches the CLI, so the agent becomes visible while the underlying program (Claude, Codex, Gemini …) is still starting. In that window:
Proposal: an opt-in readiness gate
The instance registers in a new
startingstate. It gets the identity details needed to launch, is shown as starting but unavailable, and receives no mentions; a sender gets a visible "not delivered, resend once it shows ready" notice rather than silence. The wrapper watches the real pane and marks the instance ready only once it recognises the CLI's ready screen. A known blocker screen (login, consent) fails fast and is labelled; an unknown screen fails closed on a timeout; either way the pane is left alive when a human could still answer it.Liveness is tracked separately from readiness: a starting instance keeps heartbeating, so the existing crash sweep can still tell a slow launch from a dead one and reclaim the name if the wrapper is killed mid-start. Being live does not make it available, and every user-facing "who is online" answer masks on state.
Default-off. Unused, registration and delivery behave exactly as they do today. It is Unix-only, since readiness is judged by reading the tmux pane, and the flag is refused on Windows rather than registering an instance nothing could mark ready.
Split into three reviewable PRs
The change has three layers, so it is offered as a stack rather than one large diff. Each lands before the next is opened, so every PR shows only its own work:
startingstate — 2 files, +445. Inert withoutready_gate=True, so it can land first on its own. Open now: feat(registry): add a starting state with a single activation path #93.Only #93 is open at this point, deliberately. GitHub diffs a pull request against the branch it targets, so opening 2 and 3 before their parents merge would show you this PR's code again inside them — the same diff two and three times over. They go up as each parent lands, so each shows only its own work. The last of them will close this issue.
Note on ordering
These PRs share a repository with #89, an intermittent 502 in
ProxyHeaderForwardingTests. Until that five-line test fix lands, any run of the full suite has a chance of failing for reasons unrelated to the change under review. Merging #89 first makes the rest of this stack read cleanly.