--cloud owner picker hangs, reconnect crashes, and task polling reaches 429

Describe the bug

copilot --cloud fails through several connected symptoms:

1. Without repository context, the CLI hangs indefinitely at Loading available owners....
2. With repository context, the cloud task is created but remains at session.requested until provisioning times out.
3. Reconnecting with copilot --connect=<task-id> opens a blank terminal pane.
4. The reconnect process polls rapidly enough to receive HTTP 429 responses.

Affected version

GitHub Copilot CLI 1.0.81-7 prerelease on Windows 11 with PowerShell 7 and Windows Terminal.

Steps to reproduce the behavior

1. Authenticate through GitHub CLI with a valid token containing read:org.

2. Run:

   copilot --cloud
   

3. Observe the owner picker hanging at Loading available owners....

4. Run from a repository:

   copilot -C C:\path\to\repository --cloud
   

5. Observe the task being created, followed by:

   Timed out waiting for the remote sandbox to start.
   

6. Reconnect:

   copilot --connect=<task-id>
   

7. Observe a blank terminal pane.

Relevant sanitized log sequence

Owner discovery:

Welcome <user> (via gh)!
listOwnerOptions: failed to fetch owners: AbortError: This operation was aborted

Authentication:

gh auth token exited non-zero
stderr: no oauth token found for https://github.com
CLI auth notification has no usable server token

The equivalent command succeeds when given a hostname:

gh auth token --hostname github.com

It fails when given the full URL:

gh auth token --hostname https://github.com

The runtime configuration contains:

{
  "githubHost": "https://github.com"
}

Cloud task:

listed Mission Control task events
event_count=1
first_event_types=["session.requested"]

This remained unchanged for the entire provisioning period.

Reconnect:

switchSession failed: Error: Session has no GitHub auth service configured
TerminalRenderer React uncaught error:
Error: Session has no GitHub auth service configured

Polling then repeatedly failed with:

status=429
body_preview="too many requests"

Bundled implementation comparison

In 1.0.80, owner discovery directly fetches /user and /user/orgs using the session token.

In 1.0.81-7, it uses the native githubListOwnerOptions request and cancellation path. The request is aborted during the authentication-state transition.

This suggests a regression in the native owner-discovery/auth integration.

Expected behavior

• Normalize https://github.com to github.com before invoking gh auth token.
• Do not cancel owner discovery because an equivalent authentication object is refreshed.
• Do not switch the renderer to a remote session lacking its GitHub auth service.
• Surface reconnect failures instead of leaving a blank pane.
• Back off task polling and respect HTTP 429 responses.

Additional context

The repository was private, the authenticated user had admin access, and the token contained read:org.

Environment: Windows 11, x86_64, PowerShell 7, Windows Terminal.

No matching public issue was found. Raw logs are intentionally not attached because debug logging includes environment data.

まず、GitHub Copilot CLI 1.0.81-7 で一覧にある PowerShell コマンドを再現し、owner の検出を 1.0.80 と比較します。記録された AbortError、欠落している auth service、HTTP 429 応答の周辺について、認証の移行、reconnect セッションのセットアップ、task のポーリングを追跡します。owner の読み込みが完了し、provisioning が進行し、reconnect がレンダリングされるかエラーを報告し、ポーリングがレート制限時にバックオフすれば完了です。