How AxiOwl Keeps Provider Bugs Isolated

Provider integrations fail in different ways. A chat app can change a local database shape. A CLI can start returning a new error format. A bridge extension can register the wrong window. A patch-sensitive surface can become unsafe after an update. AxiOwl is built around the assumption that those failures will happen, so it keeps each provider path bounded instead of letting one provider bug become a system-wide routing problem.

The important design choice is that AxiOwl does not treat "AI provider" as one generic pipe. It treats every supported surface as a named provider edge with its own discovery evidence, registry row, install contract, send method, receipt boundary, and diagnostic trail.

Isolation Starts At Install Time

AxiOwl's Windows installer is provider-aware. The source repo separates provider contracts for surfaces such as Codex, Cursor, VS Code native, VS Code Copilot-backed, Antigravity, Claude Code CLI, Copilot CLI, and remote support. The installer contract tests verify that known providers have explicit feature ids, helper actions, checkbox properties, and process scopes.

That matters when something goes wrong. If a Cursor patch action is selected, the action is scoped to Cursor. If a VS Code native action is selected, it is scoped to the VS Code native integration. The tests also check that unchecked providers do not leak into coordinator actions. In other words, selecting one integration should not silently modify a different provider's config or runtime files.

The security docs state the same rule from the operator side: AxiOwl may write selected provider MCP config, selected bridge extension files, selected patch changes, and selected AxiOwl-owned config entries. It should not modify unrelated provider extensions, unrelated settings, unrelated workspace files, unchecked provider surfaces, or remote configuration unless remote support is explicitly selected.

Registry Rows Carry Provider Boundaries

After install and discovery, AxiOwl records provider sessions in a local registry. A row includes the display name, aliases, provider id, provider-owned session id, node id, enabled state, sendable state, source, timestamps, and last error.

That registry shape is one of the main bug-containment mechanisms. A broken provider discovery path does not become a vague global failure. It becomes a concrete row state:

provider = cursor
provider_session_id = cursor:composer:<id>
sendable = false
last_error = <reason>

or:

provider = claude_code_cli
provider_session_id = claude_code_cli:session:<id>
sendable = false
last_error = <reason>

The message pipeline checks this state before routing. If a target is known but not sendable, AxiOwl rejects the send with "target is known but not sendable" and includes the row's last error when available. If discovery finds evidence but no exact sendable target, the pipeline reports that distinction instead of converting weak evidence into delivery confidence.

The tests reinforce this behavior. One core test verifies that weak Codex evidence alone should not create a sendable registry row. Another verifies that a targeted Codex row with IPC owner proof can become sendable. That is the difference between "we saw something that might be a session" and "we have enough proof to route to it."

Provider Edges Are Explicit Dispatch Points

When AxiOwl has a resolved, sendable target, it does not hand the message to a generic catch-all. The provider dispatcher switches on the target provider id and calls the matching provider edge:

codex
codex_cli
vscode_native
vscode_copilot_backed
antigravity
antigravity_cli
cursor
cursor_cli
claude_code_cli
copilot_cli
opencode_cli
remote

If the provider id is unknown, the provider edge returns a failed result with an unknown-provider error. If the current local build sees a remote delivery target that is out of scope, it returns an explicit remote-out-of-scope result. Unsupported create and rename paths also return unsupported-provider errors rather than pretending the action exists.

This is how a provider bug stays local. A Cursor bridge failure returns as a Cursor provider result. A Claude CLI resume failure returns as a Claude provider result. A Codex IPC failure returns as a Codex provider result. The failed edge records its method, state, evidence, and error without rewriting the meaning of other providers.

The Delivery Worker Separates Acceptance From Provider Work

AxiOwl also separates the local message receipt from provider delivery work. The message pipeline accepts a request, validates sender and target identity, resolves the route, builds the final visible body, then starts a delivery-worker handoff.

The receipt boundary is explicit. A returned accepted_by_axiowl receipt means AxiOwl accepted the request and handed it toward delivery. It does not mean the provider displayed the message or replied. The support docs tell operators not to confuse these events:

MSI install succeeded
accepted_by_axiowl
provider accepted
MCP reply received

Those are separate milestones. The core tests check that the send receipt is accepted_by_axiowl, that it does not report provider acceptance, and that the log records the boundary as after target resolution and before delivery worker or provider work.

This makes provider bugs easier to diagnose. If AxiOwl accepts the message but the provider edge fails later, the failure is in the delivery layer or provider edge, not in sender parsing or target resolution. If AxiOwl rejects the message before handoff, the failure is earlier: missing body, missing sender identity, missing target, stale registry row, or non-sendable target.

Cursor Bugs Stay In The Cursor Bridge

Cursor is a good example because its integration has several moving parts. The Cursor provider code reads a Cursor bridge registry, chooses an agent-window bridge, writes a command file, waits for a result file, and checks that the result came from the expected bridge and the expected surface.

If the Cursor patch is unhealthy, the Cursor provider edge blocks send with a Cursor-specific patch-status gate. If the operation is empty, it fails with "no fallback is allowed." If a bridge result is handled by the wrong bridge, AxiOwl fails that Cursor command instead of accepting a possibly misdelivered message. If the handled surface is not the Cursor agent window, it fails that result too.

Those checks are intentionally narrow. A Cursor bridge bug does not change Codex routing. It does not mark Claude sessions broken. It does not downgrade the global registry. It produces Cursor evidence that an operator can inspect in the Cursor bridge registry, command file, result file, and AxiOwl logs.

CLI Bugs Stay In Their CLI Edges

CLI-based providers get the same treatment. Claude Code CLI delivery checks for a valid claude_code_cli:session:<uuid> provider session id, locates the Claude executable, finds the JSONL session file, verifies the session working directory still exists, writes a session-specific MCP config, then runs Claude with the expected resume arguments. If any of those provider-specific conditions fail, the result is a Claude provider failure with evidence such as the missing executable, missing session file, missing cwd, nonzero exit code, or provider-reported error response.

Codex has separate paths for desktop IPC on Windows and CLI resume elsewhere. Codex CLI delivery writes the message to a temp file, resumes the target thread id, captures output, and records whether the command completed. If the CLI changes behavior, the failure stays attached to the Codex edge and its evidence.

Copilot CLI discovery also shows the same cautious pattern. The tests verify that Copilot CLI discovery filters to standalone CLI sessions and does not mark a row sendable without explicit headless auth proof. A discovered file is not automatically treated as a usable delivery path.

Diagnostics Are Designed For Containment

The support guide tells operators to collect AxiOwl logs, registry state, runtime files, MSI verbose logs, provider output channels, provider CLI stdout and stderr, and relevant provider session files when safe. It also lists provider-specific failure patterns:

• missing MCP tools can be session startup, config, executable path, or provider metadata.
• bad discovery can be stale paths, old session names, changed provider databases, or skipped provider selection.
• Cursor failures can be patch visibility, bridge registration, command watcher state, or wrong result ownership.
• VS Code failures can be bridge extension install, MCP visibility, native session mapping, or window ownership.
• stale paths can come from provider state, AxiOwl config, registry rows, inherited provider defaults, or provider session metadata.

That style of diagnosis is not accidental. AxiOwl logs fields such as provider, target, session id, node, stage, result, method used, evidence, and error. The delivery worker emits parse failures separately from provider dispatch results. The pipeline logs whether a target was found, repaired by targeted discovery, still missing, known but not sendable, accepted locally, or handed to delivery.

Why This Helps Operators

Provider bugs are unavoidable because AxiOwl integrates with real applications, CLIs, local databases, MCP configs, bridge extensions, and sometimes patch-sensitive surfaces. The practical goal is not to pretend those surfaces are stable forever. The goal is to make the blast radius small.

For an operator, that means:

• a broken provider path should fail loudly.
• a weak discovery signal should not become a sendable target.
• a local receipt should not claim provider delivery proof.
• selected provider install actions should not touch unchecked providers.
• provider-specific evidence should point to the failing surface.
• unsupported paths should be reported as unsupported.

This is why AxiOwl's provider model is deliberately explicit. Each provider gets a named edge, a concrete registry identity, and a separate evidence trail. When a provider changes under AxiOwl, the system can show where the break happened instead of turning it into an ambiguous "AxiOwl failed" event.

The Short Version

AxiOwl keeps provider bugs isolated by refusing to blur boundaries. Install actions are selected-provider-specific. Registry rows preserve provider and session identity. Sendability is gated by evidence. The message pipeline separates local acceptance from provider delivery. The delivery worker dispatches to one provider edge at a time. Logs and receipts distinguish what AxiOwl accepted from what the provider actually did.

That is what makes AxiOwl useful as a coordinator: it can connect different provider sessions without pretending they all behave the same way, and when one provider surface breaks, the failure remains inspectable, contained, and tied to the provider that produced it.