Copilot reference
Depth behind the GitHub Copilot guide.
Remote windows
When VS Code attaches to a remote machine, Copilot Chat and its extension host run on the remote side. The Anyray provider, your key, and the model picker all live there, so configure the window that actually renders Chat.
Open the machine with the Remote-SSH or Dev Containers extension, then run Connect from that window's integrated terminal:
npx anyray-connect@latest --enroll https://app.anyray.ai/enroll/enl_… --tools copilot
A local terminal only configures your laptop's VS Code, which is the usual reason "Anyray models
are not visible over Remote-SSH". A plain ssh session is not enough either: Connect hands your key
to the running window through the VS Code server's own code launcher, which only that window's
terminal puts on your PATH.
| Requirement | Detail |
|---|---|
| Anyray extension 0.1.17+ | Earlier versions ran in the wrong host and lost the models. |
| A current Connect | Earlier releases refused to configure from a remote shell. |
| VS Code 1.121+ on the server | Check with code --version in that window's terminal. |
| Gateway reachable from the remote host | HTTPS, or http on loopback. A gateway on your laptop needs an SSH tunnel (ssh -R), or point Connect at the deployed one. |
The retrieval MCP tools register on the remote side too. Enable them under Select Tools. If Connect reports that VS Code never confirmed, the configuration is staged rather than lost: reload the window with Developer: Reload Window and the extension applies it. Nothing to re-run.
It loads the extensions installed on your laptop, and a window attached to a remote runs its agent host on that remote, which carries no model bridge. A remote-only setup never shows Anyray models there, and Connect writes no Agents-window settings from a remote window. Run Connect on your laptop too if you want them.
Seat-lane sign-in sources
The default sweep configures the CLI seat lane whenever it can read a Copilot sign-in, from any of
COPILOT_GITHUB_TOKEN, the shared ~/.config/github-copilot directory, an OpenCode
github-copilot login, the sign-in anyray-connect copilot-login mints, or the CLI's own
~/.copilot/config.json.
On macOS the CLI's /login stores in the Keychain, which Connect reads only on an explicit
--tools copilot-cli run, because the read raises a permission dialog. On Linux and Windows
/login offers to store credentials locally, so say yes and no flag is needed.
If Connect detects a seat but cannot read any sign-in token, it leaves the CLI on native GitHub
inference and prints how to enable the seat lane. It never falls back to org billing on its own, and
doctor reports the CLI as not applicable rather than as a routing failure. If Connect did find
a token and GitHub turned it down, the message names the source: that token is expired or its
account holds no Copilot seat, so sign in again and re-run.
Which sign-in decides which models
GitHub grants a Copilot token the models the OAuth app that minted it is entitled to, not the models your plan lists.
| Sign-in | Models served |
|---|---|
| Editor-plugin sign-in | 48 models, answered claude-sonnet-5 |
The CLI's own /login token | 7 legacy ids, 400 on every current model |
Measured on one seat. The fix is one anyray-connect copilot-login, which is a browser device-code
step, then re-run anyray-connect --tools copilot-cli.
Choosing the CLI model
COPILOT_MODEL sets only the CLI's startup default, and --model still switches per launch. On
a BYOK provider, recent CLI versions list only the configured model in /models, so
anyray-connect models is the picker. Bare, it lists the models your seat can run on the lane.
anyray-connect models <id> switches the startup model after validating it with a live one-token
chat.
The default differs per lane:
| Lane | Default | How it is picked |
|---|---|---|
| Org | anyray-default | The gateway's routing sentinel, so the CLI follows your org's routing with no client edit. |
| Seat | The newest Sonnet-class id that answers | The lane forwards verbatim to GitHub, where the sentinel does not resolve. Connect asks the Copilot API which models your plan serves, test-calls the pick through the exact lane it is configuring, and walks down until one answers. Offline, it falls back to claude-sonnet-5. |
Apply lists the other ids for copilot --model <id> and writes the picked model's token caps
(COPILOT_PROVIDER_MAX_PROMPT_TOKENS and COPILOT_PROVIDER_MAX_OUTPUT_TOKENS) so the CLI does not
warn about unknown ids. Pin either lane's default with ANYRAY_COPILOT_MODEL, shared with the VS
Code lane, where the CLI takes the first id:
ANYRAY_COPILOT_MODEL=gpt-5-codex npx anyray-connect@latest --tools copilot-cli
Windows
Managed profile blocks are POSIX shell, so on Windows Connect prints the equivalent commands instead
of writing anything: setx on the org lane, and PowerShell
[Environment]::SetEnvironmentVariable on the seat lane, whose headers value is multi-line and
which setx cannot carry. Run them, then restart your terminal.
Secrets print masked. Substitute the seat token from the source Connect names, and the gateway key
from npx anyray-connect@latest print-key.
Reverting, and shells already open
npx anyray-connect@latest --tools copilot-cli --revert
This removes the managed block and deletes ~/.anyray/copilot-cli.sh. A shell that already sourced
the block keeps the exported variables, so the CLI stays on BYOK there until you unset them or
open a new terminal. Connect names the exact variables. Inline completions and GitHub-hosted
features were never routed and are unaffected.