How AxiOwl Keeps Provider Sessions Separate

AxiOwl is built to send messages between AI provider sessions without treating every chat window as the same kind of thing. A Codex session, a Cursor composer, a VS Code native chat, and a Copilot-backed VS Code chat may all look like "agents" to an operator, but AxiOwl keeps their provider identity, session identity, node identity, sendability state, and delivery route separate.

That separation is not just a UI preference. It is the difference between sending a message to the intended session and accidentally relying on a stale title, an old path, or a guessed sender name.

The Registry Is the Boundary

The center of AxiOwl's session separation is its durable local registry. The current Windows implementation stores agent rows under the AxiOwl state directory as registry\agents.tsv; on Windows that state root resolves under %LOCALAPPDATA%\AxiOwl.

Each registry row represents one reachable provider session or agent. The code model includes fields for:

• display_name
• aliases
• provider
• provider_session_id
• node_id
• enabled
• sendable
• source
• first_seen_at
• last_seen_at
• last_verified_at
• last_error

Those fields matter because two provider sessions can share similar human names while still needing different delivery behavior. AxiOwl does not only remember "Project helper" or "pricing agent." It also remembers which provider owns the session and what provider-owned session ID should be used to address it.

The developer docs state the design rule plainly: the registry maps names and aliases to provider sessions, and a row should not be marked sendable unless discovery or direct proof justifies it. That prevents the registry from becoming a loose collection of hopeful shortcuts.

Provider Session IDs Beat Display Names

A display name is useful for humans, but it is not strong enough by itself. AxiOwl's registry lookup code checks both names and aliases, but it gives exact session matches priority when resolving a target or sender. It also recognizes provider-specific session identifier shapes such as Cursor composer IDs, Cursor session IDs, Antigravity conversation IDs, and other provider session aliases.

This is important for day-to-day use. If an operator sends to a familiar agent name, AxiOwl can resolve that name through the registry. If a provider reply comes back with a raw session address, AxiOwl can map that address back to the registered sender when the session is known. If the display name itself still looks like a raw session ID, AxiOwl treats that as unresolved rather than pretending it has a clean human identity.

That behavior is visible in the sender identity path. The registry helper can resolve an explicit sender by provider session, by registered name, or by alias. But when an unregistered session-looking sender appears, it records that the sender session did not match a registered AxiOwl sender. The message pipeline can then run targeted discovery once instead of silently inventing an identity.

MCP Sender Identity Must Come From the Provider

AxiOwl's MCP server is strict about sender identity. The tool description for axiowl_send_message says the host MCP session ID is used as the stable sender identity key, and the developer docs say provider replies must include enough metadata for AxiOwl to identify the sender session.

The implementation follows that rule. When a provider calls the MCP tool, AxiOwl resolves identity from host metadata, registers the sender when there is a real session ID and sender name, and then launches the CLI send with --from set to the sender address derived from that provider-owned identity. If no usable session ID is present, the server refuses to launch a no-session send.

That refusal is deliberate. AxiOwl is not trying to make every provider look the same by stripping away its session model. It needs the provider's own session metadata so the reply path remains anchored to a real chat, not to an environment variable or a guessed label.

The provider support matrix applies the same standard to CLI providers. A provider is not considered fully supported just because AxiOwl can start a process or write a config file. The support bar includes discovery, sending to a named provider session, receiving a provider reply through AxiOwl MCP, and carrying correct provider-owned sender identity. For CLI providers, environment-only identity injection is explicitly not enough for final support.

The Message Pipeline Resolves Before It Delivers

When a send enters AxiOwl, it moves through a MessagePipeline instead of jumping straight to a provider command. The architecture docs describe the flow as:

1. CLI or MCP request enters axiowl.exe.
2. The handler passes the request to MessagePipeline.
3. The pipeline validates target, body, and sender.
4. It resolves sender identity.
5. It resolves the target registry row.
6. It runs one targeted discovery repair when needed.
7. It builds the final visible body.
8. It dispatches through provider edges.
9. It records delivery evidence.

The target resolution step is where separation becomes operational. If the target is missing or appears stale, AxiOwl logs the miss and performs a targeted discovery repair. If the target is known but not sendable, the send is rejected with the target's provider, session ID, and last error still attached to the decision. If the target is valid, the pipeline records the canonical display name, provider, provider session ID, and node before handing the work to delivery.

That means a send is not routed by a broad "whatever provider is available" fallback. It is routed by the provider and provider session stored on the resolved registry row.

Provider Edges Keep Delivery Code Separate

After the registry chooses a canonical target, provider_edges.cpp selects the delivery implementation by provider key. Current dispatch paths include providers such as codex, codex_cli, vscode_native, vscode_copilot_backed, antigravity, antigravity_cli, cursor, claude_code_cli, copilot_cli, and opencode_cli.

This dispatch table is a simple but important boundary. Cursor delivery does not accidentally become VS Code native delivery. VS Code native delivery does not accidentally become Copilot-backed VS Code delivery. A registry row with provider remote is not treated as a local-provider fallback; in the current local-provider remediation build, remote delivery returns an explicit out-of-scope result.

The provider support matrix reflects the same separation at the product level. Supported surfaces are listed separately, including Codex agents, Codex CLI, VS Code native agents, Copilot through the VS Code extension, Cursor agents, and Antigravity agents. Target or unsupported surfaces are also separate, so an unfinished CLI path does not inherit support status from a working desktop or extension path.

Receipts Are Not Confused With Proof

AxiOwl also separates "AxiOwl accepted the request" from "the provider accepted the message" and from "the provider replied." The architecture docs define accepted_by_axiowl as a handoff receipt, while provider acceptance and response-backed MCP proof are stronger signals.

That distinction protects operators from over-reading a successful local command. AxiOwl may validate a request, resolve the target, and hand off to the delivery worker before provider delivery is complete. The logs and receipt states preserve that boundary instead of collapsing all success into one vague result.

The strongest proof is a response over MCP with provider-owned sender identity. That is the point where AxiOwl knows the target provider received the message, acted on it, and replied from the expected session context.

Why This Matters in Real Operation

Provider sessions are messy in practice. Chat titles can change. Old extension folders can remain on disk. CLI sessions can need provider-specific metadata patches. A provider app can expose one kind of session ID for a native chat and a different one for a Copilot-backed chat. AxiOwl's design assumes those details are real and keeps them visible.

For an operator, this gives three practical benefits:

• You can address agents by human names while AxiOwl still preserves provider-owned session IDs underneath.
• You can inspect why a target is not sendable instead of watching AxiOwl silently fall through to another route.
• You can distinguish local acceptance, provider acceptance, and end-to-end reply proof.

For developers, the same design makes provider work safer. New provider support has to define discovery, registry enrollment, sender metadata, delivery, and proof. It cannot claim full support just because a command launches.

The Short Version

AxiOwl keeps provider sessions separate by treating each reachable chat as a provider-owned session record, not as a generic text destination. The registry stores the session identity. MCP metadata anchors the sender. The message pipeline resolves and validates the route. Provider edges dispatch to the correct delivery module. Logs preserve the difference between handoff, provider acceptance, and real reply proof.

That is why AxiOwl can coordinate across Codex, Cursor, VS Code, Copilot-backed VS Code, Antigravity, and CLI-oriented provider work without pretending their sessions are interchangeable.