orchestration: worker-start never passes agent readiness for omp workers (1.4.211) #24971

Activity

1. bashrusakh commented on Oct 3, 2026

   

   bashrusakh

   on Oct 3, 2026

   More actions

   Thanks for the detailed report — the observed timeout and the workaround both check out, and the readiness gap is already fixed on main.

   Why it failed

   worker-start gates the brief behind the agent_readiness stage, which awaits waitForTerminal(handle, { condition: 'tui-idle' }). In 1.4.211 that lane needed the pane's output stream to go quiet for ~3s before it would settle. OMP 18.4 re-asserts bracketed paste about once a second once the terminal answers its capability probe, so the stream never quiesced and the wait ran to its timeout even though the pane was sitting at an idle composer.

   Two notes on the original diagnosis:

   • On 1.4.211 there was no hook lane at all — the OMP status extension deliberately posts nothing at session_start — so readiness was already falling through to the title/screen evidence below. It was not waiting on a hook that only arrives after the first prompt.
   • Reading the extension's first heartbeat as "ready" isn't safe on its own: a session start is not a turn end, and some agents post it before their composer accepts input (tui-idle-hook-lane.ts), which would reintroduce the lost-prompt class.

   What fixed it

   Commit 44a2ee54bb ("fix(runtime): make OMP 18.4 workers ready at the composer and keep stale-title clears display-only", #24295, 2026-10-02). It:

   • makes OMP's own π > … idle state title count as ready once it has stood a short window, independent of output quiescence, so OMP's ~1Hz keepalive no longer blocks it;
   • requires a screen read clear of OMP's setup wizard (alternate screen) before that title can settle, so a first-run wizard cannot be mistaken for an idle composer;
   • keeps the post-turn π - … title and other Pi/OMP titles on the existing lanes. Covered by src/main/runtime/omp-readiness-transcripts.test.ts (captured OMP 18.4 setup/composer transcripts, including the bracketed-paste keepalive case).

   Version availability

   It is not in any released build yet — checked against the tags in this repo:

   • v1.4.219 (2026-10-02 20:09 UTC) predates the fix (merged 20:29 UTC); the OMP readiness work landed after it.
   • No v1.4.220 tag exists.
   • Correcting my earlier reading of the notes: Codex's live-screen readiness is in v1.4.217, and ZCode's composer wait shipped in v1.4.218 (not 1.4.212).

   So the 1.4.211 timeout is expected until the next release (or a build from main) ships. Meanwhile your terminal create → task-create → dispatch --inject workaround remains the documented low-level path for custom-topology launches.

   If it still times out on a build that includes 44a2ee5, an OMP version plus a pane capture would help — that would be a separate issue.
2. nwparker commented on Oct 10, 2026

   

   nwparker

   on Oct 10, 2026

   Contributor

   More actions

   Closing as completed: the OMP 18.4 keepalive readiness bug is fixed by merged PR #24295. I verified that latest main still uses the sustained OMP idle title plus a screen check for setup overlays, without requiring the output stream to go quiet. All 17 tests in omp-readiness-transcripts.test.ts pass, including captured OMP 18.4 composer/setup transcripts and the bracketed-paste keepalive case.

   The later OMP 18.5 startup-title report (#25052) remains open; this closure covers the older keepalive bug described here.
3. nwparker

   closed this as completedon Oct 10, 2026