# GitHub Copilot joins AI SDK HarnessAgent: swap runtimes without rewriting your agent UI

> Vercel’s @ai-sdk/harness-github-copilot adapter puts Copilot behind HarnessAgent via ACP—same session API, pinned sandbox CLI, and real production limits.
> By Dave · 2026-09-16
> Source: https://otf-kit.dev/blog/github-copilot-ai-sdk-harness

On September 10, 2026, Vercel added GitHub Copilot to the AI SDK harness layer through `@ai-sdk/harness-github-copilot`. If your product already runs coding agents behind `HarnessAgent`, that adapter is the missing swap: same session API, same stream shapes, Copilot as one more runtime you can select without rewriting the chat UI.

This post is for builders who ship agent products (or internal agent routes) and need Copilot in the same control plane as Claude Code, Codex, Cursor, and the other listed harnesses — not for people hunting a generic Copilot desktop tip.

## What actually shipped

[Vercel's changelog](https://vercel.com/changelog/github-copilot-ai-sdk-harness-adapter) is short and precise: pass `githubCopilot` into `HarnessAgent`, and the adapter uses `@ai-sdk/harness-acp` to talk to GitHub Copilot over the Agent Client Protocol (ACP). Copilot joins the documented adapter set beside Claude Code, Cline, Codex, Cursor, Deep Agents, fx, Grok Build, OpenCode, and Pi.

The [GitHub Copilot harness docs](https://ai-sdk.dev/providers/ai-sdk-harnesses/github-copilot) add the operational detail that matters in production:

- The ACP harness installs a **pinned** GitHub Copilot CLI **inside the sandbox** on first session start.
- It never reuses a host or globally installed Copilot CLI.
- Automatic CLI updates are disabled for that bootstrap so the installed version stays fixed.
- Runtime location for Copilot is **sandbox via ACP**, same class as Cursor, fx, and Grok Build in the adapter capability table.

Harness packages are still experimental. Expect breaking changes. Treat the adapter as a product seam you version and test, not as a forever-stable public API.

![Vercel changelog: GitHub Copilot AI SDK harness adapter, captured 2026-09-16 from https://vercel.com/changelog/github-copilot-ai-sdk-harness-adapter](https://cdn.otf-kit.dev/blog/github-copilot-ai-sdk-harness/competitor-vercel-changelog-20260916.png)

## Why the harness layer is the right place for Copilot

A harness is larger than a model call. Per the [AI SDK harnesses overview](https://ai-sdk.dev/docs/ai-sdk-harnesses/overview), a harness owns workspace access, built-in coding tools, native session state, compaction, permission flows, and runtime-specific configuration. Providers expose models to `generateText` / `streamText`. Harnesses expose agent runtimes to `HarnessAgent`.

That split is the product win. Your UI and route handlers stay on AI SDK stream primitives (`text`, `stream`, `steps`, `usage`, `responseMessages`). The runtime behind the session can change when a new adapter lands. Copilot joining that list means you can A/B or tenant-select runtimes without forking the product shell.

![Decision board comparing one HarnessAgent UI to multiple harness adapters including Copilot](https://cdn.otf-kit.dev/blog/github-copilot-ai-sdk-harness/inbody-decision-20260916.png)

## How do I wire Copilot into HarnessAgent today?

Install the harness core, the Copilot adapter, and a sandbox provider:

```bash
pnpm add @ai-sdk/harness @ai-sdk/harness-github-copilot @ai-sdk/sandbox-vercel
```

Minimal server-side shape from the official docs:

```ts
import { HarnessAgent } from '@ai-sdk/harness/agent';
import { githubCopilot } from '@ai-sdk/harness-github-copilot';
import { createVercelSandbox } from '@ai-sdk/sandbox-vercel';

const agent = new HarnessAgent({
  harness: githubCopilot,
  model: 'gpt-5.5',
  sandbox: createVercelSandbox({
    runtime: 'node24',
    ports: [4000],
  }),
});

const session = await agent.createSession();

try {
  const result = await agent.stream({
    session,
    prompt: 'Check the test failures and fix the production code.',
  });

  for await (const part of result.stream) {
    if (part.type === 'text-delta') {
      process.stdout.write(part.text);
    }
  }
} finally {
  await session.destroy();
}
```

`githubCopilot` is equivalent to `createGitHubCopilot()` with defaults. For Vercel Sandbox, provide `VERCEL_OIDC_TOKEN` plus the auth variables your chosen path needs (see below). Copilot requires a **network sandbox with at least one exposed port** because the first session installs the CLI over the network, and later model / GitHub / MCP traffic also needs egress.

## Authentication choices you should make on purpose

The adapter supports direct GitHub auth and AI Gateway auth. Relevant environment variables from the docs:

- `COPILOT_GITHUB_TOKEN`, `GH_TOKEN`, `GITHUB_TOKEN`
- `VERCEL_OIDC_TOKEN`, `AI_GATEWAY_API_KEY`, `AI_GATEWAY_BASE_URL`

Defaults matter. `auth: 'auto'` selects AI Gateway when Gateway credentials are present, otherwise direct GitHub Copilot authentication. Fine-grained personal access tokens need the **Copilot Requests** permission; classic PATs are unsupported. Force a route when both credential kinds exist:

```ts
import { createGitHubCopilot } from '@ai-sdk/harness-github-copilot';

const directHarness = createGitHubCopilot({ auth: 'direct' });
const gatewayHarness = createGitHubCopilot({ auth: 'ai-gateway' });
```

AI Gateway model requests do not require GitHub authentication, but built-in GitHub MCP capabilities do. Keep credentials at the host boundary; the adapter can broker them into the sandbox for matching outbound requests when the sandbox supports request transforms. That pairs cleanly with the native-subscription harness auth story already covered in [AI SDK harness auth: keep native subscriptions on the host boundary](/blog/ai-sdk-harness-native-auth).

![Host boundary holding credentials while a sandboxed Copilot ACP bridge runs tools](https://cdn.otf-kit.dev/blog/github-copilot-ai-sdk-harness/inbody-auth-boundary-20260916.png)

## Permissions, tools, and limits that change your product design

Shared ACP permission modes still apply when Copilot asks for permission: `allow-reads`, `allow-edits`, and `allow-all`. Shell execution still needs approval under `allow-edits`. The adapter maps `bash`, `grep`, and `glob` to common harness tools; other Copilot tools stay under native names (`view`, `create`, `edit`, `web_fetch`, `skill`, `sql`, agent tools, `task`, and dynamic GitHub / MCP tools).

Read the known limitations before you promise a feature in your product:

- GitHub Copilot does **not** currently support built-in tool approval requests — use `permissionMode: 'allow-all'` with this adapter (host-executed AI SDK tool approvals still work).
- Schema-backed structured output is unsupported over Copilot ACP.
- `askUserQuestions` is unsupported.
- Reasoning content is not surfaced over ACP; `reasoningEffort` controls depth, not visibility.
- Built-in Copilot tool filtering throws an unsupported-capability error (host tool filtering still works).
- ACP v1 gaps remain: no portable mid-turn steering, no stable name for every native tool event, inferred step boundaries when usage totals are missing.

Those limits are product requirements, not footnotes. If your UX depends on structured output or mid-turn steering, keep another harness on the menu and route Copilot only where those gaps are acceptable.

## What stays yours when Copilot is just another adapter

Swapping runtimes is not the same as owning the product loop. Your repo still owns session policy, which harness each tenant may use, which tools are host-executed versus harness-native, budget and audit hooks, and the acceptance checks an agent must pass before merge. Paid full-stack kits on [OTF templates](https://otf-kit.dev/templates) ship owned application code plus `CLAUDE.md`, `.cursorrules`, and tested prompts so agents extend a known product instead of regenerating a sandbox demo — use that spine whether the harness behind `HarnessAgent` is Copilot, Codex, or Cursor.

If you already route coding agents through AI Gateway for spend and failover, keep reading [Gemini 3.8 Live on AI Gateway](/blog/gemini-3-8-live-ai-gateway) for the realtime lane and [OpenAI Agents on Vercel](/blog/vercel-openai-agents-sandbox) for the Queue + Sandbox hosting seam. Copilot-in-harness is the runtime-selection piece; those posts cover adjacent production seams.

Ship the adapter behind a feature flag. Pin package versions. Add a smoke session that creates, streams one prompt, and destroys. Then decide which tenants get Copilot based on the limitation list above — not based on launch-day excitement alone.

## Sources

- [GitHub Copilot is now available in the AI SDK harness layer (Vercel changelog, Sep 10, 2026)](https://vercel.com/changelog/github-copilot-ai-sdk-harness-adapter)
- [AI SDK Harnesses: GitHub Copilot](https://ai-sdk.dev/providers/ai-sdk-harnesses/github-copilot)
- [AI SDK Harnesses: Overview](https://ai-sdk.dev/docs/ai-sdk-harnesses/overview)
- [AI SDK Harnesses: Harness Adapters](https://ai-sdk.dev/docs/ai-sdk-harnesses/harness-adapters)