You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ACP: authenticate (github_oauth) fails on headless and remote hosts; add a device flow fallback #54
In ACP mode (--acp), authenticate with github_oauth supports only the OAuth code flow. On a host without a display, or with SSH variables set, it fails at once with error 1004. An ACP client then has no way to sign the user in.
This blocks remote development. There, the agent runs on a headless backend, and the browser of the user runs on another machine.
Environment
@github/copilot-language-server 1.551.2, started with --acp (the github-copilot agent from the ACP registry)
Client: a JetBrains IDE in Remote Development. The backend runs in a Linux container without DISPLAY.
Steps to reproduce
Start copilot-language-server --acp on Linux without DISPLAY and WAYLAND_DISPLAY, or with SSH_CONNECTION set. Use a machine with no stored GitHub credentials.
Send initialize, then session/new. The agent answers -32000 Authentication required.
Send authenticate with methodId: "github_oauth", the only advertised method.
Actual result
{ code: 1004, message: 'OAuth code flow requires a browser but none is available: Browser not available (SSH session or headless environment). Cannot perform OAuth code flow.' }
The code flow cannot work remotely even when this check passes. The agent opens the browser with xdg-open on its own host and does not send the URL to the client. The redirect goes to http://127.0.0.1:<port>/callback on the agent host, and the browser of the user cannot reach it.
Expected result
When no browser is available, authenticate falls back to the GitHub device flow. The package already implements the device flow for LSP mode (signInInitiate). The client must get the verification URI and the user code. Possible ways:
Send them in an ACP URL elicitation (elicitation/create with mode: "url") when the client advertises the elicitation.url capability. Keep the authenticate request pending until the device flow completes.
Or advertise a second auth method for the device code flow.
JetBrains clients also send clientCapabilities._meta["user-colocated"]: false when the browser of the user is not on the agent host. The agent can use this value to choose the device flow when a local display is present.
Activity
formulahendry commentedon Oct 13, 2026
Thanks for the feedback!
Device Code login in ACP is already in our backlog. We have plan to support this.