Copilot no-project chat can fail at session.create: standalone extension host is not initialized #38

Problem

Creating a standalone / No project chat from the mobile client failed before the provider could start its turn:

Provider turn failed to start
Request session.create failed with message:
Failed to initialize standalone session extensions:
extensionSdkPath is required when standalone extensions are requested

The original screenshot contains private conversation and environment information and is intentionally not attached. The private chat content is not needed to reproduce this native startup exception.

Confirmed evidence

• Read-only inspection found the same error in the affected environment's CopilotAdapter.ensureThread and provider-start spans at the incident time.
• The affected selected Linux/WSL payload contains Copilot SDK 1.0.28 and native runtime 1.0.105, protocol 3. The same native failure reproduces on macOS arm64 with those versions.
• The standalone extension SDK directory and its index.js / extension.js are present in the affected shipped platform package. This is not established as a payload-pruning or missing-file defect.
• Reproductions used fresh disposable configuration/workspaces and actual SDK/runtime calls. No prompts were sent in native startup tests, and no existing conversation was resumed or modified.

Minimal failing condition and controls

Start a CopilotClient in mode: "copilot-cli" with a stdio runtime and disposable directories, then create a session with:

await client.createSession({
  workingDirectory: scratchDirectory,
  model: "fixture-model",
  provider: {
    type: "openai",
    baseUrl: "http://127.0.0.1:1/v1",
    apiKey: "inert-fixture-not-a-credential",
    wireApi: "completions",
  },
  requestExtensions: true,
  onPermissionRequest: () => ({ kind: "reject" }),
});

Do not send a prompt: session creation itself throws the exact reported error. The inert provider endpoint is never used for inference.

Observed with the affected shipped Linux SDK/runtime:

Omitted/true/false controls were also repeated using a same-host disposable copy of account configuration, with no prompts; outcomes were unchanged. That temporary account copy was deleted afterward, and no credential values were printed or published.

An independent real application No project thread with a harmless placeholder prompt completed successfully in the isolated local candidate backend. This is therefore not yet reproduced as an unconditional no-project/UI failure.

Diagnosis and remaining uncertainty

Confirmed immediate cause: the failing native session attempts to activate standalone extensions without the host initialization they require. Supplying only extensionSdkPath is insufficient in the controlled runtime: the missing extension-launch-provider prerequisite is then reported.

Not yet established: why the affected application session entered that extension-requested path. In source candidate df3383e475c3d052bcac52259384cec319dc6901, the chat adapter's session config omits both requestExtensions and extensionSdkPath; the background text generator explicitly sets requestExtensions: false. Clean controls succeed when the request is omitted. Do not equate the runtime phrase "standalone extensions" with the UI's "No project", or claim that workspace Git initialization fixes this.

The next investigation should capture only sanitized effective create/resume options and relevant capability negotiation on the failing path, not prompts, tokens, MCP authorization headers, or whole configuration files.

Expected behavior / fix boundaries

• A new chat must not implicitly require an extension host the integration has not configured.
• If extensions are unsupported, explicitly opt out consistently on both create and resume paths while retaining supported skills, project discovery and T3 MCP tools.
• If extensions are intentionally supported, wire the complete supported SDK host/launch setup and resolve its payload portably, including packaged and ASAR/unpacked paths. Do not guess a filesystem path or silently retry with different semantics.
• Cover no-project and normal-project creation, resume, enabled/disabled extensions and real packaged Linux/WSL/Windows/macOS behavior. Preserve clear startup errors and avoid duplicate/orphan sessions on retry.

No source fix, deployment, live settings change, or tpatch feature was made for this investigation. The separate local background-routing work remains unchanged.

Model/harness: GPT-6.1 Sol (gpt-6.1-sol), GitHub Copilot CLI.