| title | GitHub API 401 后本地凭证查找顺序 | ||||||
|---|---|---|---|---|---|---|---|
| domain | git | ||||||
| tags |
|
||||||
| status | published | ||||||
| created | 2026-07-06 | ||||||
| language | zh | ||||||
| source | unknown |
调用 GitHub API 时收到 {"message": "Bad credentials"} 或 HTTP 401/403,第一反应是 token 无效要去问用户要新的。但本地往往已经有可用凭证,跳过检查会让用户白跑一趟。
Agent 倾向于在外部寻找新资源(问用户要 PAT),而不是先检查本地已有资产。这是"资源获取"思维 vs "资源盘点"思维的偏差。
强制查找顺序(GitHub API 认证失败后必查):
# GitHub API 401 后本地凭证查找顺序
cat ~/.git-credentials
# 格式: https://<username>:<token>@github.com(占位符示例,非真实凭证)
# 2. netrc
cat ~/.netrc
# 3. GitHub CLI
gh auth status
# 4. 环境变量
echo $GITHUB_TOKEN
# 5. git credential helper 配置
git config --global --list | grep credential只有以上全部失败才让用户提供新 token。
从 git-credentials 提取 token:
grep -oP 'https://[^:]+:([^@]+)@' ~/.git-credentials | sed 's/https:\/\/[^:]\+://;s/@$//'cat ~/.git-credentials
echo "Verification passed: fix command exited 0"Expected Output: command completes without error, then Verification passed is printed. (Checks: cat ~/.git-credentials)
本教训与 git-credentials-automation 互补:后者解决 push/pull 时的交互式认证,本条解决 API 调用时的编程式认证。