Using AxiOwl With VS Code Copilot

VS Code Copilot is one of the local provider surfaces AxiOwl is designed to coordinate. In the current Windows desktop implementation, AxiOwl does not treat VS Code as a generic chat box. It has a first-party VS Code Copilot-backed bridge extension, installer features for that bridge, local discovery for Copilot-backed sessions, and provider-specific delivery code that routes messages through the bridge instead of guessing at a UI.

That distinction matters. AxiOwl is not just a shortcut launcher. It is a local coordinator with a registry, sender identity rules, MCP support, discovery, and provider-specific edges. For VS Code Copilot, those pieces work together so a named AxiOwl target can refer to a real Copilot-backed session rather than a vague "the VS Code window that happens to be open."

What AxiOwl Installs For VS Code Copilot

The Windows desktop package includes a VS Code extension named axiowl-vscode-copilot-bridge. Its package metadata identifies it as the "AxiOwl VS Code Copilot Bridge" and describes it as a local VS Code Copilot-backed chat bridge for AxiOwl. The extension contributes two AxiOwl commands:

axiowl.vscodeCopilot.reportStatus
axiowl.vscodeCopilot.bridge.execute

The bridge profile in the extension metadata also names the provider as vscode_copilot_backed, the host kind as vscode-copilot, and the MCP provider id as axiowl.vscode-copilot-mcp.

The MSI installer treats this as a separable feature. The release WiX file includes features for installing the VS Code Copilot-backed extension, writing the VS Code Copilot-backed MCP configuration, and applying the VS Code Copilot-backed MCP metadata patch. The installer UI text groups those items together as:

VS Code Copilot-backed: extension, MCP config, metadata patch

The same installer line also has a separate Copilot CLI metadata patch feature. That is related, but it is not the same thing as the VS Code Copilot-backed bridge. The provider support chart marks copilot vsix extension as supported and copilot cli as a target surface.

How The Bridge Registers Itself

When the VS Code extension activates, it creates an "AxiOwl Bridge" output channel, establishes a stable bridge id, writes runtime status, and registers a VS Code-owned MCP server definition if the host provides the required VS Code MCP API.

The MCP server definition points back to the local AxiOwl executable:

axiowl.exe mcp-server --host vscode-copilot --provider vscode_copilot_backed

The extension also passes useful environment metadata into that MCP server process, including the AxiOwl executable path, bridge id, bridge registry path, VS Code session id, machine id, app name, workspace name, workspace URI, and extension id. This is part of AxiOwl's broader sender identity model: provider replies need enough metadata to route back to a real provider session.

The bridge stores its coordination files under the local AxiOwl state area, in a VS Code Copilot-specific registry path:

%LOCALAPPDATA%\AxiOwl\registry\vscode-copilot\vscode-bridge.json

The extension also manages command and result directories beside that registry file. AxiOwl writes a command file, triggers VS Code through the bridge URI, and the extension records events and result files as it handles the command.

Discovery: Turning Copilot Sessions Into AxiOwl Targets

AxiOwl discovery for VS Code Copilot-backed sessions reads Copilot session state from:

%USERPROFILE%\.copilot\session-state

The discovery code walks YAML files under that session-state directory. Each session directory name becomes part of the provider session id, using this shape:

copilot_cli:session:<session-id>

The YAML name: field becomes the visible display name when it is usable. AxiOwl deliberately rejects empty or placeholder titles such as New chat, Untitled, unknown, null, and none. It also marks rows as not sendable if the VS Code Copilot-backed patch health check says the provider path is unhealthy.

That is a practical registry rule, not cosmetic bookkeeping. AxiOwl's registry is durable local state. It maps display names, aliases, providers, provider session ids, node ids, sendability, and discovery source. For this provider, a discovered row uses provider vscode_copilot_backed, source copilot_workspace_yaml, node local, and a provider session id that points to the Copilot session.

From the CLI, discovery is exposed as:

axiowl discover vscode-copilot
axiowl discover copilot-cli
axiowl list agents

The CLI also supports discover all, which includes local VS Code Copilot-backed discovery as part of the broader local provider inventory.

Sending To A VS Code Copilot-Backed Session

The normal AxiOwl send shape is the same as other local targets:

axiowl send --to "<agent>" --body "<message>"

For multiline content, the CLI supports stdin:

Get-Content .\message.txt | axiowl send --to "<agent>" --stdin

Internally, that request goes through the same AxiOwl message pipeline used by other providers:

CLI or MCP request
-> MessagePipeline
-> target and sender validation
-> registry target resolution
-> targeted discovery repair when needed
-> final visible body builder
-> provider_edges dispatch
-> VS Code Copilot provider module
-> bridge command file and VS Code URI trigger

For VS Code Copilot, provider dispatch selects deliver_vscode_copilot_provider. On Windows, that path checks the VS Code Copilot patch health gate, then writes a bridge command with operation send_to_copilot_cli_session. The extension receives that command through the URI handler and attempts to route the prompt to the exact Copilot CLI session using VS Code commands that match the Copilot-backed session surface.

The implementation intentionally records the receipt boundary. A send can be accepted by AxiOwl and handed to the delivery layer before a full provider response exists. In the current VS Code Copilot send path, the provider handoff can be started without waiting for the VS Code bridge result file, and the evidence string explicitly calls out that provider delivery is unverified and that an MCP receipt is required for stronger delivery proof.

That is the right operational expectation: a handoff receipt is useful, but it is not the same as the target model replying through AxiOwl.

Creating And Renaming Copilot-Backed Chats

The CLI usage includes create support for vscode-copilot:

axiowl create --provider vscode-copilot --name "New VS Code Copilot Chat" --body "Start a new Copilot-backed VS Code chat."

The provider implementation requires a non-empty initial message. It asks the VS Code bridge to start a Copilot-backed session, then tries to correlate the created session back to a stable provider session id. If the bridge returns a provider session id directly, AxiOwl enrolls that row in the registry. If not, it compares discovery before and after creation and looks for a single newly discovered Copilot session.

Rename support also exists for the VS Code Copilot-backed provider. AxiOwl sends a /rename <new name> command to the exact session and then waits briefly for discovery to verify that the visible Copilot title changed. If the command is accepted but title verification does not complete, AxiOwl records that as an unverified rename rather than pretending the provider state is proven.

MCP Matters More Than A Shortcut

The developer docs make a clear rule: provider replies must include enough metadata for AxiOwl to identify the sender session, and MCP should fail loudly when that metadata is missing. That rule is especially important in editor-backed surfaces such as VS Code Copilot. Without provider-owned session metadata, a reply could look like it came from "VS Code" without proving which session actually sent it.

The VS Code Copilot bridge therefore does two jobs. First, it gives AxiOwl a controlled way to execute provider-specific VS Code commands. Second, it helps attach the AxiOwl MCP server to the VS Code Copilot host context with explicit metadata about the bridge, workspace, machine, session, and provider.

The article-level takeaway is simple: the bridge exists because the target is a real provider session, not a browser tab or a process name.

Current Boundaries

There are important limits in the current implementation.

The VS Code Copilot-backed provider is a Windows desktop provider. The Linux remote app intentionally supports Codex CLI delivery only. The VS Code Copilot provider code returns a not-supported result on remote Linux rather than attempting GUI or editor automation where the required surface does not exist.

Copilot CLI support is also marked differently from the VS Code Copilot bridge. The support chart lists Copilot CLI as a target surface, while the VS Code Copilot VSIX extension is marked supported. AxiOwl's installer has separate features for the VS Code Copilot-backed extension, MCP configuration, metadata patch, and Copilot CLI metadata patch.

Those boundaries are useful for operators. If you are working locally on Windows with VS Code and Copilot session state present, the VS Code Copilot-backed bridge is the relevant path. If you are on a remote Linux AxiOwl node, expect Codex CLI delivery, not VS Code Copilot delivery.

Why This Is Useful

For a developer, the value is that VS Code Copilot can become one named participant in an AxiOwl workflow. You can discover sessions, list them, send to one by name, create a new Copilot-backed chat with an initial prompt, and keep registry evidence about what happened.

For an operator, the value is traceability. The bridge writes command files, events, runtime status, and result files. The native provider code records whether AxiOwl accepted the request, whether the provider handoff was started, whether a bridge result was observed, and whether stronger proof still depends on a real MCP response.

AxiOwl's VS Code Copilot integration is therefore best understood as a local bridge plus a registry contract. VS Code remains the Copilot host. AxiOwl supplies the routing, sender identity discipline, discovery, and operational records needed to make that host usable inside a multi-agent workflow.