Why Claude Gets the Popup and Other Agents Do Not

A precise breakdown of why Claude currently triggers Beacon while Codex, Gemini, OpenClaw, and provider-layer systems like OpenRouter do not.

All essays2026-05-0610 minagentsclaudecodexgeminiopenclawopenrouter

The Important Distinction

The popup does not depend on “which model is smart enough.” It depends on which runtime emits the lifecycle events that FleetCrown and Beacon need in order to know a session has reached a stopping point.

That is why Claude works today.

Why Claude Works

Claude is currently the only interactive runtime in this setup that is wired into a real stop path.

The chain is:

  1. Claude finishes a turn.
  2. Claude fires a local hook.
  3. The hook runs the bridge script.
  4. The bridge writes lifecycle state and launches Beacon.
  5. Beacon renders the continuation UI.

That is enough to create a real loop.

Why Codex Does Not Behave The Same Way

Codex can launch and accept work, but the interactive local session path does not currently emit an equivalent “finished and waiting” event in this setup.

So the system can know:

  • Codex is running
  • Codex received a prompt

But it cannot reliably know:

  • Codex has reached the point where the popup should appear

That is the missing piece.

Why Gemini Does Not Behave The Same Way

Gemini is even less integrated. Detection of a CLI is not the same thing as orchestration. Without prompt flow, lifecycle emission, and continuation routing, the agent is not participating in the same operating loop yet.

So the absence of popup support here is not surprising. It is simply unfinished integration.

Why OpenClaw Is Different

OpenClaw is better thought of as a runner or orchestrator backend than as a terminal-native interactive session loop.

It can:

  • run tasks
  • finish tasks
  • persist run results
  • produce summaries

But unless completion from OpenClaw is translated into the same waiting or completion event that Beacon expects, it will not feel equivalent to Claude from the operator’s point of view.

So OpenClaw is not the same problem as Codex. It does not need the same implementation path. It still needs the same system semantics.

Why OpenRouter Is A Different Category Entirely

OpenRouter is a provider abstraction, not a local session runtime.

That means OpenRouter itself does not have a popup path. A client or runtime using OpenRouter would need to emit session lifecycle events. Without that, asking whether OpenRouter “supports the popup” is the wrong question.

The right question is:

Which runtime is using OpenRouter, and does that runtime participate in the FleetCrown lifecycle contract?

The Better Way To Phrase The Problem

The wrong question is:

Which models support the popup?

The correct question is:

Which session runtimes emit the lifecycle events that FleetCrown needs to drive the popup?

That wording forces cleaner architecture and avoids mixing up:

  • model
  • provider
  • runtime
  • orchestration layer

The Bottom Line

Claude gets the popup because Claude is the only runtime in this setup with a fully wired lifecycle callback path into Beacon.

Codex, Gemini, OpenClaw, and OpenRouter do not all fail for the same reason, but they all currently miss the same product outcome: they are not yet participating in a neutral, shared session lifecycle that drives the continuation loop.

Newer

The Anatomy of a Broken Injection Pipeline

A deep technical dissection of how FleetCrown, Beacon, and Zellij connect to form a prompt-injection system — and the five structural bugs that make it unreliable when it looks like it should just work.

Older

What a Truly Agent-Agnostic Popup Architecture Needs

The concrete architecture needed to make Beacon and FleetCrown lifecycle-driven instead of Claude-driven, with a clear split between adapters, control plane, and clients.

Related

A Fleet Outlives Its Ships

The agent market keeps asking which new worker kills the last one — is Hermes the OpenClaw killer, is Codex the Claude Code killer. The question is almost content-free, and the fact that it stays askable is the tell: the worker layer is converging on one substrate and commoditizing. This is a technical and philosophical account of what that means — what a worker actually is now, read closely through Nous Research's Hermes; the two things a single worker structurally cannot be, its own verifier and its own market; and why FleetCrown and OrangeCat are built on exactly those two things.

The Visitor Is Part of the Fleet Now

FleetCrown's feedback widget turns a stranger's complaint into a deployed fix — one script tag on any of your sites, a per-project inbox, one-click dispatch to an agent, and a loop that closes itself: when the fix ships, the report resolves automatically and the visitor gets an email. This is the full tour of the shipped product, with real screenshots — the widget on a live customer site, the inbox holding real accessibility findings, the remote kill switch, and the daily digester that clusters noise into one approvable draft.

A Working Tree Is a Lock

FleetCrown runs many AI-agent sessions at once, and for months they shared a single git checkout — so branches switched under live work, and an unrelated session's half-finished code could ride out to production on someone else's deploy. This is the full record of the fix: why a working tree is a mutual-exclusion resource, why the same tree must not also be the deploy artifact, the two isolations we built (per-session worktrees, a CI-owned deploy), the three latent bugs the first real deploy exposed, and an honest ledger of what the new machinery might cost us later.