mcp-publisher: device-flow login fails with `incorrect_device_code` at the authorize step (1.7.9 and 1.8.1); pending-poll and payload verified healthy

[john-broadway]

Summary

mcp-publisher login github fails with incorrect_device_code at the authorization step. Observed three times across two days and two publisher versions (1.7.9 twice on 2026-08-17, 1.8.1 once on 2026-08-18), same host. Polling while the code is still pending is healthy; the error appears only in runs where the user proceeds to authorize in the browser, well inside the 15-minute expiry window.

Logging in with github...

To authenticate, please:
1. Go to: https://github.com/login/device
2. Enter code: XXXX-XXXX
3. Authorize this application
Waiting for authorization...
Error: login failed: error polling for token: token request failed: incorrect_device_code

Per RFC 8628 and GitHub's device-flow docs, a pending poll should return authorization_pending, and incorrect_device_code means the polled device_code does not match one issued for that client_id. Getting it after a successful code issuance, from the same process that requested the code, is the puzzle.

Environment

• publisher 1.7.9 (commit 35b2071, built 2026-05-12) and 1.8.1 (commit f52dc85, built 2026-08-06, checksum-verified from the release), linux amd64
• registry: https://registry.modelcontextprotocol.io (health endpoint serves github_client_id: Iv23liUydBbI7Z2Q9bOZ)
• no proxy env vars, DNS resolves github.com normally

What we ruled out

1. The binary version. 1.7.9 and 1.8.1 fail identically.
2. The pending-poll path. Ran mcp-publisher login github (1.8.1) and let it poll for 40 seconds without authorizing anything: no error, it polls quietly. So the loop, the payload it sends, and the network path are all fine while the code is pending.
3. The wire and the payload shape. Reproduced the publisher's exact requests manually from the same host: POST https://github.com/login/device/code with {"client_id":"Iv23liUydBbI7Z2Q9bOZ","scope":"read:org read:user"} (JSON, same headers) issues a device code, and a single poll of POST https://github.com/login/oauth/access_token with the publisher's exact payload returns authorization_pending as expected.
4. The account/namespace. The MCP_GITHUB_TOKEN provided-token path logs in and publishes fine with the same GitHub account (that is how we shipped in the end).

What we could not capture

Browser-side behavior at the authorize step. The failures correlate with the user completing (or attempting) authorization at github.com/login/device, but we did not record what GitHub displayed there. One of the three failures arrived within seconds of a rerun.

Related

#1289 is the same poll loop failing terminally on slow_down. Two observations about pollForToken in cmd/publisher/auth/github-at.go compound whatever the underlying GitHub-side condition is:

• every non-authorization_pending error is treated as terminal, so a transient or ambiguous response kills the whole login irrecoverably;
• the loop hardcodes interval = 5 and ignores the interval the device-code response actually returns.

Ask

• Is the device flow for the Iv23liUydBbI7Z2Q9bOZ GitHub App known-healthy right now? Has anyone else reported incorrect_device_code after authorizing?
• Independent of the root cause, could the poll loop distinguish terminal from transient errors per RFC 8628 (which would also close mcp-publisher: device-flow login treats GitHub slow_down as fatal instead of backing off #1289)? A login that dies on the last hop after the user has authorized is the most expensive place to fail.