Using Github Copilot is not working as expected

[gustavoaca1997]

I have set up my Companion with Github Copilot.

If I use Claude Opus 4.7, I get this:

⚠️ Agent failed before reply: Unknown model: openai/claude-opus-4.7.
Logs: openclaw logs --follow

If I use Gpt 5.5, I get this:

⚠️ Agent failed before reply: No API key found for provider "openai". Auth store: /home/openclaw/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/openclaw/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy only portable static auth profiles from the main agentDir.
Logs: openclaw logs --follow

[clawsweeper]

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

Summary
Keep open: the report shows a real provider/model-auth failure, and current main does not contain evidence that GitHub Copilot setup now works. The Windows client appears to relay gateway-provided model IDs and session patches, while provider/model setup is documented as gateway-driven, so this needs gateway/provider routing rather than cleanup closure.

Reproducibility: no. high-confidence current-main reproduction path is available from this checkout alone. The reporter provided concrete runtime errors, but reproducing requires a live configured gateway/Copilot setup whose provider/auth implementation is not present in this repo.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
Needs maintainer/provider routing because the failing model and auth decisions appear to come from the gateway/agent provider layer rather than a narrow Windows-node code path.

Review details

Best possible solution:

Reproduce with the pinned local gateway and either fix the gateway Copilot model/auth mapping or document/disable unsupported Copilot choices in the Companion wizard.

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

No high-confidence current-main reproduction path is available from this checkout alone. The reporter provided concrete runtime errors, but reproducing requires a live configured gateway/Copilot setup whose provider/auth implementation is not present in this repo.

Is this the best way to solve the issue?

Unclear: a Windows-node-only change is unlikely to be the best fix unless the client is sending malformed model IDs. The maintainable path likely belongs in gateway provider catalog/auth handling or wizard validation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The exact root cause is still unconfirmed because the error strings appear to originate from the gateway/agent provider layer, not from source present in this Windows node checkout.
• The fix may live in upstream gateway provider catalog/auth handling or in the bundled gateway version, so a Windows-only repair could miss the failing path.

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

Label changes

Label changes:

• add P2: The report is a normal-priority provider/auth failure that blocks a configured agent from replying but has limited blast radius to GitHub Copilot setup.
• add impact:auth-provider: The observed failures are model/provider routing and missing-provider-auth errors after selecting GitHub Copilot.
• 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.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: The report is a normal-priority provider/auth failure that blocks a configured agent from replying but has limited blast radius to GitHub Copilot setup.
• impact:auth-provider: The observed failures are model/provider routing and missing-provider-auth errors after selecting GitHub Copilot.

Evidence reviewed

What I checked:

• Reporter runtime errors: The issue body reports Unknown model: openai/claude-opus-4.7 and No API key found for provider "openai" after setting up Companion with GitHub Copilot.
• Gateway-driven provider setup: The setup guide says the onboarding Wizard's AI provider selection and model setup steps are defined by the gateway via RPC, so provider/auth behavior is not owned solely by the Windows UI. (docs/SETUP.md:60, db30e6089125)
• Models come from gateway: The gateway client requests models.list with view = "configured", making the available model list a gateway response rather than a hard-coded Copilot/OpenAI list in this repo. (src/OpenClaw.Shared/OpenClawGatewayClient.cs:806, db30e6089125)
• Client forwards model IDs: The chat data provider extracts and exposes model IDs from models.list as the wire-format values used by the composer. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:1123, db30e6089125)
• Session model patch path: Model changes are sent as sessions.patch with the selected model string; there is no local provider translation or Copilot auth handling at this call site. (src/OpenClaw.Shared/OpenClawGatewayClient.cs:598, db30e6089125)
• Pinned local gateway version: Local setup pins the gateway to 2026.5.28, which is relevant for reproducing whether the bundled gateway's provider catalog/auth mapping is the failing layer. (src/OpenClaw.SetupEngine/GatewayLkgVersion.cs:6, db30e6089125)

Likely related people:

• Régis Brid: Git blame and log show this person authored the current gateway client/chat provider surfaces that request configured models, forward session model patches, and pin the local gateway version. (role: recent area contributor; confidence: medium; commits: 7d9152f427a3; files: src/OpenClaw.Shared/OpenClawGatewayClient.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, src/OpenClaw.Tray.WinUI/Chat/IChatGatewayBridge.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.

[ranjeshj]

Thanks for the report. Could you clarify how the gateway was set up?

Did you complete the setup flow from the Companion installer UI, or did you configure GitHub Copilot directly in the gateway/CLI environment?

If Copilot was configured directly outside the Companion setup flow, the gateway may not have all of the expected provider/auth configuration. In that case, please try running this in the gateway environment to complete the setup manually:

openclaw onboard

After that, restart/reconnect Companion and try the same model again. That will help confirm whether this is a gateway configuration issue or something else in the Companion flow.