---
summary: "Sign in to GitHub Copilot from OpenClaw using the device flow or non-interactive token import"
read_when:
- You want to use GitHub Copilot as a model provider
- You need the `openclaw models auth login-github-copilot` flow
- You are choosing between the built-in Copilot provider, Copilot SDK harness, and Copilot Proxy
title: "GitHub Copilot"
---
GitHub Copilot is GitHub's AI coding assistant. It provides access to Copilot
models for your GitHub account and plan. OpenClaw can use Copilot as a model
provider or agent runtime in three different ways.
## Three ways to use Copilot in OpenClaw
Use the native device-login flow to obtain a GitHub token, then exchange it for
Copilot API tokens when OpenClaw runs. This is the **default** and simplest path
because it does not require VS Code.
```bash
openclaw models auth login-github-copilot
```
You will be prompted to visit a URL and enter a one-time code. Keep the
terminal open until it completes.
```bash
openclaw models set github-copilot/claude-opus-4.7
```
Or in config:
```json5
{
agents: {
defaults: { model: { primary: "github-copilot/claude-opus-4.7" } },
},
}
```
Install the external `@openclaw/copilot` plugin when you want GitHub's
Copilot CLI and SDK to own the low-level agent loop for selected
`github-copilot/*` models.
```bash
openclaw plugins install @openclaw/copilot
```
Then opt a model or provider into the runtime:
```json5
{
agents: {
defaults: {
model: "github-copilot/gpt-5.5",
models: {
"github-copilot/gpt-5.5": {
agentRuntime: { id: "copilot" },
},
},
},
},
}
```
Choose this when you want 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 keep using the
built-in provider. See [Copilot SDK harness](/plugins/copilot) for the full
runtime contract.
Use the **Copilot Proxy** VS Code extension as a local bridge. OpenClaw talks to
the proxy's `/v1` endpoint (default `http://localhost:3000/v1`) and uses the
model list you configure.
The `copilot-proxy` plugin ships with OpenClaw and is enabled by default.
Configure the base URL and model ids with:
```bash
openclaw models auth login --provider copilot-proxy --set-default
```
Choose this when you already run Copilot Proxy in VS Code or need to route
through it. The VS Code extension must stay running.
## Optional flags
| Command | Flag | Description |
| ---------------------------------------------------------------------- | --------------- | ---------------------------------------------------- |
| `openclaw models auth login-github-copilot` | `--yes` | Overwrite an existing auth profile without prompting |
| `openclaw models auth login --provider github-copilot --method device` | `--set-default` | Also apply the provider's recommended default model |
```bash
# 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 setup, import
an existing GitHub OAuth access token with `openclaw onboard --non-interactive`:
```bash
openclaw onboard --non-interactive --accept-risk \
--auth-choice github-copilot \
--github-copilot-token "$COPILOT_GITHUB_TOKEN" \
--skip-channels --skip-health
```
You can also omit `--auth-choice`; passing `--github-copilot-token` infers the
GitHub Copilot provider auth choice. If the flag is omitted, onboarding falls
back to `COPILOT_GITHUB_TOKEN`, `GH_TOKEN`, then `GITHUB_TOKEN`. Use
`--secret-input-mode ref` with `COPILOT_GITHUB_TOKEN` set to store an env-backed
`tokenRef` instead of plaintext in `auth-profiles.json`.
The device-login flow requires an interactive TTY. Run it directly in a
terminal, not in a non-interactive script or CI pipeline.
Copilot model availability depends on your GitHub plan. If a model is
rejected, try another ID (for example `github-copilot/gpt-5.5`). See
GitHub's [supported models per Copilot plan](https://docs.github.com/en/copilot/reference/ai-models/supported-models#supported-ai-models-per-copilot-plan)
for the current model list.
Once the device-login (or env-var) auth path has resolved 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. Newly published Copilot models become visible 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 stays as 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 rely entirely
on the static manifest catalog (offline / air-gapped scenarios):
```json5
{
plugins: {
entries: {
"github-copilot": {
config: { discovery: { enabled: false } },
},
},
},
}
```
Claude model IDs use the Anthropic Messages transport automatically.
Gemini models use the OpenAI Chat Completions transport; GPT and o-series
models keep the OpenAI Responses transport. OpenClaw selects the correct
transport based on the model ref.
OpenClaw sends Copilot IDE-style request headers on Copilot transports
(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 carries image input.
OpenClaw resolves Copilot auth from environment variables in the following
priority order:
| Priority | Variable | Notes |
| -------- | --------------------- | -------------------------------- |
| 1 | `COPILOT_GITHUB_TOKEN` | Highest priority, Copilot-specific |
| 2 | `GH_TOKEN` | GitHub CLI token (fallback) |
| 3 | `GITHUB_TOKEN` | Standard GitHub token (lowest) |
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.
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 manage the token manually.
## Memory search embeddings
GitHub Copilot can also serve as an embedding provider for
[memory search](/concepts/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 `memorySearch.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.
```json5
{
agents: {
defaults: {
memorySearch: {
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. Exchanges it for a short-lived Copilot API token.
3. Queries the Copilot `/models` endpoint to discover available embedding models.
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 no embedding models are
available, OpenClaw skips Copilot and tries the next provider.
## Related
Choosing providers, model refs, and failover behavior.
Auth details and credential reuse rules.