1.0.88 regression: joinSession() stalls during extension startup, causing repeated 30s timeouts and delaying -i

Start by comparing the bundled app.js behavior around handleSessionResumeCore, especially ensureManagedSettingsApplied and extensionConnections, between 1.0.87-0 and 1.0.88. Reproduce with the provided extension.mjs, then inspect join-ext.log, events.jsonl, and the CLI log. Done means joinSession() completes during initial startup without repeated 30-second timeouts and the interactive prompt runs after initialization.

Describe the bug

Starting with 1.0.88, an SDK extension that calls joinSession() during CLI startup gets no reply to its session.resume request. Extension startup waits up to 30 s for the extension to become ready, but the extension can't become ready until joinSession() returns. The CLI kills the extension at the timeout, starts a new copy, and the new copy gets stuck the same way. Usually the first two launches time out and a copy launched after startup finishes joins in about 100 ms.

Effects:

• copilot -i "<prompt>" holds the prompt until extension loading finishes. With one trivial extension it's sent about 50 s later than on 1.0.87-0, and later still with several plugin extensions (we measured about 110 s).
• Sometimes every launch of an extension times out and the CLI finishes startup without it. A host that waits for its observer extension to attach before sending the first prompt then remains blocked until its own readiness timeout. In one observed run, readiness never arrived within 290 s and the composer stayed empty.

The probes were run on September 23, 2026. The 30 s startup timeout loop did not occur on 1.0.87-0 and also occurred on 1.0.89-0. Changing SDK versions did not resolve it: we saw the behavior with the CLI-bundled SDK, @github/[email protected], and 1.0.15-preview.1 via --extension-sdk-path. Versions newer than these have not been tested for this report.

Affected version

GitHub Copilot CLI 1.0.88 (also 1.0.89-0; not reproducible on 1.0.87-0)

Steps to reproduce the behavior

1. Choose a fresh session UUID and create its extension directory. In PowerShell:

   $sessionId = [guid]::NewGuid().ToString()
   $copilotHome = if ($env:COPILOT_HOME) { $env:COPILOT_HOME } else { Join-Path $HOME ".copilot" }
   $extensionDir = Join-Path $copilotHome "session-state\$sessionId\extensions\probe-join"
   New-Item -ItemType Directory -Path $extensionDir -Force | Out-Null
   

   Save this as extension.mjs in $extensionDir:

   import { appendFileSync } from "node:fs";
   const logFile = new URL("join-ext.log", import.meta.url);
   const log = (m) => appendFileSync(logFile, `${new Date().toISOString()} pid=${process.pid} ${m}\n`);
   log("started");
   const { joinSession } = await import("@github/copilot-sdk/extension");
   log("imported");
   const s = await joinSession({});
   log("joined " + s.sessionId);
   setInterval(() => {}, 1000);
   

2. Start the CLI for that session with an initial prompt:

   copilot "--session-id=$sessionId" --allow-all --experimental -i "Reply with exactly the word PONG and nothing else. Do not use tools."
   

3. Watch join-ext.log in the extension directory and the time the user.message event reaches the session's events.jsonl. The isolated-home tests had no other installed plugins, but retained the same authenticated account and its managed-settings environment.

Representative result on CLI 1.0.88 with SDK 1.0.15-preview.1:

10:32:56.599 pid=38564 started
10:32:56.672 pid=38564 imported        <- joinSession() never returns; killed ~30 s later
10:33:26.625 pid=31084 started
10:33:26.694 pid=31084 imported        <- same again
10:33:59.257 pid=64376 started
10:33:59.326 pid=64376 imported
10:33:59.430 pid=64376 joined          <- joins in ~100 ms once startup has finished

The version comparison used the same machine and isolated Copilot home. Prompt timings are measured from CLI launch; extension timings are measured from the first extension process launch:

CLI	Extension joined	-i prompt sent (user.message)
1.0.87-0	~6 s after the first extension launch, no timeouts	~24 s
1.0.88	third launch, ~63 s after the first extension launch	~74 s
1.0.89-0	third launch, ~71 s after the first extension launch	~82 s

On 1.0.87-0 the first extension process was restarted, but subsequent copies joined without hitting the 30 s startup timeout. In a separate control, an extension that never calls joinSession() was also killed and relaunched at 30 s; simply keeping the extension process alive did not make it ready.

The CLI log for each stuck launch shows the resume request arriving and progressing past authentication, and then no reply:

Received session.resume request ...
[rust:copilot_runtime::protocol::jsonrpc::engine] Prepared SDK resume plugin inventory {"resident":true,"preserve_inventory":true}
Set auth info on session <id>
... (30 s)
Installed 0 native extension(s) for session <id>
[WARNING] [rust:rt_protocol::jsonrpc::transport] request drain timed out during connection teardown

Expected behavior

An extension's joinSession() should complete without a circular dependency on extension startup finishing. Startup should not require repeated 30 s extension timeouts before a join succeeds, and -i should execute once initialization genuinely completes.

Additional context

Suspected cause, from reading the bundled app.js. We haven't confirmed it with instrumentation, because this wait isn't logged. The step that runs right after Set auth info on session in handleSessionResumeCore changed between versions:

• 1.0.87-0: t.enableManagedSettings && await session.ensureManagedSettingsApplied()
• 1.0.88: if (t.enableManagedSettings || this.extensionConnections.has(n)) await session.ensureManagedSettingsApplied()

Every extension connection now waits until the session's managed settings have been applied. Our account has managed settings (mcp apply_session_settings ... "has_managed_settings":true). The final mcp apply_session_settings {"sandbox_changed":true,...} entry only appears after the extension startup timeouts have run, and extensions launched after that join immediately. That suggests managed-settings application is itself waiting on initial extension startup, which waits for the extension's session.resume, which waits for managed settings.

Environment:

• Windows 11 x64 (build 26200), PowerShell 7, ConPTY
• Node.js v24.14.0
• Also seen with real plugin extensions installed (several plugin extensions each time out 2–3 times before startup completes).

Related reports

• github/copilot-cli#2348 describes a circular wait involving joinSession() during extension reload, and was closed as resolved in 1.0.86. This report concerns initial startup on 1.0.88, with repeated 30 s timeouts.
• github/copilot-cli#4766 and github/copilot-cli#4723 describe missing -i prompts on older versions. This report adds a minimal extension reproduction and extension-launch timing; a shared root cause has not been established.
• github/copilot-cli#4957 reports a separate managed-policy startup-ordering regression in 1.0.88. It may be relevant to the suspected managed-settings wait above, but does not establish the cause of this extension stall.
• github/copilot-cli#4717 concerns large-history serialization during extension attachment. This reproduction uses a fresh session, not a large history.