This was generated by AI during triage.
Environment
- Windows 11
- GitHub Copilot desktop app v1.0.25 (updater reported latest)
- App-spawned Copilot CLI v1.0.71
- Existing sessions and multiple projects
Actual behavior
After starting the desktop app, the reporter observes approximately 1-2 minutes before existing sessions become usable.
One captured startup/resume sequence took 91.9 seconds:
| Segment |
Duration |
| App start -> resume request |
74.577s |
| Resume request -> completion |
17.402s |
The entire 91.9 seconds is not resume time, and logs do not prove the pre-request interval was entirely blocking.
Expected behavior
The app should become usable promptly after startup.
Observations
- Startup booted eight CLI processes: seven for catalog warming and one for the requested resume.
- Five CLI boot intervals overlapped at peak.
- No CLI spawn failures or retries occurred in this startup window.
- Across 22 samples from the full run,
spawn_ms was 6,598-21,343ms (median 12,196ms).
- Seven catalog creations reported
create_session_rpc_ms of 11,507-27,413ms.
- Cold
session_create_ms samples were 16,005-31,896ms; warm-process samples were 100-343ms.
These are separate metrics measured on this host.
Sanitized log shapes
github_app::session::manager::cli_pool: spawned new CLI process for pool ... pid=Some(<redacted>) spawn_ms=14516
github_app::session::core: CLI session created ... create_session_rpc_ms=<duration>
github_app::session::manager::lifecycle: session::create completed ... retain_cli_ms=<duration> model_fetch_ms=<duration> session_create_ms=26391 total_ms=<duration>
Unconfirmed factors
The profile contained 1,145 sessions and 1.37GB of session state. A clean-profile control was not performed because the investigation was read-only.
MCP configuration, Defender, orphaned processes, authentication warnings, and an invalid hook remain unproven as causes.
Related issues
Questions
- Is catalog warming expected to create one CLI process per project or directory?
- Should these CLI processes be reused or pooled?
- Which diagnostics expose the internal phases of
create_session_rpc_ms?
- Is a clean-profile reproduction required?
Additional context
This is a read-only investigation from one host. It establishes timing and correlation, not the internal root cause.
Environment
Actual behavior
After starting the desktop app, the reporter observes approximately 1-2 minutes before existing sessions become usable.
One captured startup/resume sequence took 91.9 seconds:
The entire 91.9 seconds is not resume time, and logs do not prove the pre-request interval was entirely blocking.
Expected behavior
The app should become usable promptly after startup.
Observations
spawn_mswas 6,598-21,343ms (median 12,196ms).create_session_rpc_msof 11,507-27,413ms.session_create_mssamples were 16,005-31,896ms; warm-process samples were 100-343ms.These are separate metrics measured on this host.
Sanitized log shapes
Unconfirmed factors
The profile contained 1,145 sessions and 1.37GB of session state. A clean-profile control was not performed because the investigation was read-only.
MCP configuration, Defender, orphaned processes, authentication warnings, and an invalid hook remain unproven as causes.
Related issues
listSessions.Questions
create_session_rpc_ms?Additional context
This is a read-only investigation from one host. It establishes timing and correlation, not the internal root cause.