Summary
On Windows, GitHub Copilot app startup takes about two minutes before the session list is usable. App logs show prolonged list_workspaces processing and many short Git checks. Reducing the CLI session import window to seven days did not resolve this.
A backed-up diagnostic cleanup of 170 inactive workspace database entries reduced initial workspace-list processing from at least 118.688 seconds to at least 56.454 seconds. Session readiness improved to roughly 30-60 seconds. This helps, but still leaves a substantial startup delay and is not a durable application-level fix.
Environment
- Windows, x86_64
- GitHub Copilot app 1.1.26
- Bundled Copilot CLI 1.0.90-0
- CLI session import age limit: 7 days in both comparison launches
- Azure DevOps integration enabled in both comparison launches
- Background automation was present; these were real startup captures, not otherwise-idle benchmarks
Reproduction
- Use an existing Windows installation with a substantial saved workspace list. This installation had 866 non-archived workspace entries before the cleanup trial.
- Set the CLI session import age limit to seven days.
- Exit the app normally and relaunch it.
- Observe the delay before the session list becomes usable and inspect initial
list_workspaces processing in the app log.
Actual measurements
| Measurement |
Before inactive-entry cleanup |
After inactive-entry cleanup |
| Non-archived workspace entries |
866 |
696 |
| Initial workspace-list Git activity duration, lower bound |
118.688 s |
56.454 s |
| Observed session-list readiness |
About 2 minutes |
Roughly 30-60 seconds |
| CLI import age limit |
7 days |
7 days |
| Azure DevOps integration |
Enabled |
Enabled |
The backend durations are measured from the first workspace-list request to the last observed Git activity in its initial handler. They are lower bounds, not exact response-completion times or UI-readiness measurements. Detached CLI reconciliation was excluded from these initial-handler timings.
In a separate startup capture, 960 directly app-parented Git processes were observed in 180 seconds, including 883 rev-parse processes across 331 working-directory groups. Multiple checks occurred in the same directory groups. No successfully sampled Git process in that capture had an observed age of one second or longer. Sampling can miss short processes, so these counts are lower bounds and do not rule out every possible slow process.
An isolated local SDK full-metadata session listing using the bundled CLI completed in 1.4-2.1 seconds. That is not the identical full app startup context, but suggests raw local session listing alone is insufficient to explain the observed app delay.
Diagnostic intervention and persistence
The only intentional change between the two controlled comparison launches was removal of 170 inactive app workspace database entries older than 30 days, after a consistent SQLite backup and checks excluding running/open/referenced sessions and protected metadata. Session records, worktree records, conversation files, and source files were retained. Derived workspace/activity links were removed with the workspace entries. Background workload was not fully controlled.
The removed workspace IDs did not return after two fresh launches. A subsequent launch with the Azure DevOps integration disabled still spent at least 67.729 seconds in initial workspace-list Git processing. Disabling that integration did not explain the earlier measured cleanup improvement, because it was enabled in both comparison launches.
The database cleanup was a diagnostic experiment, not a recommended general workaround. Users should not need to keep deleting historical workspace metadata to obtain reasonable startup performance.
Expected behavior / investigation area
The saved session/workspace list should become usable promptly without waiting for Git validation across historical entries. Please investigate whether initial workspace enumeration, repository validation, or equivalent repeated Git queries are on the startup critical path. Using persisted metadata for initial display and refreshing repository information asynchronously may help, where correctness permits.
The exact implementation cause is unconfirmed; I have not inspected the app's backend source. The observations above identify a performance-sensitive path rather than proving a specific caching or concurrency defect.
Privacy
This report includes only software versions, aggregate counts, sanitized operation names, and timings. No raw logs, database files, backups, private project paths, session IDs, account details, or attachments are included.
Summary
On Windows, GitHub Copilot app startup takes about two minutes before the session list is usable. App logs show prolonged
list_workspacesprocessing and many short Git checks. Reducing the CLI session import window to seven days did not resolve this.A backed-up diagnostic cleanup of 170 inactive workspace database entries reduced initial workspace-list processing from at least 118.688 seconds to at least 56.454 seconds. Session readiness improved to roughly 30-60 seconds. This helps, but still leaves a substantial startup delay and is not a durable application-level fix.
Environment
Reproduction
list_workspacesprocessing in the app log.Actual measurements
The backend durations are measured from the first workspace-list request to the last observed Git activity in its initial handler. They are lower bounds, not exact response-completion times or UI-readiness measurements. Detached CLI reconciliation was excluded from these initial-handler timings.
In a separate startup capture, 960 directly app-parented Git processes were observed in 180 seconds, including 883
rev-parseprocesses across 331 working-directory groups. Multiple checks occurred in the same directory groups. No successfully sampled Git process in that capture had an observed age of one second or longer. Sampling can miss short processes, so these counts are lower bounds and do not rule out every possible slow process.An isolated local SDK full-metadata session listing using the bundled CLI completed in 1.4-2.1 seconds. That is not the identical full app startup context, but suggests raw local session listing alone is insufficient to explain the observed app delay.
Diagnostic intervention and persistence
The only intentional change between the two controlled comparison launches was removal of 170 inactive app workspace database entries older than 30 days, after a consistent SQLite backup and checks excluding running/open/referenced sessions and protected metadata. Session records, worktree records, conversation files, and source files were retained. Derived workspace/activity links were removed with the workspace entries. Background workload was not fully controlled.
The removed workspace IDs did not return after two fresh launches. A subsequent launch with the Azure DevOps integration disabled still spent at least 67.729 seconds in initial workspace-list Git processing. Disabling that integration did not explain the earlier measured cleanup improvement, because it was enabled in both comparison launches.
The database cleanup was a diagnostic experiment, not a recommended general workaround. Users should not need to keep deleting historical workspace metadata to obtain reasonable startup performance.
Expected behavior / investigation area
The saved session/workspace list should become usable promptly without waiting for Git validation across historical entries. Please investigate whether initial workspace enumeration, repository validation, or equivalent repeated Git queries are on the startup critical path. Using persisted metadata for initial display and refreshing repository information asynchronously may help, where correctness permits.
The exact implementation cause is unconfirmed; I have not inspected the app's backend source. The observations above identify a performance-sensitive path rather than proving a specific caching or concurrency defect.
Privacy
This report includes only software versions, aggregate counts, sanitized operation names, and timings. No raw logs, database files, backups, private project paths, session IDs, account details, or attachments are included.