# Desktop app: BYOK custom model provider is not forwarded to remote (WSL) se...

Start by tracing remote session creation and the existing LlmInferenceSetProvider and ProviderTokenAcquire RPCs described in the report. Compare provider handling for local and WSL sessions; done means the configured BYOK provider and models are available remotely without falling back to GitHub models.

Desktop app: BYOK custom model provider is not forwarded to remote (WSL) sessions — BYOK models unavailable, requests fall back to GitHub models

Environment

• GitHub Copilot desktop app 1.1.22 on Windows 11
• WSL2 (Ubuntu), .wslconfig with networkingMode=mirrored
• BYOK provider configured in app settings: OpenAI-compatible endpoint (https://ollama.com/v1), wire API responses, with models such as kimi-k3 and GLM-5.3
• Windows-side CLI 1.0.84-5; remote CLI in WSL at ~/.cache/github-copilot-sdk/cli/1.0.79 (binary reports 1.0.86); copilotd 0.7.3
• Projects whose path lives inside the WSL filesystem run as remote sessions (via copilotd on the WSL side)

What happens

• Sessions on Windows-path projects: BYOK models are selectable and work correctly.
• Sessions on WSL-path projects (remote sessions): BYOK models are not available. The remote CLI log shows:

Model 'GLM-5.3' from CLI argument/session ... not available. Falling back to next option.

and requests are served by GitHub's model routing instead of the configured provider.

Repro

1. In the app, add a custom model provider (BYOK) and add models to it.
2. Add a project whose repository is inside the WSL filesystem.
3. Create a session on that project and observe the fallback (or inability to select the BYOK model).

Evidence that the gap is provider-registry forwarding

• The remote copilotd/CLI processes do receive the full COPILOT_PROVIDER_* environment variable set (verified via /proc/<pid>/environ), but the server-mode CLI ignores env-var BYOK — in server mode the provider is controlled by the host over RPC, so the env vars are inert there.
• Running the same CLI directly in a WSL terminal with the same env vars works perfectly (verified even with COPILOT_HOME isolated and no GitHub auth) — so the endpoint, credentials, and network path are all fine.
• copilotd 0.7.3 already ships the remote BYOK plumbing: LlmInferenceSetProvider, ProviderTokenAcquire (providerName, accessToken, expiresIn, tokenType), LlmInferenceHttpRequestStart/Chunk — so an RPC path for forwarding providers exists.
• The app binary contains the flow strings ("provider registry attached to new session", "re-applying provider registry on session resume"), but no provider-registry activity appears in app logs when a remote session is created.

Conclusion: when creating a remote session, the app passes the model name (e.g. GLM-5.3) but does not attach/forward the provider registry, so the remote CLI has no provider for those model IDs and falls back to GitHub models.

Expected behavior

The BYOK provider and its models should be forwarded to remote sessions via the existing SetProvider/ProviderTokenAcquire RPCs, so remote (WSL) sessions can use BYOK models just like local sessions.

Additional observations (possibly related)

• Every remote session creation logs skills.discover: Invalid working directory (customization discovery failure).
• After an app restart, remote sessions fail to resume: resume_session reports "session not found".