Version: copilot v1.0.65 (Node SEA, Linux x64)
OS / shell: Linux (Ubuntu), bash; installed via gh.io/copilot-install
Description
When the Copilot backend endpoints (api.github.com/copilot_internal/user, api.business.githubcopilot.com) are intermittently slow or timing out, copilot --interactive "<message>" hangs indefinitely at startup — spinner never resolves, the TUI never becomes usable, and there is no timeout, retry, or error. The process must be killed manually. Non-interactive prompt mode (copilot -p) and sessions that don't auto-send a first message do not exhibit this.
Copilot Business via org/enterprise; reproduced across multiple users on the same host; happy to share sanitized logs.
Steps to reproduce
- Induce latency/timeouts on the Copilot API endpoints (e.g., firewall delay/drop on api.business.githubcopilot.com and api.github.com/copilot_internal/*). Core api.github.com remains fast.
- Run copilot --interactive "hello".
- Observe: startup reaches "Memory enablement check: enabled" then stalls before "Sending request to the AI model" and hangs forever.
Expected
A bounded timeout with a clear error and/or retry on the startup auth/account bootstrap, so the client fails fast or degrades to a usable prompt —rather than hanging indefinitely.
Actual
Infinite hang. Diagnostics show the Node event loop is idle (process._getActiveRequests() empty; only stdio + 1 FSWatcher handles); the outboundsockets are owned by the native runtime. First error in logs:
[rust:runtime::auth_manager_orchestration] Failed to fetch OAuth user login:
network fetch failed ... api.github.com/copilot_internal/user (10s timeout)
i.e., the JS layer awaits a native-runtime promise that never resolves when the backend bootstrap call stalls.
Impact
On hosts with intermittent latency to the Copilot API paths, interactive launches hang with no recovery. A startup timeout/retry would make theclient resilient.
Additional context
Reproduced across multiple accounts; correlated with backend latency spikes (1.5–30s+) on the Copilot API hostnames while core GitHub API stayedfast (<0.1s). Prompt mode (-p) is a reliable workaround.
Version: copilot v1.0.65 (Node SEA, Linux x64)
OS / shell: Linux (Ubuntu), bash; installed via gh.io/copilot-install
Description
When the Copilot backend endpoints (api.github.com/copilot_internal/user, api.business.githubcopilot.com) are intermittently slow or timing out,
copilot --interactive "<message>"hangs indefinitely at startup — spinner never resolves, the TUI never becomes usable, and there is no timeout, retry, or error. The process must be killed manually. Non-interactive prompt mode (copilot -p) and sessions that don't auto-send a first message do not exhibit this.Copilot Business via org/enterprise; reproduced across multiple users on the same host; happy to share sanitized logs.
Steps to reproduce
Expected
A bounded timeout with a clear error and/or retry on the startup auth/account bootstrap, so the client fails fast or degrades to a usable prompt —rather than hanging indefinitely.
Actual
Infinite hang. Diagnostics show the Node event loop is idle (process._getActiveRequests() empty; only stdio + 1 FSWatcher handles); the outboundsockets are owned by the native runtime. First error in logs:
i.e., the JS layer awaits a native-runtime promise that never resolves when the backend bootstrap call stalls.
Impact
On hosts with intermittent latency to the Copilot API paths, interactive launches hang with no recovery. A startup timeout/retry would make theclient resilient.
Additional context
Reproduced across multiple accounts; correlated with backend latency spikes (1.5–30s+) on the Copilot API hostnames while core GitHub API stayedfast (<0.1s). Prompt mode (-p) is a reliable workaround.