Desktop app 1.1.15: every session creation blocks ~30s inside `session.create` (was 0.6-0.9s)

Describe the bug

After the desktop app updated to 1.1.15, every CLI session creation blocks for a hard ~30 seconds inside the session.create RPC. Before 1.1.15 the same call completed in 0.6–0.9s.

This affects every session type — project sessions, warmup pre-spawns, scheduled automation runs, and plain chat sessions with no repo attached.

Affected version

Desktop app 1.1.15 (macOS, Apple Silicon). Bundled CLI 1.0.83-5.

Steps to reproduce the behavior

1. Update the desktop app to 1.1.15.
2. Create any new session.
3. Observe the "Starting Copilot session" spinner for ~30s before the composer becomes usable.
4. Measure: grep -o 'create_session_rpc_ms=[0-9]*' ~/.copilot/logs/github-app.*.log

Expected behavior

create_session_rpc_ms back to sub-second, as in 1.1.13 / 1.1.14.

Additional context

Regression boundary is exact. Measured from create_session_rpc_ms across my ~/.copilot/logs/github-app.*.log:

Log	Date	Creations	Avg	>10s
github-app.63460	Sep 1	189	0.6s	0
github-app.88674	Sep 2	135	0.8s	0
github-app.99993	Sep 5 02:03	167	0.9s	2
github-app.79888	Sep 5 13:44+	33	30.8s	33
github-app.41665	Sep 6	126	~30s	124

• Last fast creation: 2026-09-05T05:33 (511 ms)
• App bundle replaced: 2026-09-05 09:43 (data.db.pre-update-backup-1.1.15-…)
• First slow creation: 2026-09-05T13:44:11 (create_session_rpc_ms=31438)

Current distribution over 126 creations:

121  30-35s
  3  >35s
  2  <1s

Not configuration-dependent. Average / minimum create_session_rpc_ms grouped by session cwd — every location hits the same floor, including a bare chat scratch directory with no git repo, no .mcp.json and no project config:

44  avg=31.7s  min=30.5s  <local repo A>
34  avg=30.4s  min=30.2s  <vault, OneDrive-backed>
13  avg=30.8s  min=30.6s  <local repo B>
 1  avg=30.7s  min=30.7s  <git worktree>
 1  avg=30.8s  min=30.8s  ~/.copilot
 1  avg=30.2s  min=30.2s  ~/.copilot/chats/<scratch>   <-- no repo, no MCP

Minimum across all 126 creations: 30.2s. The tight clustering just above 30.0s looks like a fixed 30-second deadline being hit and abandoned rather than genuine work.

The stall is entirely inside the CLI RPC. The app logs creating session, the CLI is silent for 30.2s, then emits its first permission request and returns:

20:52:36.409  github_app::session::core: creating session session_id="…" cwd="…"
20:52:36.417  github_app::session::core: Wiring bundled copilot-sdk path for session.create
              … 30 seconds of no CLI-side output …
20:53:06.635  session_event_loop{…}: permission_request_handler{…}
                 permission_kind="extension-permission-access"
                 tool_name="" should_auto_approve=true
20:53:06.647  github_app::session::core: CLI session created create_session_rpc_ms=30220

The only thing emitted at the end of the window is an extension-permission-access request with an empty tool_name that is set to auto-approve — which suggests session.create now synchronously awaits an extension permission/capability negotiation that never resolves and is abandoned at a 30s deadline.

Ruled out

• MCP config — global ~/.copilot/mcp-config.json declares one server; scratch dirs with no MCP config stall identically.
• Filesystem / cloud-synced paths — local-SSD repos and a OneDrive-backed folder both stall ~30s.
• Repo size / git — ~/.copilot itself and empty scratch dirs stall ~30s. (Separately saw 3 × git ls-remote 60s timeouts; unrelated and far too rare.)
• Session-state volume — stall is constant before and after pruning ~4,200 stale session-state directories.
• Extension count — only ~5 distinct extensions load.

User-visible impact. The app pre-spawns warmup sessions to hide creation latency. At 30s per create the warmup pool cannot refill at interactive speed, so clicking New Session returns nothing ready and the next message can land in the previously focused session.

Happy to share full logs or run any diagnostic.

Environment

• macOS, Apple Silicon
• Desktop app 1.1.15, bundled CLI 1.0.83-5

Reproduce session creation in Desktop app 1.1.15 and inspect the bundled CLI's session.create path, using the reported create_session_rpc_ms log query as the first diagnostic. Trace the 30-second pause around the extension-permission-access request and compare behavior with 1.1.13/1.1.14; done means session creation returns without the fixed delay and restores sub-second timings.