GitHub Copilot Integration with OpenClaw: Login and Setup Guide

GitHub Copilot is GitHub's AI-powered coding assistant. It lets you reach Copilot models through your GitHub account and plan. OpenClaw can leverage Copilot in three distinct ways: as a model provider, as an agent runtime, or both.

Three ways to use Copilot in OpenClaw

Built-in provider (github-copilot)

Acquire a GitHub token through the native device-login flow, then swap it for Copilot API tokens during OpenClaw execution. This approach is the default and most straightforward since it functions without VS Code.

Run the login command

openclaw models auth login-github-copilot

A URL and one-time code will be shown to you. Leave the terminal session open until the process finishes.

Set a default model

openclaw models set github-copilot/claude-opus-4.7

Or within configuration:

{
  agents: {
    defaults: { model: { primary: "github-copilot/claude-opus-4.7" } },
  },
}

Copilot SDK harness plugin (copilot)

Install the external @openclaw/copilot plugin when you want GitHub's Copilot CLI and SDK to manage the low-level agent loop for particular github-copilot/* models.

openclaw plugins install @openclaw/copilot

Then enable the runtime for a model or provider:

{
  agents: {
    defaults: {
      model: "github-copilot/gpt-5.5",
      models: {
        "github-copilot/gpt-5.5": {
          agentRuntime: { id: "copilot" },
        },
      },
    },
  },
}

Pick this option when you prefer native Copilot CLI sessions, thread state handled by the SDK, and compaction managed by Copilot for those agent turns. Without the explicit agentRuntime opt-in, github-copilot/* models continue to rely on the built-in provider. Refer to Copilot SDK harness for the complete runtime contract.

Copilot Proxy plugin (copilot-proxy)

Employ the Copilot Proxy VS Code extension as a local intermediary. OpenClaw communicates with the proxy's /v1 endpoint (default http://localhost:3000/v1) and uses the model list you define.

The copilot-proxy plugin is bundled with OpenClaw and active by default. Set the base URL and model identifiers with:

openclaw models auth login --provider copilot-proxy --set-default

Note

Select this option if Copilot Proxy is already active in VS Code or you need to direct traffic through it. The VS Code extension must remain running.

GitHub Enterprise (data residency)

If your organization operates a data-residency GitHub Enterprise tenant (an *.ghe.com host like your-org.ghe.com), Copilot uses tenant-specific endpoints instead of the public github.com ones. OpenClaw presents this as a built-in authentication option so manual URL editing is unnecessary.

Pick the Enterprise auth choice

During onboarding or openclaw models auth, pick GitHub Copilot (Enterprise / data residency). You will be asked for your Enterprise domain (for instance your-org.ghe.com), after which the device login executes against that tenant.

Provide only the tenant root (your-org.ghe.com). Derived service hosts such as api.your-org.ghe.com or copilot-api.your-org.ghe.com are not valid; OpenClaw automatically derives those endpoints from the tenant root.

openclaw models auth login --provider github-copilot --method device-enterprise

Domain is persisted to config

The selected host is saved within the provider parameters so subsequent token refreshes and completions automatically target the tenant:

{
  models: {
    providers: {
      "github-copilot": { params: { githubDomain: "your-org.ghe.com" } },
    },
  },
}

The device flow, token exchange, and completions resolve to https://your-org.ghe.com/login/device/code, https://api.your-org.ghe.com/copilot_internal/v2/token, and https://copilot-api.your-org.ghe.com respectively. Tokens from data-residency environments include a tenant stamp and omit a proxy hint, so the completions base URL defaults to the tenant Copilot host rather than the public endpoint.

Note

Changing domains always triggers a fresh device login. If you have a stored Copilot token and switch to a different domain (public github.com ↔ a *.ghe.com tenant, or from one tenant to another), OpenClaw discards the existing token and forces a new login so the token is scoped to the domain being saved in config. Running login again for the same domain still offers to reuse the current token. Returning to public github.com removes the persisted githubDomain so the configuration reverts to defaults.

Note

The COPILOT_GITHUB_DOMAIN environment variable overrides the resolved domain for every Copilot path that resolves it: the Enterprise device login (--method device-enterprise), the standalone openclaw models auth login-github-copilot shortcut, token refresh, embeddings, and completions. Set it to your *.ghe.com host for fully headless or CI environments. Leave it unset (and omit the config parameter) to use public github.com. Logins store the domain for which the token was created (and clear it when logging in against public github.com), so routing remains accurate even after the environment variable is removed.

Optional flags

# Skip the re-login confirmation
openclaw models auth login-github-copilot --yes

# Login and set the default model in one step
openclaw models auth login --provider github-copilot --method device --set-default

Non-interactive onboarding

The device-login flow requires an interactive TTY. For headless setups, bring in an existing GitHub OAuth access token with openclaw onboard --non-interactive:

openclaw onboard --non-interactive --accept-risk \
  --auth-choice github-copilot \
  --github-copilot-token "$COPILOT_GITHUB_TOKEN" \
  --skip-channels --skip-health

You can leave out --auth-choice; supplying --github-copilot-token automatically determines the GitHub Copilot provider authentication option. When the flag is omitted, onboarding defaults to COPILOT_GITHUB_TOKEN, then GH_TOKEN, and finally GITHUB_TOKEN. To store an environment-backed tokenRef instead of plaintext inside auth-profiles.json, use --secret-input-mode ref together with COPILOT_GITHUB_TOKEN.

Interactive TTY required

The device-login flow requires an interactive TTY. Execute it directly in a terminal, not within a non-interactive script or CI pipeline.

Model availability depends on your plan

Which Copilot models are available depends on your GitHub plan. If a model gets rejected, try a different ID (for example github-copilot/gpt-5.5). For the current list of models, check GitHub's supported models per Copilot plan.

Live catalog refresh from the Copilot API

Once the device-login (or env-var) authentication path has obtained a GitHub token, OpenClaw refreshes the model catalog on demand from ${baseUrl}/models (the same endpoint used by VS Code Copilot). This allows the runtime to track per-account entitlements and accurate context windows without manifest churn. Newly published Copilot models become visible without an OpenClaw upgrade, and context windows reflect the real per-model limits (for instance, 400k for the gpt-5.x series, 1M for the internal claude-opus-*-1m variants).

The bundled static catalog remains the visible fallback when discovery is disabled, the user has no GitHub auth profile, the token-exchange fails, or the /models HTTPS call errors. To opt out and depend entirely on the static manifest catalog (offline or air-gapped scenarios):

{
  plugins: {
    entries: {
      "github-copilot": {
        config: { discovery: { enabled: false } },
      },
    },
  },
}

Transport selection

Claude model IDs automatically use the Anthropic Messages transport. Gemini models use the OpenAI Chat Completions transport; GPT and o-series models keep the OpenAI Responses transport. OpenClaw picks the correct transport based on the model ref.

Request compatibility

On Copilot transports, OpenClaw sends Copilot IDE-style request headers (VS Code editor/plugin versions and the vscode-chat integration id), marks tool-result follow-up turns as agent-initiated, and sets the Copilot vision header when a turn includes image input.

Environment variable resolution order

OpenClaw resolves Copilot authentication from environment variables in this priority order:

When multiple variables are set, OpenClaw uses the highest-priority one. The device-login flow (openclaw models auth login-github-copilot) stores its token in the auth profile store and takes precedence over all environment variables.

Token storage

The login stores a GitHub token in the auth profile store (profile id github-copilot:github) and exchanges it for a short-lived Copilot API token when OpenClaw runs. You do not need to handle the token manually.

Memory search embeddings

GitHub Copilot can also act as an embedding provider for memory search. If you have a Copilot subscription and have logged in, OpenClaw can use it for embeddings without requiring a separate API key.

Config

Set memory.search.provider explicitly to employ GitHub Copilot embeddings. If a GitHub token is available, OpenClaw discovers available embedding models from the Copilot API and automatically selects the best one.

{
  memory: {
    search: {
      provider: "github-copilot",
      // Optional: override the auto-discovered model
      model: "text-embedding-3-small",
    },
  },
}

How it works

1. OpenClaw resolves your GitHub token (from environment variables or the auth profile).
2. Exchanges it for a short-lived Copilot API token.
3. Queries the Copilot /models endpoint to discover available embedding models.
4. Selects the best model (preference order: text-embedding-3-small, text-embedding-3-large, text-embedding-ada-002).
5. Sends embedding requests to the Copilot /embeddings endpoint.

Model availability depends on your GitHub plan. If no embedding models are available, OpenClaw skips Copilot and attempts the next provider.

Related

• Model selection, Choosing providers, model refs, and failover behavior.

• OAuth and auth, Auth details and credential reuse rules.