GitHub Copilot Sign-In for OpenClaw: Device Flow and Token Import

GitHub Copilot is the AI coding assistant built by GitHub. Through it, you get access to Copilot models tied to your GitHub account and plan. OpenClaw supports Copilot as either a model provider or an agent runtime, and there are three distinct ways to set this up.

Three ways to use Copilot in OpenClaw

Built-in provider (github-copilot)

The native device-login flow is how you get a GitHub token. By default, that token goes into OpenClaw's protected local secret store, and only a tokenRef is written to the auth profile. At runtime, OpenClaw checks Copilot access and works out the Copilot API endpoint that belongs to your account. This path is the default and the simplest one, since no VS Code is needed.

Run the login command

openclaw models auth login-github-copilot

A URL and a one-time code will be shown to you. Leave the terminal running until the flow finishes.

Set a default model

openclaw models set github-copilot/claude-sonnet-5

Or in config:

{
  agents: {
    defaults: { model: { primary: "github-copilot/claude-sonnet-5" } },
  },
}

Copilot SDK harness plugin (copilot)

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

openclaw plugins install @openclaw/copilot

Next, opt a model or provider into that runtime:

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

Pick this option when you need native Copilot CLI sessions, thread state managed by the SDK, and compaction handled by Copilot for those agent turns. Unless you explicitly opt in with agentRuntime, github-copilot/* models continue to use the built-in provider. The full runtime contract is described in Copilot SDK harness.

Copilot Proxy plugin (copilot-proxy)

The Copilot Proxy VS Code extension can serve as a local bridge. OpenClaw sends requests to the proxy's /v1 endpoint (http://localhost:3000/v1 by default) and relies on the model list that you configure.

The copilot-proxy plugin comes bundled with OpenClaw and is on by default. Set the base URL and model ids like this:

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

Note

Pick this option when Copilot Proxy already runs in your VS Code, or when traffic has to go through it. The VS Code extension has to remain running.

GitHub Enterprise (data residency)

When your organization runs a data-residency GitHub Enterprise tenant (a *.ghe.com host, for example your-org.ghe.com), Copilot is served from tenant-local endpoints instead of the public github.com. OpenClaw treats this as a first-class auth choice, so no manual URL editing is needed.

Pick the Enterprise auth choice

During onboarding or in openclaw models auth, select GitHub Copilot (Enterprise / data residency). You will be asked for your Enterprise domain (your-org.ghe.com, for instance), and the device login then runs against that tenant.

Supply 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 rejected; OpenClaw works those endpoints out from the tenant root on its own.

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

Domain is persisted to config

The host you pick is saved in the provider params, so later account validation and completions automatically target the tenant:

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

Both the device flow and account validation go through the tenant's GitHub endpoints, while Copilot requests use https://copilot-api.your-org.ghe.com. As a result, authentication and inference both stay on the configured data-residency tenant rather than the public endpoints.

Note

Changing domains always triggers a new device login. Suppose a Copilot token is already stored and you select a different domain (public github.com ↔ a *.ghe.com tenant, or one tenant ↔ another): OpenClaw will not reuse that token. It forces a fresh login so the token is scoped to the domain being written to config. Re-running login for the same domain still offers to reuse the current token. Going back to public github.com clears the persisted githubDomain, which returns config to the default.

Copilot credentials are shared between agents only when their normalized, supported tenant scopes match. Doctor keeps credentials for different tenants, so authenticate each affected agent for the tenant it is meant to use rather than deleting its local credential.

Note

For every Copilot path that resolves the domain, the COPILOT_GITHUB_DOMAIN environment variable overrides the result: the Enterprise device login (--method device-enterprise), the standalone openclaw models auth login-github-copilot shortcut, account validation, embeddings, and completions. For fully headless or CI setups, set it to your *.ghe.com host. To use public github.com, leave it unset and keep the config param absent. Logins record the domain they minted the token for (and clear it when logging in against public github.com), so routing stays correct even after the environment variable is removed.

Tenant request identity

By default OpenClaw uses the copilot-developer-cli request identity, data-residency tenants included. Start by verifying that your enterprise allows Copilot CLI and the model you selected. A *.ghe.com hostname does not mean a different integration policy applies.

Should your tenant administrator or GitHub support require another identity, use the provider header setting that already exists:

{
  models: {
    providers: {
      "github-copilot": {
        params: { githubDomain: "your-org.ghe.com" },
        headers: { "Copilot-Integration-Id": "vscode-chat" },
      },
    },
  },
}

This provider identity covers model selection during setup, live model discovery, inference, and embeddings. Header names are case-insensitive, and request.headers wins over provider headers. For embedding discovery and requests, embedding-specific memory.search.remote.headers still takes precedence. Provider headers that are unrelated are not forwarded to the catalog or embedding endpoints. Changing the identity does not give you access to models or clients that your organization's policy has disabled.

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

An interactive TTY is required for the device-login flow. In headless environments, import a GitHub OAuth access token you already have by using 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 may leave out --auth-choice as well; supplying --github-copilot-token implies the GitHub Copilot provider auth choice. When the flag is absent, onboarding defaults to COPILOT_GITHUB_TOKEN. Neither generic GH_TOKEN nor GITHUB_TOKEN turns the provider on or authenticates it. To keep an env-backed tokenRef in the auth profile store rather than plaintext, pass --secret-input-mode ref with COPILOT_GITHUB_TOKEN set.

A fresh non-interactive setup checks the token before it is saved. Where setup has to pick a default, it consults the live Copilot model catalog too. If the provider's current general-purpose model is enabled for the account, OpenClaw prefers it; if not, an eligible fallback is chosen in a fixed order. Should the account have no picker-visible model that supports streaming and tool calls, setup fails and no new auth profile is written. A default model you configured explicitly is never swapped out.

Interactive TTY required

An interactive TTY is required for the device-login flow. Run it straight from a terminal; a non-interactive script or CI pipeline is not a suitable place for it.

Model availability depends on your plan

Which Copilot models you can use is governed by your GitHub plan and organization policy. The live catalog feeds the model picker during interactive onboarding, whereas non-interactive onboarding picks an eligible model on its own. GitHub's supported models per Copilot plan lists the models currently available.

Live catalog refresh from the Copilot API

After the device-login (or env-var) auth path resolves a GitHub token, OpenClaw pulls the model catalog on demand from ${baseUrl}/models, the same endpoint VS Code Copilot uses. That keeps the runtime aligned with per-account entitlement and accurate context windows, with no manifest churn. Models hidden from GitHub's picker or disabled by account policy are left out of the visible live catalog. Defaults chosen by automatic setup have the extra requirement of streaming and tool-call support. New Copilot models show up without an OpenClaw upgrade, and context windows track the real per-model limits (e.g. 400k for the gpt-5.x series, 1M for the internal claude-opus-*-1m variants).

When a refresh fails, the failure is reported and the last successful inventory is kept, or the bundled models if no refresh has succeeded yet. A successful empty response wipes discovered models. With no Copilot credentials present, no live request is made. Copilot needs explicit provider configuration, a saved Copilot auth profile, or COPILOT_GITHUB_TOKEN, all within the agent's model scope. The former plugins.entries.github-copilot.config.discovery.enabled switch has been retired: config loading ignores it, and Doctor strips it when saving the config. It no longer blocks live requests for configured Copilot auth.

Transport selection

Claude model IDs are routed over the Anthropic Messages transport automatically. Gemini models go through the OpenAI Chat Completions transport, while GPT and o-series models stay on the OpenAI Responses transport. These transports and request compatibility settings are part of the bundled static catalog, so Gemini still uses Chat Completions when live discovery is not available. If your account's model list names the endpoints a model supports and the default transport is not among them, OpenClaw switches to a listed endpoint, which lets Chat Completions-only models such as kimi-k3 work.

Thinking levels

Reach for /think xhigh or /think max when the chosen model exposes that level. The supported efforts for your account come from Copilot's live catalog, and OpenClaw carries those efforts through in Responses requests. If a Responses model's native effort range begins at low, then minimal is mapped to low rather than sending a value the model does not support. Explicit live limits win over the bundled catalog. Gemini's Chat Completions transport does not expose max. A Claude model whose live entry lists xhigh gets adaptive thinking even before OpenClaw recognizes its model ID. Session and per-message controls are covered in Thinking levels.

Request compatibility

Requests to Copilot go out with Copilot-compatible headers carrying a Copilot CLI request identity; follow-up turns that return tool results are marked as agent-initiated, and the Copilot vision header is set whenever a turn includes image input.

Environment credentials

For this provider, COPILOT_GITHUB_TOKEN is the only credential picked up automatically from the environment. Generic GH_TOKEN and GITHUB_TOKEN stay usable by other GitHub tools and remain subject to secret auditing and cleanup. When only generic GitHub auth is present, Doctor flags the activation change once and tells you to sign in or set COPILOT_GITHUB_TOKEN.

The device-login flow saves a protected-store tokenRef in the Copilot auth profile. A profile you selected explicitly stays selected; an unscoped lookup may use COPILOT_GITHUB_TOKEN until the first profile is saved.

Token storage

Device login writes the GitHub token to OpenClaw's protected local secret store by default, and only a tokenRef goes into the auth profile (profile id github-copilot:github). No external secret provider needs to be configured for the built-in store. Should OpenClaw be unable to write the store, login halts before the auth profile is replaced and reports that the state-directory or database permissions require repair.

For compatibility, interactive onboarding respects an explicit --secret-input-mode plaintext choice. In that mode the token is stored inline, the choice is reported, and it stays visible to openclaw secrets audit --check.

OpenClaw's user-facing secret APIs can write to the protected store but not read from it, and the store is not encrypted at rest: its SQLite file depends on state-directory permissions. At runtime OpenClaw resolves the reference, validates Copilot access, resolves the account-specific API endpoint, and sends Copilot requests with the GitHub token. Runtime authentication needs no manual handling on your part.

Usage checks rely on the selected profile's GitHub token as well. For OAuth profiles that carry a tenant domain, usage follows that domain ahead of the provider's configured domain. COPILOT_GITHUB_DOMAIN still takes precedence.

Memory search embeddings

GitHub Copilot can serve as an embedding provider for memory search too. With a Copilot subscription and a completed login, OpenClaw can produce embeddings through it and no separate API key is needed.

Config

To use GitHub Copilot embeddings, set memory.search.provider explicitly. When a GitHub token is available, OpenClaw queries the Copilot API for embedding models and chooses the best one automatically.

{
  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 env vars or auth profile).
2. It validates Copilot access and resolves the account-specific API endpoint.
3. It queries the Copilot /models endpoint to discover available embedding models, under a 10-second deadline that includes reading the response body.
4. It picks the best model (preference order: text-embedding-3-small, text-embedding-3-large, text-embedding-ada-002).
5. Embedding requests are sent to the Copilot /embeddings endpoint.

Which models you get depends on your GitHub plan. If discovery fails or no embedding models exist, OpenClaw falls back to memory.search.fallback only when you have explicitly configured another provider. Otherwise setup surfaces the error rather than quietly switching providers.

Related

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

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