Using AxiOwl to Keep Codex, Cursor, and Claude Working Together

Using AxiOwl to Keep Codex, Cursor, and Claude Working Together

Modern AI coding work rarely lives in one chat. A developer may have Codex handling a repository task, Cursor open in an editor agent window, and Claude Code useful for a separate command-line investigation. The hard part is not asking each assistant a question. The hard part is keeping the work coordinated without copying context by hand, losing the sender, or pretending that every provider behaves the same way.

AxiOwl is built for that middle layer. In the current C++ implementation, it is a local Windows coordinator with a CLI, an MCP server, a durable registry of provider sessions, provider-specific discovery, and provider-specific delivery edges. Its job is to let one named agent send a message to another named agent while preserving enough identity and delivery evidence to make the exchange operationally useful.

AxiOwl Is a Router, Not a Generic Chat Box

The current architecture is deliberately simple in the center and specific at the edges. A request can enter through the AxiOwl CLI or through an MCP tool exposed to a provider host. From there it goes through the MessagePipeline, which validates the request, resolves the sender, resolves the target registry row, performs one targeted discovery repair if needed, builds the final visible body, and dispatches through provider_edges.cpp to the provider module that knows how to reach the target surface.

That distinction matters for Codex, Cursor, and Claude because each one exposes a different surface:

That is the useful way to think about AxiOwl: one operator-facing message layer, with honest provider-specific contracts underneath.

The Registry Gives Agents Stable Names

AxiOwl keeps a durable local registry instead of relying only on whatever window title or filesystem artifact happens to be available at the moment. Registry rows include the display name, aliases, provider value, provider session ID, node ID, sendability, discovery source, last-seen time, last-verified time, and last error.

That registry is why a user can aim at a name instead of a raw session identifier:

axiowl list agents
axiowl send --to "codex planning agent" --body "Please review the Cursor patch notes and reply with blockers." --from "cursor implementation agent"

The exact agent names depend on what discovery and registration have found locally, but the command shape is stable. The CLI also supports stdin for longer messages:

Get-Content .\handoff.md | axiowl send --to "cursor implementation agent" --stdin --from "codex planning agent"

For agent-to-agent usage through MCP, the preferred path is not to invent raw command arguments. The MCP tool contract uses the host MCP session ID as the stable sender identity key. AxiOwl resolves that key back to the registered visible sender name before it appends reply instructions.

Codex: Supported Agent and CLI Routing

Codex is one of the stronger current surfaces in AxiOwl. The source-of-truth provider matrix marks both codex:agents and codex:cli as supported. The Codex provider implementation includes Windows desktop IPC delivery for local Codex sessions and CLI thread operations for Codex CLI.

In the CLI path, the provider code uses Codex CLI resume behavior and app-server thread operations. Discovery reads Codex state from local Codex files and classifies rows as Codex or Codex CLI depending on the evidence. For CLI delivery, the provider edge reports accepted_by_provider only after the Codex path accepts the handoff.

The practical value is that Codex can be part of a larger local team without becoming the only place where work happens. Codex can ask a Cursor agent to inspect an editor-specific issue, or a Cursor agent can ask Codex to continue a repository task, as long as both sides are registered with usable sender identity and target session evidence.

Cursor: Supported Agent Window Routing Through a Bridge

Cursor support is not implemented as a generic shell command pretending to be Cursor. The current supported Cursor surface is cursor:agents, using the AxiOwl Cursor bridge. The provider support matrix describes the delivery method as bridge command files, a watcher, URI fallback, and a Cursor patch-provided command path.

The implementation reflects that. Cursor discovery reads Cursor composer information and stores provider session IDs in the cursor:composer:<id> shape. The provider writes command JSON files under the AxiOwl Cursor bridge area, waits for result files, prefers an active command watcher when available, and falls back to a Cursor URI trigger when needed. It also gates sending when Cursor patch status blocks delivery.

That design is useful because Cursor is often where the active editor context lives. AxiOwl does not need to flatten that into a lowest-common-denominator chat. It keeps Cursor-specific routing in the Cursor provider edge while the operator still uses the same high-level AxiOwl verbs: discover, list, create, send, and rename where supported.

Claude Code: A Target Surface With Real Implementation Boundaries

Claude Code CLI is present in the implementation, but the current support matrix is intentionally stricter than "there is code." It marks claude-code:cli as a target. The reason is specific: the current support bar requires provider-owned sender metadata for final CLI support. Environment-only identity is not enough.

The Claude provider code discovers sessions from ~/.claude/projects/*/*.jsonl and uses provider session IDs shaped like claude_code_cli:session:<uuid>. Delivery uses Claude's print/resume style flow, including --resume, and requires a valid working directory from the Claude JSONL session state. The provider code also writes a Claude MCP config for the session so replies can route back through AxiOwl.

That makes Claude useful in an AxiOwl workflow today as a concrete integration target being wired toward the same standard, while also making the limitation visible. AxiOwl should not silently call a provider "supported" until discovery, delivery, MCP reply, and provider-owned sender identity all meet the current test bar.

Why Sender Identity Is the Center of the System

The most important AxiOwl behavior is not simply "send text." It is knowing who sent the text and giving the recipient a correct path to reply.

When AxiOwl builds the final visible body, it includes a message header from the resolved sender and appends reply instructions that point back to that sender. If the sender cannot be resolved, the visible body carries a warning instead of quietly attaching a bad return path.

That is why the MCP server requires usable provider/session metadata and why the developer docs say missing metadata should fail loudly. A reply should route to a real provider session, not to a guessed display name, stale path, or raw ID that only looked plausible during discovery.

The Operator Workflow

A typical local workflow is straightforward:

axiowl discover all
axiowl list agents
axiowl send --to "<target agent name>" --body "<message>" --from "<sender agent name>"

For a new session, the CLI exposes provider-aware creation:

axiowl create --provider codex-cli --name "codex review agent" --body "Start a review thread for the current task."
axiowl create --provider cursor --name "cursor implementation agent" --body "Open an implementation thread for this workspace."
axiowl create --provider claude-code-cli --name "claude investigation agent" --body "Start with a concise investigation note."

The provider names matter. AxiOwl normalizes common CLI spellings into internal provider values such as codex_cli, cursor, and claude_code_cli, then dispatches to the matching provider edge. If the provider is unknown, unsupported, unavailable, or out of scope, the delivery result should say that instead of falling back silently.

There is also a smoke-test path for local provider checks:

axiowl provider smoke-test --all-local --report

The smoke-test command checks local sendable rows and sends provider-specific contracts, but AxiOwl still treats receipt boundaries carefully. An AxiOwl handoff receipt means AxiOwl accepted and validated the request. A provider result of accepted_by_provider means the provider edge reported acceptance. The strongest proof is a response over MCP from the target provider with correct sender identity.

Why This Helps Real Development Work

The value of AxiOwl is not that it erases differences between tools. It gives those differences a controlled place to live.

Codex can use its agent or CLI paths. Cursor can use its bridge, watcher, command files, and patch-aware checks. Claude Code CLI can use its session JSONL and resume flow while final metadata support is treated as a real requirement, not a footnote. The user sees a consistent routing surface, but the implementation keeps provider-specific behavior inspectable.

For teams running several AI coding tools in parallel, that means fewer manual handoffs and fewer ambiguous messages. A Codex thread can ask a Cursor agent to inspect an editor task. Cursor can send a result back through AxiOwl. Claude can be brought into the same registry-backed workflow as its CLI metadata path matures. Each message has a target, a sender, a provider edge, and a delivery boundary.

Keeping the Tools Together Without Blurring Them

AxiOwl's current design is pragmatic: keep a durable registry, discover provider sessions, require sender identity, dispatch through provider-specific edges, and be explicit about what has been accepted by AxiOwl versus what has been accepted by a provider. That is what lets Codex, Cursor, and Claude participate in one workflow without pretending they are the same product.

The result is a coordination layer for real agent work. It does not replace Codex, Cursor, or Claude. It gives them a shared routing fabric so each tool can do the part of the job it is best suited for while the operator keeps the conversation connected.

Tagged , , , , , , , ,