mirror of
https://github.com/coder/coder.git
synced 2026-09-24 15:04:27 +08:00
Ethan
411714cd73
## Problem The dogfood startup script uses `gh auth status` to decide whether to re-authenticate the GitHub CLI. That command exits non-zero when **any** stored credential is invalid—even if Coder external auth already injects a working `GITHUB_TOKEN` into the environment and `gh` commands work fine. On workspaces with a persistent home volume, `~/.config/gh/hosts.yml` retains OAuth tokens written by previous `gh auth login --with-token` calls. These tokens are issued by Coder's external auth integration and can be rotated or revoked between workspace starts, but the copy in `hosts.yml` persists on the volume. When the stored token goes stale, `gh auth status` reports two accounts: ``` ✓ Logged in to github.com account user (GITHUB_TOKEN) ← works fine ✗ Failed to log in to github.com account user (hosts.yml) ← stale token ``` It exits 1 because of the stale entry, even though `gh` API calls succeed via `GITHUB_TOKEN`. This makes the auth state **indeterminate** from `gh auth status` alone—you can't tell whether `gh` actually works or not. When the script enters the login branch: 1. `gh auth login --with-token` **refuses** to accept piped input when `GITHUB_TOKEN` is already set in the environment, and exits 1. 2. `set -e` kills the script before it reaches `sudo service docker start`. The result: Docker never starts, devcontainer health checks fail, and the workspace reports a startup error—all because of a stale GitHub CLI credential that has no bearing on workspace functionality. ## Fix - Switch the auth guard from `gh auth status` to `gh api user --jq .login`, which tests whether GitHub API access actually works regardless of which credential provides it. - Wrap the fallback `gh auth login` so a failure logs the indeterminate state but does not abort the script.