GitHubDeviceFlow has never run against real GitHub: its JSON request bodies and 200-with-error polling are untested live

[matt-edmondson]

Plan item

• Plan: https://github.com/ktsu-dev/GitIntegration/blob/e93880ebdc96f46adf780d97fbc211564ea56d4a/docs/superpowers/plans/2026-09-21-worktrees-and-github-auth.md#L2430-L2434
• Spec: https://github.com/ktsu-dev/GitIntegration/blob/e93880ebdc96f46adf780d97fbc211564ea56d4a/docs/superpowers/specs/2026-09-21-worktrees-and-github-auth-design.md#L339-L347

The OAuth App does not exist yet. Every test here runs against a fake transport, so no task is blocked. But nothing has been confirmed against GitHub itself, and it cannot be until someone with organization ownership registers an OAuth App with device flow enabled and approves it for SAML single sign-on, scopes repo and read:org.

PR #118 only mentioned this as a "Not yet verified end to end" paragraph in its description. No issue tracks it.

What exists today

• GitIntegration/Hosting/GitHubDeviceFlow.cs implements RequestDeviceCodeAsync and WaitForTokenAsync over a raw HttpClient.
• GitIntegration.Test/Hosting/GitHubDeviceFlowTests.cs has about 18 tests, all against FakeHttpMessageHandler.

What's missing, and why it matters

These assumptions have only been checked against the project's reading of the protocol, never against GitHub:

• JSON request bodies. The type's own remarks (GitHubDeviceFlow.cs, around L100) say both endpoints are sent JSON "even though GitHub's own published documentation shows the device flow using form-url-encoded requests". If GitHub stops accepting JSON, every sign-in fails, and no fake-transport test can catch that.
• Errors in a 200 body. The code assumes GitHub reports authorization_pending, slow_down, access_denied and expired_token in the body of a 200 response.
• SAML SSO. Nobody has confirmed that the resulting token can be approved for SAML single sign-on on the target organization.

Acceptance criteria

• An organization owner registers a GitHub OAuth App with device flow enabled (scopes repo and read:org) and approves it for SAML SSO.
• A manual run, or an opt-in run gated on credentials, completes RequestDeviceCodeAsync followed by WaitForTokenAsync against github.com. It records what actually happens for pending, slow_down (if it can be provoked), denial, and success.
• With the token that run obtains, GitHubProvider.GetRepositoriesAsync lists the organization's private repositories.
• The findings are recorded in docs/superpowers/research/, the way 2026-08-21-azure-devops-rest-findings.md records the Azure DevOps ones. If the JSON-body assumption fails, the requests are switched to form encoding.

Dependencies

• External: an organization owner has to register and approve the OAuth App.
• Related: DNS, TLS or connection failures escape GitHubDeviceFlow, GitHubProvider and AzureDevOpsProvider as raw HttpRequestException, bypassing the documented GitHostingException hierarchy #155. Transport failures currently escape GitHubDeviceFlow as a raw HttpRequestException, which a live run may hit.

[matt-edmondson]

Triage

• Category: Improvement (a live verification and test gap)
• Priority: Medium. There is no known defect. However, sign-in over the device flow depends on two unverified assumptions: that GitHub accepts JSON request bodies, and that it reports errors inside a 200 response. If either is wrong, every sign-in fails, and fake-transport tests cannot catch that. It is blocked on an external step, so it isn't urgent until the OAuth App exists.
• Area / suggested assignment: Hosting, in GitHubDeviceFlow and GitHubProvider. The OAuth App registration and SAML approval need a ktsu-dev organization owner. The live run and write-up can then go to whoever owns the hosting code.
• Duplicates / in progress: No duplicate found, and no open PR covers it. It is related to DNS, TLS or connection failures escape GitHubDeviceFlow, GitHubProvider and AzureDevOpsProvider as raw HttpRequestException, bypassing the documented GitHostingException hierarchy #155 (raw HttpRequestException escaping GitHubDeviceFlow), which a live run may hit, so landing DNS, TLS or connection failures escape GitHubDeviceFlow, GitHubProvider and AzureDevOpsProvider as raw HttpRequestException, bypassing the documented GitHostingException hierarchy #155 first would make the live run's failures readable.
• Next step: An org owner registers the OAuth App (device flow enabled, repo and read:org, SAML-approved). Then do one manual run and record the findings under docs/superpowers/research/.

---

Generated by Claude Code