GitHub Copilot harness — guide

The GitHub Copilot package lets you run your MeshWeaver chat threads on the GitHub Copilot CLI, under your own GitHub account. Your threads, your mesh content and the mesh tools stay as they are; what changes is the engine that executes each round of the conversation.

It is for people who already have GitHub Copilot and want MeshWeaver's threads to use that account rather than the models the mesh provides.

Key concepts

• A harness, not an agent. A harness decides what executes the round, not which agent you talk to. Switching a thread back to the standard MeshWeaver path loses nothing.
• Personal, access-based opt-in. Getting the package gives you access to it, and the chat's harness picker offers the harnesses of every package you can read — so the harness appears in your picker, and in no one else's who has not got the package. Nothing is copied into your home for this. (On installations that still copy app content into homes, the older behaviour, the Store also places a copy at {you}/Harness/Copilot.) There is no shared key, and nothing is billed to the mesh.
• One Copilot session per thread. Each mesh thread maps to one Copilot session, and every round resumes it, so the CLI keeps the thread's context and tool results itself and only your new message is sent. When a session cannot be resumed — the first round, or a pruned session store — the harness creates it again and hands it the thread's earlier turns as a transcript.
• The mesh as the workspace. Each session is connected to MeshWeaver's MCP server, acting as you under your own credentials, so mesh access control applies unchanged. Your selectable MeshWeaver agents are passed to the session as part of its instructions.

What the installation must provide

Two things are the operator's job, separate from your opt-in:

• The runtime module. The harness runtime is this package's own module, MeshWeaver.AI.Copilot; the deployment must load it. The feature flag Features:Ai:Clis:Copilot does not deliver or load the module by itself.
• The Copilot CLI installed beside the portal, where the runtime can start it.

When either is missing, the harness is not available to run your threads, whatever you install.

Typical workflow

1. Get the package from the Store.
2. Open a thread and pick GitHub Copilot as the harness.
3. Run /login to connect your GitHub account. If a round finds you are not logged in, the thread offers the /login step again rather than failing silently.
4. Chat as usual. Responses stream into the thread; each tool call and its result is shown, with mesh tools named mcp__{server}__{tool} as in the other harnesses.

Uninstalling removes only a legacy home copy ({you}/Harness/…) where your installation made one; it does not revoke your access to the package, so the picker keeps offering the harness and threads that selected it keep using it. To stop using it, switch each thread to another harness — or to the standard MeshWeaver agent path — in the picker; nothing breaks and no history is lost.

Long rounds

The session timeout is an idle bound (two minutes by default), re-armed on every event the CLI emits. A round that does real tool work for a long time keeps running; only a CLI that has gone silent is stopped.

What you get

• GitHub Copilot as an execution engine for every MeshWeaver thread you choose.
• Continuity across rounds through Copilot's own session store.
• The full mesh toolset through the MCP back-connection, under your own permissions.
• Your account, your login, your picker — nothing shared.

The other execution harnesses — Claude Code, OpenAI Codex, Cursor, Grok Build and Google Antigravity — work the same way and can be installed side by side; each thread picks one.