Oh My OpenAgent v4.9.2 Fixes the Runtime Bug Every Multi-Agent Harness Eventually Meets

The least glamorous part of multi-agent coding is the part that decides whether the product feels brilliant or haunted: waking the parent session after a background agent finishes.

Oh My OpenAgent v4.9.2, published June 12, is a release about exactly that. The headline is “Reliable Background-Agent Wake Routing,” which sounds like runtime plumbing because it is. Background agents can now wake parent sessions through a live server route, using a direct HTTP path that bypasses the previous prompt-gate timing window. The synced LazyCodex v4.9.2 marketplace release landed one second earlier, which makes this more than a niche OpenCode plugin patch. The same orchestration idea now straddles OpenCode Ultimate and Codex Light.

That is the interesting part. Everyone in agentic coding wants “teams of agents.” Fewer people want to own the control plane that makes teams of agents not deadlock. Oh My OpenAgent's release is worth attention because it names a real failure mode in enough detail for practitioners to learn from it.

The bug was not intelligence. It was session semantics.

The root cause is documented in PR #5171, merged June 11. A noReply: true injection added a synthetic user message that was never supposed to receive an assistant reply. The shared gate function, however, treated every synthetic user tail as if it expected a reply. That meant a notification tail could look like an unfinished prompt. Parent-wake notifications then got stuck behind stacked noReply tails, leaving the parent session waiting even though the background agent had completed.

This is a perfect agent-runtime bug because the model can do everything right and the user still experiences failure. The child agent finishes. The result exists. The parent is supposed to resume. But a synthetic history item has the wrong semantics, so the harness politely waits forever. From the outside, it looks like “the agent got stuck.” From the inside, it is a state-machine bug with a prompt-shaped disguise.

The fix is the kind of boring precision these systems need more of. PR #5171 tags no-reply injections with OMO_INTERNAL_NOREPLY_MARKER, teaches the shared gate function to look through terminal no-reply tails to the real assistant turn behind them, preserves anti-stacking behavior for genuine reply-expecting internal tails, and still blocks when an active assistant turn exists behind the tail. The change touched eight files with 334 additions and four deletions. The PR reports 13 new tests across three files, including marker round-trip and idempotence, stacked no-reply tails, reply-expecting tails behind no-reply tails, active assistant pending-tool cases, and an end-to-end wake-dispatch scenario. The touched test set passed 39/39, with a clean tsgo typecheck.

That test list matters more than the release slogan. If your multi-agent harness does not have tests for stacked notifications, active parent turns, duplicate or delayed wakes, failed children, pending tools, and synthetic-message edge cases, you are not really testing multi-agent behavior. You are testing a happy-path demo.

Live wake routing is a control-plane feature

The release adds a live server route for parent wakeups and says wake dispatch now uses the live listener client with synchronous fast-path resolution. In plain English: do not rely on the prompt gate alone to notice that a background worker completed. Give the completion signal a direct route to the waiting parent.

That is a small architectural decision with a large product effect. Multi-agent systems are distributed systems wearing a chat UI. They have parent and child tasks, internal messages, notification tails, active turns, listeners, queues, cancellation paths, and race conditions. The user sees a conversation. The runtime is coordinating state across cooperating workers.

Once you accept that frame, live parent-wake routing looks less like an implementation detail and more like necessary infrastructure. The parent session needs a reliable completion signal. The gate needs to distinguish between prompts that require replies and notifications that do not. Multiple serve() registrations need isolated route state. The system needs an escape hatch, and this release includes one: experimental.disable_live_parent_wake_routing: true.

That rollback switch is a good sign. Agent products often ship features as if the only risk is model quality. Runtime changes need the same discipline as any production control-plane change: can you disable the new path if it misbehaves, can you observe where work is stuck, and can you preserve the old behavior long enough to recover? A harness without escape hatches is asking users to debug autonomy with vibes.

OpenCode Ultimate, Codex Light, and the portable-agent thesis

Oh My OpenAgent's README describes two editions. Ultimate targets OpenCode and includes 11 agents, 54-plus lifecycle hooks, five built-in MCPs, Team Mode, slash commands, ultrawork, ulw-loop, hashline edits, and richer orchestration. Light targets Codex CLI through LazyCodex, carrying portable rules, comment-checker, git-bash, LSP, ultrawork, ulw-loop, start-work-continuation, telemetry, and plugin-scoped MCPs. Installation paths include bunx oh-my-openagent install for OpenCode Ultimate, npx lazycodex-ai install for Codex Light, and a --platform=both option.

The split is strategically revealing. OpenCode gives community projects more room to wire deep into the harness: hooks, teams, MCPs, permissions, lifecycle control, and bespoke workflow machinery. Codex gives a more vendor-shaped surface with plugin packaging and stricter boundaries. Oh My OpenAgent is effectively betting that some agent behaviors should be portable across both worlds.

That tracks where the market is going. The durable unit may not be “one coding agent app.” It may be a set of reviewable workflows, routing rules, subagent roles, and lifecycle hooks that can survive across harnesses. Developers already move between Claude Code, Codex, Cursor, OpenCode, and homegrown runners depending on the repo and task. The winning agent infrastructure will treat portability as a feature, not an accident.

But portability cuts both ways. A plugin that follows you across harnesses also follows you across trust boundaries. OMO advertises autonomous permissions options, built-in MCPs, telemetry, hooks, and installer-driven configuration. Those are useful capabilities, and each one deserves inspection before use on sensitive repositories. Review installed hooks. Review MCP server configuration. Review environment variables. Review telemetry. Review whether subagents can run commands, edit files, or touch networked tools. The control plane is where productivity and blast radius meet.

What engineers should take from a wake-routing patch

The lesson is not “everyone should install Oh My OpenAgent today.” The lesson is that background-agent reliability is a first-class evaluation criterion.

If you are comparing multi-agent coding stacks, ask how child completion works. Does the parent wake through a direct route, a queue, a polling loop, or only conversation history? What happens if the parent is already in an assistant turn? Can synthetic notification messages be marked as terminal? Are no-reply messages distinguishable from reply-expecting messages? Can wakeups stack? Can they duplicate? Can they be cancelled? Is there an explicit rollback flag for the new routing path?

Also ask what the test suite proves. A system that claims background agents but only tests “spawn child, child returns, parent prints result” is not done. The useful tests are ugly: stacked no-reply tails, active tool calls, pending assistant turns, failed children, repeated notifications, multiple server instances, and out-of-order completion signals. This is where agent orchestration either becomes software engineering or remains a demo script.

The same applies inside companies building internal agent platforms. Do not hide all coordination inside natural-language prompts. Prompts are fine for intent. Control flow belongs in code, with typed states, observable events, retry behavior, and tests. If a child agent finishing work is an important event, model it as an event. If a synthetic message should not receive a reply, encode that property explicitly. If a parent can be busy, define what “busy” means and how wake signals should wait, merge, or fail.

Oh My OpenAgent v4.9.2 is not a flashy release. It is better than that. It is a reminder that agentic coding is bottlenecked by runtime correctness at least as much as model intelligence. A background worker that cannot wake its parent reliably is not autonomous; it is a subprocess with stage fright. The teams that make multi-agent coding work will be the ones willing to debug the unglamorous machinery: prompt gates, synthetic history, listener clients, route state, cancellation, and rollback switches.

That is where the product is. The chat box is just where users notice when it breaks.

Sources: Oh My OpenAgent v4.9.2 release, LazyCodex v4.9.2 release, PR #5171 background-agent wake fix, Oh My OpenAgent repository, LazyCodex repository, OpenCode repository, Codex migration docs.