Skip to content

Store native-gateway onboarding cannot complete GitHub Copilot setup despite a working saved sign-in #1870

Open
Open
Store native-gateway onboarding cannot complete GitHub Copilot setup despite a working saved sign-in#1870
Labels
P0Emergency: data loss, security bypass, crash loop, or unusable core runtime.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:auth-providerThis issue is about auth, provider routing, model choice, or SecretRef resolution.impact:ux-release-blockerA non-technical user is blocked without terminal, logs, config, or support.issue-rating: 🦪 silver shellfishThin issue quality; more reproduction proof or environment detail is needed.

Description

@adrastogi
adrastogi
opened on Oct 24, 2026

Summary

The Microsoft Store Windows companion could not complete Connect your AI using GitHub Copilot. Browser device authorization completed, but onboarding continued to fail after multiple attempts.

At least two saved sign-ins subsequently passed inference verification through the OpenClaw CLI without another device login. Explicitly selecting a working profile allowed real Copilot chat requests to succeed, including after a gateway restart. The companion's onboarding flow still failed when trying to use the configured model.

This appears to be an onboarding/credential-activation problem rather than simply a missing Copilot subscription. The exact root cause and whether the fix belongs in Companion or the upstream Gateway are not established.

Environment at time of failure

  • Windows build: 10.0.28651.1004
  • Microsoft Store companion: OpenClawFoundation.OpenClaw, version 2026.10.502.0
  • Microsoft Store gateway: OpenClawFoundation.OpenClawGateway, version 2026.10.600.0
  • Bundled OpenClaw: 2026.10.6, commit fe06181dc5ecc01cf8904abbfc26925925efefbc
  • Gateway type: native Windows isolated session, not WSL
  • Provider: GitHub Copilot on github.com
  • Model used for successful recovery: github-copilot/claude-sonnet-5
  • Observed on October 23, 2026

Observed flow

This describes the affected instance; it has not been reduced to a clean-install reproduction.

  1. Install the Windows companion and native Gateway from Microsoft Store.
  2. Use the companion's setup UI to configure the local native Gateway.
  3. Choose GitHub Copilot and complete browser device authorization.
  4. Attempt to finish model setup. Retry device authorization when setup does not complete.
  5. Setup remains blocked despite saved Copilot sign-ins.
  6. After CLI recovery establishes a working Copilot model, return to Connect your AI and select Current model / Use this model.
  7. The wizard fails with a saved-secret runtime-loading error rather than completing onboarding.

Expected behavior

A successfully authorized, usable Copilot sign-in should be verified, activated for the selected agent/model, and carried through to a saved companion connection.

If verification fails, setup should identify whether the failure is GitHub authorization, local credential loading, provider/plugin readiness, or gateway pairing. Retrying should allow a working saved sign-in to be used without unnecessarily repeating device authorization.

Actual behavior and diagnostic evidence

  • Several Copilot profiles existed after the repeated attempts. Two usable profiles were initially reported as inactive with reasonCode: setup_inactive.

  • Automatic model discovery selected another saved profile and reported auth-rejected. An explicit activation attempt for that profile returned Copilot authentication failed: HTTP 401.

  • Other setup attempts reported:

    Update or enable the selected provider plugin in Plugins, then retry this saved sign-in.
Your current connection is unchanged.

    However, openclaw plugins list --json showed the bundled github-copilot provider enabled and loaded.

  • The companion's Current model verification reported:

    The provider could not activate this model. Refresh to choose again.
Secret [REDACTED] ... is configured but unavailable
(secret [REDACTED] was not materialized by the active runtime).

  • Before recovery, the model still resolved to the unauthenticated default openai/gpt-6-astra; no authored agents.defaults.model was set.

  • The companion had not persisted a completed gateway connection. Separate connection timeouts also occurred during recovery; restarting the companion restored discovery, but did not resolve the model-activation error.

Recovery that worked

  1. Set the default model to github-copilot/claude-sonnet-5 and start the packaged Gateway.
  2. Use openclaw models auth activate <saved-profile-id> to verify existing saved sign-ins. Two previously inactive profiles passed inference verification without another browser login.
  3. Set the main agent's Copilot auth order to the verified profiles. Model discovery then reported ready.
  4. Confirm a real agent response through the Gateway, then restart the Gateway and confirm another successful response.
  5. Bypass the first-run AI wizard: use Connection -> Setup code to pair the Windows companion with the existing local Gateway, and approve that exact companion device request.
  6. The companion then showed Connected, persisted its device token, and displayed the successful Copilot response in native Chat.

PC Node mode and the local MCP server remained disabled.

Possibly related upstream report

openclaw/openclaw#181686 reports account-owned SecretRef loading failures in offline models status --probe on the same OpenClaw release, 2026.10.6 (fe06181), while Gateway-based checks work.

That report includes the same "not materialized by the active runtime" error. It may be relevant to the verification path used by onboarding, but it concerns an offline CLI probe, not the Windows wizard. This report does not establish that they are the same defect.

Investigation scope

Please investigate the handoff between saved provider sign-ins, activation/eligibility, runtime secret loading, and the onboarding verification step. The CLI and wizard produced different outcomes for a configuration capable of successful Copilot inference.

The evidence does not establish why the rejected profile returned HTTP 401, whether stale in-memory state was the underlying cause, or whether all observed errors share one defect. The connection-timeout symptom may be separate.

Sanitized error excerpts are included above. No access tokens, setup codes, private device keys, account identifiers, or full credential databases are included.

Activity

  1. github-project-automation
    added this to Windows Companion Appon Oct 24, 2026
  2. github-project-automation
    moved this to Backlog in Windows Companion Appon Oct 24, 2026
  3. clawsweeper
    added
    clawsweeper:intake:bugPreliminary submission classification; full source review pending.
    P0Emergency: data loss, security bypass, crash loop, or unusable core runtime.
    clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.
    clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.
    impact:auth-providerThis issue is about auth, provider routing, model choice, or SecretRef resolution.
    impact:ux-release-blockerA non-technical user is blocked without terminal, logs, config, or support.
    issue-rating: 🦪 silver shellfishThin issue quality; more reproduction proof or environment detail is needed.
    and removed
    clawsweeper:intake:bugPreliminary submission classification; full source review pending.
    on Oct 24, 2026

  4. clawsweeper commented on Oct 24, 2026

    @clawsweeper
    clawsweeperBot
    on Oct 24, 2026 – with ClawSweeper

    Codex review: this still needs some work.

    Summary
    Keep open: this issue documents blocked Store onboarding despite successful Copilot inference, and neither current source nor related fixes establishes that the failure is resolved.

    Reproducibility: The report provides exact shipped versions, a concrete failed flow, and a successful inference control, but this review did not reproduce it and current source establishes only the RPC boundary.

    Next step
    Correlate the failing wizard RPC with the working profile and agent, then repair that boundary with inline saved-sign-in recovery.

    Review details

    Best possible solution:

    Let the existing wizard verify and use a working saved sign-in, with inline recovery that completes pairing without terminal edits.

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

    The report provides exact shipped versions, a concrete failed flow, and a successful inference control, but this review did not reproduce it and current source establishes only the RPC boundary.

    Is this the best way to solve the issue?

    Trace and repair the existing setup handoff after establishing a failing regression; bypassing verification, implementing separate Companion credential storage, or assuming the offline probe fix applies would be premature.

    AGENTS.md: found and applied where relevant.

    Remaining risk / open question:

    • The failing setup RPC, selected agent/profile, and runtime secret state have not been correlated, so Companion versus Gateway repair ownership remains unresolved.
    • Current-main Store-native reproduction is unverified, and the rejected profile’s HTTP 401 and connection timeouts may be separate failures.

    Codex review notes: model internal, reasoning medium; reviewed against de162ba66028.

    Label changes

    Label changes:

    • add P0: The first-run Store onboarding path remained blocked after successful browser authorization and required CLI credential/model changes before pairing could complete.
    • add impact:auth-provider: Saved Copilot profile eligibility, model activation, and runtime secret loading disagree with successful inference using explicitly selected profiles.
    • add impact:ux-release-blocker: The reported successful recovery required terminal operations and setup-code pairing rather than a working in-product recovery flow.
    • add issue-rating: 🦪 silver shellfish: 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:

    • P0: The first-run Store onboarding path remained blocked after successful browser authorization and required CLI credential/model changes before pairing could complete.
    • impact:ux-release-blocker: The reported successful recovery required terminal operations and setup-code pairing rather than a working in-product recovery flow.
    • impact:auth-provider: Saved Copilot profile eligibility, model activation, and runtime secret loading disagree with successful inference using explicitly selected profiles.
    Evidence reviewed

    Acceptance criteria:

    • Establish a failing regression for the confirmed saved-profile activation or verification defect before implementing a repair.
    • ./build.ps1
    • dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
    • dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
    • dotnet test ./tests/OpenClaw.SetupEngine.Tests/OpenClaw.SetupEngine.Tests.csproj

    What I checked:

    • Concrete affected release and successful recovery: The complete REST-fetched report identifies Store Companion 2026.10.502.0, Gateway 2026.10.600.0, and OpenClaw 2026.10.6. It records existing profiles passing CLI activation, successful Copilot responses before and after Gateway restart, continued wizard failure, and eventual setup-code pairing recovery. The sole comment is an automated review-status message.
    • Current activation and verification boundary: Selected choices invoke Gateway-owned setup authentication or activation methods; exact-model verification invokes openclaw.setup.verify through the transport. This establishes an upstream runtime/protocol dependency, but does not establish that the wizard executes the offline models status probe. (src/OpenClaw.SetupEngine/GatewayAiSetupClient.cs:351, de162ba66028)
    • Transport uses the live Gateway connection: RequestCoreAsync sends setup requests through OpenClawGatewayClient.SendWizardRequestAsync and checks route authority around the request. (src/OpenClaw.SetupEngine/GatewayAiSetupTransport.cs:108, de162ba66028)
    • Existing coverage does not establish Copilot recovery: Synthetic transport tests protect activation receipts, exact-route verification, and configured-model retry. Their demo credentials and queued responses do not exercise Copilot profile eligibility or account-secret materialization. (tests/OpenClaw.SetupEngine.Tests/GatewayAiSetupClientTests.cs:529, de162ba66028)
    • Related fixes address different behavior: fix(setup): preserve sanitized Local AI verification errors #1716 (fix(setup): preserve sanitized Local AI verification errors) merged diagnostic retention, rather than credential activation. fix(onboarding): finish setup before showing AI as ready #1626 (fix(onboarding): finish setup before showing AI as ready) remains open and addresses completion/readiness authority; it does not establish a repair for this Copilot failure. (src/OpenClaw.SetupEngine.UI/Pages/AiSetupPage.xaml.cs:1235, 735783459efa)
    • Canonical search and related discussion: Searches across issues and PRs for Copilot, saved sign-in, SecretRef, materialization, activation, and this issue’s number found no exact fixing item. In Connect your AI: OpenRouter OAuth device sign-in does not complete #1579, jondihaynes documents an OpenRouter route-label rejection and an explicit-model workaround, a different established failure from the Copilot secret-loading report.
    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; those execution lanes are retired.
    • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

    Reviewed October 24, 2026, 11:33 AM ET / 15:33 UTC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P0Emergency: data loss, security bypass, crash loop, or unusable core runtime.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:auth-providerThis issue is about auth, provider routing, model choice, or SecretRef resolution.impact:ux-release-blockerA non-technical user is blocked without terminal, logs, config, or support.issue-rating: 🦪 silver shellfishThin issue quality; more reproduction proof or environment detail is needed.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions