Describe the bug
Since upgrading from v1.0.48 → v1.0.49, every interactive copilot session on native Linux hangs for ~20 seconds before the CLI prompt appears. The CLI does eventually start — it is not fully blocked like the WSL variant in #3385 — but every session has an unavoidable 20-second wait.
The freeze is isolated to the window between Starting Copilot CLI and ICU native addon loaded in the session log. This window was ~0.3s in v1.0.48 and is consistently ~20s in v1.0.49.
Root cause (confirmed via strace): v1.0.49 moved a D-Bus session bus / credential lookup (likely node-keytar / libsecret) onto the critical startup path before icu-native.node is loaded. The lookup uses a 0.5s + 15s retry/timeout pattern and only exits (giving up) after ~15.5s. Multiple worker threads are blocked waiting on the same futex. In v1.0.48 this lookup happened after ICU, so it was off the critical path.
Affected version
GitHub Copilot CLI 1.0.49
Steps to reproduce
- Install or auto-update to v1.0.49 on Linux.
- Run
copilot interactively.
- Observe ~20s delay before the CLI prompt appears.
Expected behavior
Startup should complete in under 1 second (as in v1.0.48).
Root cause (strace analysis)
A strace -f trace captured the exact blocking sequence:
11:29:23.721 Worker thread connects to D-Bus session bus /run/user/1001/bus
11:29:23.722 D-Bus auth succeeds (REJECTED EXTERNAL → OK → AGREE_UNIX_FD)
11:29:23.724 futex_wait(timeout=0.5s) → ETIMEDOUT ← credential lookup attempt 1
11:29:24.224 futex_wait(timeout=15.0s) → ETIMEDOUT ← credential lookup attempt 2
11:29:39.224 Thread exits with 0 (gave up after 15.5s)
[+4.8s for blocked worker threads to drain]
11:29:44.019 icu-native.node finally loaded ← CLI becomes usable
The D-Bus secret service is reachable (auth succeeds in <1ms) but the GetSecret/FindItems call never returns within either timeout window. All startup worker threads block on the same futex waiting for the result.
- v1.0.48: credential lookup happened after
icu-native.node loaded → off critical path
- v1.0.49: credential lookup happens before → blocks all of startup for ~20s
Observed behavior
Downgrading back to v1.0.48 on the same machine restores instant startup, confirming this is a pure v1.0.49 regression and not system-specific.
# v1.0.48 — instant (before auto-update)
2026-05-19T00:10:31.256Z [INFO] Starting Copilot CLI: 1.0.48
2026-05-19T00:10:31.543Z [INFO] ICU native addon loaded ← 0.3s later
# v1.0.49 — 20s freeze (after auto-update)
2026-05-19T00:12:49.143Z [INFO] Starting Copilot CLI: 1.0.49
2026-05-19T00:13:09.456Z [INFO] ICU native addon loaded ← 20.3s later
# v1.0.48 — instant again (after manual downgrade, same machine)
2026-05-20T14:59:27.126Z [INFO] Starting Copilot CLI: 1.0.48
2026-05-20T14:59:27.377Z [INFO] ICU native addon loaded ← 0.25s later
Across 20+ consecutive v1.0.49 sessions the delta was consistently 20–23s.
Environment
- OS: Ubuntu 22.04.5 LTS (Jammy Jellyfish)
- Kernel: 6.8.0-111-generic
- Arch: x86_64
- Shell: zsh
- Node.js (bundled in SEA): v24.15.0
- Binary: Single Executable Application,
~/.local/bin/copilot (154 MB)
What I've ruled out
| Candidate |
Result |
| MCP servers |
Disabled all, freeze persists |
| SQLite WAL bloat |
VACUUM + TRUNCATE applied, no effect |
| Stale lock files |
Cleaned, no effect |
| Node compile cache (cold) |
Added NODE_COMPILE_CACHE, no effect |
runtime.node cold page cache |
Pre-warmed, no effect |
| gnome-keyring / DBus ping |
DBus responds in 9ms — service is alive and healthy |
| Git repository in cwd |
NOT the cause — git detection happens after ICU loads |
| HTTPS to api.github.com |
Non-blocking (EINPROGRESS), not on critical path |
Workaround
Pin to v1.0.48 and disable auto-update:
export COPILOT_AUTO_UPDATE=false
# Download v1.0.48 from https://github.com/github/copilot-cli/releases/tag/v1.0.48
# (copilot-linux-x64.tar.gz) and replace your current binary
Related issues
Suggested fix
Move the credential/keytar lookup back to an async/deferred path that does not block icu-native.node initialization (as it was in v1.0.48), or reduce the 15s fallback timeout for the "secret not found" case.
Describe the bug
Since upgrading from v1.0.48 → v1.0.49, every interactive
copilotsession on native Linux hangs for ~20 seconds before the CLI prompt appears. The CLI does eventually start — it is not fully blocked like the WSL variant in #3385 — but every session has an unavoidable 20-second wait.The freeze is isolated to the window between
Starting Copilot CLIandICU native addon loadedin the session log. This window was ~0.3s in v1.0.48 and is consistently ~20s in v1.0.49.Root cause (confirmed via
strace): v1.0.49 moved a D-Bus session bus / credential lookup (likelynode-keytar/libsecret) onto the critical startup path beforeicu-native.nodeis loaded. The lookup uses a 0.5s + 15s retry/timeout pattern and only exits (giving up) after ~15.5s. Multiple worker threads are blocked waiting on the same futex. In v1.0.48 this lookup happened after ICU, so it was off the critical path.Affected version
Steps to reproduce
copilotinteractively.Expected behavior
Startup should complete in under 1 second (as in v1.0.48).
Root cause (strace analysis)
A
strace -ftrace captured the exact blocking sequence:The D-Bus secret service is reachable (auth succeeds in <1ms) but the
GetSecret/FindItemscall never returns within either timeout window. All startup worker threads block on the same futex waiting for the result.icu-native.nodeloaded → off critical pathObserved behavior
Downgrading back to v1.0.48 on the same machine restores instant startup, confirming this is a pure v1.0.49 regression and not system-specific.
Across 20+ consecutive v1.0.49 sessions the delta was consistently 20–23s.
Environment
~/.local/bin/copilot(154 MB)What I've ruled out
NODE_COMPILE_CACHE, no effectruntime.nodecold page cacheEINPROGRESS), not on critical pathWorkaround
Pin to v1.0.48 and disable auto-update:
Related issues
$EDITORmissing keystrokes starting from v1.0.49Suggested fix
Move the credential/keytar lookup back to an async/deferred path that does not block
icu-native.nodeinitialization (as it was in v1.0.48), or reduce the 15s fallback timeout for the "secret not found" case.