GitHub Copilot auth timed out

[FireBelow]

This is related to issue #654 but I think I found a new bug.

I ran openclaw configure --section model again and this time was creating a github issue to document the issues I was having. However, while I was writing a summary, the device code auth expired and when it did, I was able to get past the device auth and got to a new menu that allowed me to select which models I wanted to use and then complete the configuration update.

The model selection isn't as important as the auth flow was allowed to continue with the device auth I completed days ago but still wasn't working.

I think this timeout bug actually helped me get unblocked and I'm hoping the bot can find the source. After I restarted my gateway, chat worked for the first time since I installed openclaw.

`openclaw@COMPUTER:~$ openclaw configure --section model
│
◇

🦞 OpenClaw 2026.6.1 (...) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

┌ OpenClaw configure
│
◇ Existing config detected ──────────────╮
│ │
│ Workspace: ~/.openclaw/workspace │
│ Model: github-copilot/claude-opus-4.7 │
│ Gateway: local via loopback on :18789 │
│ Node manager: npm │
│ │
├─────────────────────────────────────────╯
│
◇ Model/auth provider
│ More…
│
◇ Model/auth provider
│ Copilot
│
◇ Copilot auth method
│ GitHub Copilot
│
◇ GitHub Copilot auth already exists. Re-run login?
│ Yes
│
◇ GitHub Copilot ─────────────────────────────────────────────╮
│ │
│ This will open a GitHub device login to authorize Copilot. │
│ Requires an active GitHub Copilot subscription. │
│ │
├──────────────────────────────────────────────────────────────╯
│
◇ Authorize GitHub Copilot ────────────────────────────────────────────────────────────╮
│ │
│ Open this URL in your browser and enter the code below. │
│ URL: https://github.com/login/device │
│ Code: │
│ Code expires in 15 minutes. Never share it. │
│ │
│ If a browser does not open automatically after you continue, copy the URL manually. │
│ │
├───────────────────────────────────────────────────────────────────────────────────────╯
│
◇ GitHub Copilot ─────────────────────────────────────────────────╮
│ │
│ The GitHub device code expired. Retry login to get a new code. │
│ │
├──────────────────────────────────────────────────────────────────╯
│
│
◇ Models in /model picker (multi-select)
│ 24 items selected
Updated config: ~/.openclaw/openclaw.json
Backup: ~/.openclaw/openclaw.json.bak
│
└ Configuration updated.

openclaw@COMPUTER:~$`

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 8, 2026, 2:48 PM ET / 18:48 UTC.

Summary
Keep open: current main still installs gateway/CLI version 2026.6.1, which matches the reporter’s failing transcript, and the expired-device-code fallthrough is a distinct enough auth-provider behavior that it should not be swept into the older Copilot auth issue without maintainer triage.

Reproducibility: no. The report includes a detailed command transcript on version 2026.6.1, but this review did not reproduce the WSL/gateway auth flow and the direct CLI implementation is not in this checkout.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
Maintainer triage should first decide whether to track this as a separate expired-device-code fail-open bug or fold it into the open Copilot auth-provider cluster after preserving the transcript.

Review details

Best possible solution:

Fix the gateway CLI so an expired Copilot device-code re-login fails closed or forces a fresh retry before model selection, then update this repository’s pinned gateway version and add Windows setup coverage where the wrapper can observe the regression.

Do we have a high-confidence way to reproduce the issue?

No. The report includes a detailed command transcript on version 2026.6.1, but this review did not reproduce the WSL/gateway auth flow and the direct CLI implementation is not in this checkout.

Is this the best way to solve the issue?

Unclear. There is no proposed patch, and the narrow maintainable fix likely belongs in the gateway CLI first, with this repository consuming the fixed version and covering the setup wrapper boundary.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The exact openclaw configure --section model implementation is not present in this C# checkout, so a narrow fix may need to land in the gateway/CLI package before this repository can consume it through an LKG bump.
• This overlaps the open Copilot auth-provider reports at Copilot Github auth doesn't complete #654 and GitHub Copilot auth permissions #723, but the expired-code fallthrough may be a separate fail-open path.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 37b0ea672037.

Label changes

Label changes:

• add P2: This is a normal-priority provider auth bug with a concrete transcript but no evidence of data loss, crash loop, or broad runtime outage.
• add impact:auth-provider: The reported behavior is in GitHub Copilot authentication and model-provider configuration.
• add issue-rating: 🦐 gold shrimp: Current issue advisory state selects this label.
• add clawsweeper:needs-info: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal-priority provider auth bug with a concrete transcript but no evidence of data loss, crash loop, or broad runtime outage.
• impact:auth-provider: The reported behavior is in GitHub Copilot authentication and model-provider configuration.

Evidence reviewed

What I checked:

• Reporter transcript: The issue body shows openclaw configure --section model on OpenClaw 2026.6.1 reporting an expired GitHub device code and then continuing into the /model picker before updating config.
• Related auth-provider cluster: The related open Copilot auth issue includes later reporter comments that direct openclaw models auth login-github-copilot still failed after browser auth while the Companion wizard flow had completed once.
• Current main installs the reported gateway version: Current main pins GatewayLkgVersion.LkgVersion to 2026.6.1, so the reported version is still the default bundled gateway/CLI version rather than an obviously obsolete release. (src/OpenClaw.SetupEngine/GatewayLkgVersion.cs:6, 37b0ea672037)
• Windows setup delegates provider/model setup to the gateway: The setup engine downloads the OpenClaw CLI via the configured install URL and requested gateway version, so the direct openclaw configure behavior likely lives in the bundled gateway/CLI package rather than native tray code. (src/OpenClaw.SetupEngine/SetupSteps.cs:1101, 37b0ea672037)
• Wizard wrapper timeout path: The headless setup wizard sends wizard.next and uses a long timeout for device/authorize/login/oauth steps, which is the Windows-side wrapper surface if the same provider-auth step is reached through Companion setup. (src/OpenClaw.SetupEngine/SetupWizardRunner.cs:161, 37b0ea672037)
• Recent adjacent OAuth setup work: Commit 8f134b3 added device-pair enablement for OAuth provider scope-upgrade flows and notes that provider CLI auth can hang before printing a verification URL when setup pairing is wrong. (src/OpenClaw.SetupEngine/SetupSteps.cs:1321, 8f134b354df0)

Likely related people:

• Barbara Kudiess: Blame and commit history tie recent OAuth provider scope-upgrade and device-pair setup behavior to commit 8f134b3, which is adjacent to Copilot device-code auth setup. (role: recent setup/OAuth area contributor; confidence: medium; commits: 8f134b354df0; files: src/OpenClaw.SetupEngine/SetupSteps.cs, src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs, tests/OpenClaw.SetupEngine.Tests/SetupStepsTests.cs)
• Ranjesh: Commit 9d304c1 added wizard recovery actions during auth waits, directly adjacent to provider auth stalls and timeout handling in the setup UI. (role: recent adjacent recovery contributor; confidence: medium; commits: 9d304c110c0f; files: src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs, docs/ONBOARDING_WIZARD.md)
• Christine Yan: Current checkout blame attributes the baseline SetupWizardRunner and GatewayLkgVersion implementation to commit 85445c7, the latest release tag baseline for this area. (role: current setup wizard and LKG provenance; confidence: low; commits: 85445c78066b; files: src/OpenClaw.SetupEngine/SetupWizardRunner.cs, src/OpenClaw.SetupEngine/GatewayLkgVersion.cs)
• Scott Hanselman: Recent history shows commit d23f8ca touching SetupWizardRunner during setup hardening, making this a useful routing signal for current wrapper behavior. (role: recent SetupWizardRunner contributor; confidence: low; commits: d23f8ca50013; files: src/OpenClaw.SetupEngine/SetupWizardRunner.cs)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for sharing this — the expired-device-code behavior you observed is a helpful diagnostic. Here's what most likely happened:

When you first ran openclaw configure --section model, you completed the browser authorization, but the CLI's polling loop didn't detect the completion and timed out. The gateway may have stored the completed Copilot credential on the first authorization, but the active CLI session was stuck waiting for a callback that never arrived.

When the device code expired 15 minutes later, the gateway's expired-code handling likely fell through to a "check what's already authenticated" path, found the cached credential from your earlier browser auth, and allowed the flow to continue to model selection.

This is a fail-open behavior in the gateway's GitHub Copilot auth flow — the expiry case effectively unblocks a stuck session. While it happened to work as a workaround here, the correct behavior would be for the polling loop to detect browser auth completion without requiring a timeout.

If you need to re-authenticate in the future, the workaround is: start the auth flow, complete browser auth, then wait for the device code to expire (~15 minutes) before the CLI will continue. Restarting the gateway afterward (as you found) appears to activate the new credentials.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a