GitHub Copilot Integration with OpenClaw: Setup and Configuration

GitHub Copilot functions as GitHub's AI-powered coding assistant. Through your GitHub account and plan, it grants access to Copilot models. OpenClaw offers three distinct approaches for employing Copilot either as a model provider or as an agent runtime.

Three ways to use Copilot in OpenClaw

Built-in provider (github-copilot)

A GitHub token is obtained through the native device-login flow. By default, OpenClaw stores this token in its protected local secret store, with only a tokenRef saved in the auth profile. When OpenClaw executes, it verifies Copilot access and determines the account-specific Copilot API endpoint. Since no VS Code dependency exists, this stands as the default and most straightforward option.

Run the login command

openclaw models auth login-github-copilot

A URL will be shown for you to visit, along with a one-time code to enter. Until the process finishes, leave the terminal open.

Set a default model

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

Alternatively, through config:

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

Copilot SDK harness plugin (copilot)

When you need GitHub's Copilot CLI and SDK to manage the low-level agent loop for specific github-copilot/* models, install the external @openclaw/copilot plugin.

openclaw plugins install @openclaw/copilot

After that, designate a model or provider for the runtime:

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

Opt for this approach when you require native Copilot CLI sessions, SDK-managed thread state, and Copilot-owned compaction for those agent turns. Without the explicit agentRuntime opt-in, github-copilot/* models continue relying on the built-in provider. The complete runtime contract is documented in Copilot SDK harness.

Copilot Proxy plugin (copilot-proxy)

The Copilot Proxy VS Code extension serves as a local bridge. OpenClaw connects to the proxy's /v1 endpoint (defaulting to http://localhost:3000/v1) and employs the model list you define.

OpenClaw ships with the copilot-proxy plugin, which is active by default. Set the base URL and model ids as follows:

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

Note

Select this path when Copilot Proxy already runs in VS Code or when routing through it is necessary. The VS Code extension must remain active.

GitHub Enterprise (data residency)

For organizations operating a data-residency GitHub Enterprise tenant (a *.ghe.com host like your-org.ghe.com), Copilot resides on tenant-local endpoints instead of public github.com. OpenClaw treats this as a first-class auth option, eliminating the need for manual URL editing.

Pick the Enterprise auth choice

During onboarding or in openclaw models auth, pick GitHub Copilot (Enterprise / data residency). After you provide your Enterprise domain (for instance your-org.ghe.com), the device login executes against that tenant.

Provide only the tenant root (your-org.ghe.com). Derived service hosts including api.your-org.ghe.com or copilot-api.your-org.ghe.com will be rejected; 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 provider params retain the chosen host, so subsequent account validation and completions automatically target the tenant:

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

Tenant GitHub endpoints handle the device flow and account validation, while Copilot requests go through https://copilot-api.your-org.ghe.com. Both authentication and inference thus stay on the configured data-residency tenant rather than the public endpoints.

Note

A domain switch always triggers the device login again. If a Copilot token is already stored and you select a different domain (public github.com ↔ a *.ghe.com tenant, or moving between tenants), OpenClaw refuses to reuse the existing token; instead, it forces a fresh login so the token matches the domain being written to config. For the same domain, re-running login still offers token reuse. Returning to public github.com removes the persisted githubDomain, restoring config to its default state.

Note

Every Copilot path that resolves the domain respects the COPILOT_GITHUB_DOMAIN environment variable as an override: the Enterprise device login (--method device-enterprise), the standalone openclaw models auth login-github-copilot shortcut, account validation, embeddings, and completions all honor it. For fully headless or CI environments, set it to your *.ghe.com host. When unset (and with no config param present), public github.com is used. Logins record the domain for which the token was minted (and clear that record when logging in against public github.com), so routing remains accurate even after the environment variable is removed.

Tenant request identity

By default, OpenClaw adopts the copilot-developer-cli request identity, which includes data-residency tenants. Before proceeding, verify that your enterprise allows Copilot CLI and the selected model. A *.ghe.com hostname does not indicate a different integration policy.

Should your tenant administrator or GitHub support require a distinct identity, apply the existing provider header setting:

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

Model selection during setup, live model discovery, inference, and embeddings all use the provider identity. Header names ignore case; request.headers overrides provider headers. For embedding discovery and requests, embedding-specific memory.search.remote.headers still wins. Unrelated provider headers are not passed along to the catalog or embedding endpoints. Changing the identity does not grant 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 mandatory for the device-login flow. For headless setup, bring in an existing GitHub OAuth access token via 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 drop --auth-choice entirely; supplying --github-copilot-token implies the GitHub Copilot provider auth choice. When that flag is absent, onboarding tries COPILOT_GITHUB_TOKEN, then GH_TOKEN, and finally GITHUB_TOKEN. To persist an env-backed tokenRef rather than a plaintext value in the auth profile store, pass --secret-input-mode ref with COPILOT_GITHUB_TOKEN configured.

A fresh non-interactive setup validates the token prior to persisting it. When a default must be selected, the live Copilot model catalog is consulted as well. OpenClaw picks the provider's current general-purpose model if that model is enabled for the account; otherwise, a deterministic eligible fallback is chosen. If the account has no picker-visible model that supports both streaming and tool calls, setup aborts without writing a new auth profile. An explicitly configured default model is left untouched.

Interactive TTY required

The device-login flow demands an interactive TTY. Execute it directly in a terminal, never inside a non-interactive script or CI pipeline.

Model availability depends on your plan

Which Copilot models are available hinges on your GitHub plan and organization policy. Interactive onboarding pulls from the live catalog for its model picker, whereas non-interactive onboarding picks an eligible model on its own. Consult GitHub's supported models per Copilot plan for the latest model list.

Live catalog refresh from the Copilot API

Once the device-login (or env-var) auth path yields a GitHub token, OpenClaw refreshes the model catalog on demand from ${baseUrl}/models (the same endpoint VS Code Copilot uses), so the runtime tracks per-account entitlement and accurate context windows without manifest churn. Models hidden from GitHub's picker or disabled by account policy are excluded from the visible live catalog. Automatic setup defaults additionally require streaming and tool-call support. Newly published Copilot models show up without an OpenClaw upgrade, and context windows reflect the real per-model limits (e.g. 400k for the gpt-5.x series, 1M for the internal claude-opus-*-1m variants).

The bundled static catalog serves as the visible fallback when discovery is disabled, the user has no GitHub auth profile, runtime authentication fails, or the /models HTTPS call errors. To opt out and rely entirely on the static manifest catalog (offline / 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. The bundled static catalog includes these transports and request compatibility settings, so Gemini keeps using Chat Completions when live discovery is disabled or unavailable.

Thinking levels

Use /think xhigh or /think max when the selected model exposes that level. Copilot's live catalog determines the supported efforts for your account, and OpenClaw preserves those efforts in Responses requests. When a Responses model starts its native effort range at low, minimal maps to low instead of sending an unsupported value. Explicit live limits take precedence over the bundled catalog. Gemini's Chat Completions transport does not expose max. See Thinking levels for session and per-message controls.

Request compatibility

OpenClaw sends Copilot-compatible request headers with a Copilot CLI request identity, marks tool-result follow-up turns as agent-initiated, and sets the Copilot vision header when a turn carries image input.

Environment variable resolution order

OpenClaw resolves Copilot auth from environment variables in the following priority order:

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

Token storage

By default, device login stores the GitHub token in OpenClaw's protected local secret store and writes only a tokenRef to the auth profile (profile id github-copilot:github). The built-in store does not require a configured external secret provider. If OpenClaw cannot write the store, login stops before replacing the auth profile and reports that the state-directory or database permissions need repair.

Interactive onboarding honors an explicit --secret-input-mode plaintext choice for compatibility. That mode stores the token inline, reports the choice, and remains visible to openclaw secrets audit --check.

The protected store is write-only through OpenClaw's user-facing secret APIs, but it is not encrypted at rest; its SQLite file relies on state-directory permissions. At runtime, OpenClaw resolves the reference, validates Copilot access, resolves the account-specific API endpoint, and uses the GitHub token for Copilot requests. You do not need to manage runtime authentication manually.

Usage checks also use the selected profile's GitHub token. For OAuth profiles that carry a tenant domain, usage follows that domain before the provider's configured domain. COPILOT_GITHUB_DOMAIN still takes precedence.

Memory search embeddings

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

Config

Set memory.search.provider explicitly to use GitHub Copilot embeddings. If a GitHub token is available, OpenClaw discovers available embedding models from the Copilot API and picks 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. Validates Copilot access and resolves the account-specific API endpoint.
3. Queries the Copilot /models endpoint to discover available embedding models, with a 10-second deadline that includes reading the response body.
4. Picks 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 discovery fails or no embedding models are available, OpenClaw uses memory.search.fallback only when you explicitly configure another provider. Otherwise, setup reports the error instead of silently selecting a different provider.

Related

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

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