最近，我将 WordPress AI 翻译优化项目整理并提交到 GitHub。项目本地仓库已经完成初始化，代码修改、离线测试和 Git commit 也都可以交给 Codex 执行。
不过，在真正推送代码时遇到了一个问题：
Codex 可以修改和提交代码，但执行
git push时，无法读取 GitHub HTTPS 凭据。
如果每次都需要退出 Codex，再回到普通终端手工输入 GitHub 用户名和凭据，整个自动化流程就会被打断。
因此，这次我使用 GitHub CLI 完成浏览器授权，并将 Git 配置为通过 GitHub CLI 获取 HTTPS 凭据。配置完成后，Codex 已经能够直接将本地提交推送到 GitHub。
本文记录完整过程。
一、问题背景
这次需要提交的是一个受保护 token 修复。
Codex 已经完成了严格的单次相邻 token 误编号修复，并通过全部离线测试。
随后创建了 Git commit：
2c9cba5 fix: repair uniquely misnumbered adjacent tokens
本地工作树干净，但 Codex 执行：
git push origin main
时失败。
错误信息如下：
fatal: could not read Username for 'https://github.com': No such device or address
二、为什么 Codex 无法直接推送
当前仓库的远端地址使用 HTTPS：
https://github.com/shuijingwan/wordpress-ai-translation-pipeline.git
在没有配置凭据助手的情况下，Git 推送时通常需要交互式输入认证信息。
普通终端可以提示输入用户名和凭据，但 Codex 执行命令时不适合停下来等待人工输入。这也是为什么：
- Codex 可以修改文件；
- Codex 可以运行测试；
- Codex 可以执行
git add； - Codex 可以创建 commit；
- 但到了
git push阶段就会失败。
从长期使用角度看，更合理的方式不是每次手动输入认证信息，而是给当前 Linux 用户配置一个安全、可复用的 GitHub 凭据助手。
三、为什么选择 GitHub CLI
我最终选择使用 GitHub CLI，也就是 gh。
它比较适合当前场景，主要原因有：
- 可以通过浏览器完成 GitHub 授权；
- 不需要手动创建和复制 Personal Access Token；
- 可以将 Git 配置为通过
gh获取 HTTPS 凭据； - Codex 与本地终端使用同一个 Linux 用户环境；
- 配置完成后，普通的
git push不再需要重复输入用户名和凭据； - 不需要将现有 HTTPS remote 改为 SSH。
此前仓库已经能够通过 HTTPS 正常访问，因此没有必要为了自动推送再切换到 SSH。
四、安装 GitHub CLI
当前系统可以直接从 Ubuntu 软件源安装 gh。
执行：
sudo apt install gh \
&& gh --version
安装完成后输出：
gh version 2.46.0 (2025-12-13 Ubuntu 2.46.0-4)
这一步只安装 GitHub CLI，并不会修改仓库，也不会自动获得 GitHub 账号权限。
五、通过浏览器登录 GitHub
安装完成后，执行：
gh auth login --hostname github.com --git-protocol https --web
这条命令指定了三个关键参数：
--hostname github.com
表示登录 GitHub.com。
--git-protocol https
表示后续 Git 操作继续使用 HTTPS。
--web
表示通过浏览器完成认证。
终端首先询问：
? Authenticate Git with your GitHub credentials? Yes
选择 Yes。
随后终端显示一次性设备验证码：
! First copy your one-time code: XXXX-XXXX
Press Enter to open github.com in your browser...
这个验证码只应该填写到 GitHub 官方设备授权页面，不应该发到聊天记录、截图或公开文章中。
六、在 GitHub 页面完成设备授权
浏览器打开后，会进入 GitHub 的设备授权页面。
页面要求输入终端中显示的一次性验证码。
输入验证码并继续后，GitHub 还要求进行一次敏感操作确认。
由于我的 GitHub 账号启用了两步验证，这里要求输入的不是账号密码，而是 Google Authenticator 中生成的动态验证码。
验证完成后，页面显示：
Congratulations, you're all set!
Your device is now connected.
这里需要特别说明：
具体显示密码、身份验证器代码还是其他验证方式，取决于 GitHub 账号当前启用的安全设置。
如果账号启用了 TOTP 两步验证，就可能需要输入 Google Authenticator 等身份验证器生成的动态验证码。
七、确认 GitHub CLI 登录成功
完成浏览器授权后，终端返回：
✓ Authentication complete.
- gh config set -h github.com git_protocol https
✓ Configured git protocol
✓ Logged in as shuijingwan
这说明：
- GitHub CLI 认证已经完成；
- Git 协议已经设置为 HTTPS；
- 当前登录账号为
shuijingwan。
随后可以执行：
gh auth status --hostname github.com
输出如下：
github.com
✓ Logged in to github.com account shuijingwan (keyring)
- Active account: true
- Git operations protocol: https
- Token: gho_************************************
- Token scopes: 'gist', 'read:org', 'repo', 'workflow'
这里的 token 会被自动隐藏，不需要手工复制。
gh auth status 确认 GitHub 登录状态八、让 Git 使用 GitHub CLI 凭据
仅仅完成 gh auth login 还不够。
还需要将 Git 配置为在访问 GitHub HTTPS remote 时，通过 GitHub CLI 获取凭据。
执行：
gh auth setup-git --hostname github.com
然后查看 GitHub 对应的凭据助手：
git config --global --get-all credential.https://github.com.helper
输出：
!/usr/bin/gh auth git-credential
这表示以后 Git 访问 GitHub HTTPS remote 时，会调用：
/usr/bin/gh auth git-credential
由 GitHub CLI 提供认证信息。
九、为什么没有使用 credential.helper store
一种更简单但风险更高的方式是：
git config --global credential.helper store
这种方式可能将凭据以可直接读取的形式保存到用户目录中。
虽然操作简单，但不适合长期使用，更不适合在包含自动化开发工具的环境中随意配置。
这次使用 GitHub CLI 后，认证信息由系统 keyring 和 gh 管理，不需要将 GitHub token 直接写入仓库、Shell 脚本或普通文本文件。
同时，也不需要：
- 将 token 写入
.env； - 将 token 写入 Git remote URL；
- 在 Codex 提示词中提供 token；
- 每次推送时手工输入账号；
- 将 GitHub 密码交给自动化工具。
十、让 Codex再次执行推送
完成认证配置后，我让 Codex只执行已有提交的推送，不允许修改文件或创建新 commit。
Codex 首先确认当前状态：
git status --short --branch
此前状态为：
## main...origin/main [ahead 1]
这表示本地 main 比远端 origin/main 多一个提交。
本地待推送提交为：
2c9cba5 fix: repair uniquely misnumbered adjacent tokens
随后 Codex 执行：
git push origin main
这一次不再要求输入 GitHub 用户名或凭据，推送成功：
To https://github.com/shuijingwan/wordpress-ai-translation-pipeline.git
32fd767..2c9cba5 main -> main
十一、验证本地与远端提交一致
推送后，继续执行：
git fetch origin
git status --short --branch
git rev-parse HEAD
git rev-parse origin/main
本地 HEAD：
2c9cba59cd083a45feeda3c991bfa36571877a72
远端 origin/main：
2c9cba59cd083a45feeda3c991bfa36571877a72
两个完整 commit hash 完全一致。
最终状态：
## main...origin/main
这说明：
- 本地没有未提交修改；
- 本地没有未推送 commit；
- 远端没有本地尚未获取的提交；
main与origin/main已经完全同步。
十二、配置完成后的实际工作流
完成这次配置后，后续 Codex 可以连续完成以下流程：
检查代码
→ 修改本地文件
→ 执行语法检查
→ 运行离线测试
→ git diff --check
→ git add
→ git commit
→ git push
→ 验证 HEAD 与 origin/main
此前，最后的 git push 必须切回普通终端并手动输入认证信息。
现在 GitHub CLI 已经为当前用户配置了 HTTPS 凭据助手，Codex 可以直接完成整个本地 Git 流程。
当然，这不代表以后应该允许 Codex 在任何情况下自动提交和推送。
对于生产项目，我仍然会要求 Codex 在推送前完成：
- 明确限制允许修改的文件；
- 运行 PHP 语法检查；
- 执行离线测试；
- 检查
git diff --check； - 查看暂存区文件范围；
- 使用普通 push，禁止 force push；
- 推送后核对本地和远端 commit hash；
- 生产部署仍然单独授权。
认证自动化解决的是操作效率问题，而不是取消代码审核。
十三、GitHub 认证与生产部署仍然是两件事
这次完成的是：
本地修改
→ 离线测试
→ Git commit
→ GitHub push
生产服务器并没有发生变化。
具体来说，本次没有：
- 修改生产服务器上的 MU 插件；
- 调用 GLM API；
- 重新翻译文章；
- 修改生产
/tmp诊断文件； - 清理生产缓存；
- 发布任何新文章。
GitHub 推送成功，只表示新代码已经安全保存到远端仓库。
正式部署仍然需要单独进行：
部署前只读确认
→ 核对生产文件哈希
→ 创建生产备份
→ 上传或替换文件
→ PHP 语法检查
→ WordPress 插件加载检查
→ 功能验证
→ 再决定是否重新翻译
这两个阶段不应该合并。
十四、关于 Codex 自动推送的安全边界
GitHub 凭据配置完成后，Codex 确实具备了推送能力。
这也意味着，后续给 Codex 的指令应该更明确。
例如，执行推送时建议写清楚：
只允许普通 git push origin main
禁止 force push
禁止修改 remote
禁止操作标签
禁止 amend
禁止 rebase
禁止创建额外 commit
对于包含多个仓库的工作目录，还应该明确：
工作区：
/home/wangqiang/code/wordpress-ai-translation-pipeline
避免 Codex 在错误仓库中执行 Git 操作。
另外，不建议让 Codex执行以下高风险命令：
git push --force
git reset --hard
git clean -fd
git remote set-url
git rebase
除非已经明确分析风险，并且确实需要。
十五、这次配置的最终结果
经过这次配置，当前状态为：
GitHub CLI：已安装
GitHub 账号：已登录
Git 协议：HTTPS
凭据存储：系统 keyring
Git credential helper：gh auth git-credential
Codex 自动 push：验证成功
本次成功推送的提交为：
2c9cba59cd083a45feeda3c991bfa36571877a72
提交说明：
fix: repair uniquely misnumbered adjacent tokens
仓库最终状态：
## main...origin/main
十六、总结
最初的问题并不复杂：Codex 可以修改和提交代码，但无法在非交互环境中输入 GitHub HTTPS 凭据，因此 git push 失败。
最终解决流程为：
安装 GitHub CLI
→ gh auth login
→ 浏览器设备授权
→ 完成两步验证
→ gh auth setup-git
→ Git 使用 gh credential helper
→ Codex 再次执行 git push
→ 推送成功
实际使用的核心命令只有几条：
sudo apt install gh
gh auth login --hostname github.com --git-protocol https --web
gh auth setup-git --hostname github.com
gh auth status --hostname github.com
配置完成后，不仅 Codex 可以自动推送，本地终端执行 GitHub HTTPS 操作时也不再需要重复输入用户名和凭据。
对于需要频繁进行“修改、测试、提交、推送”的本地开发流程，这项配置能够明显减少人工切换。但自动认证和自动推送并不等于自动部署，生产服务器操作仍然应该保持独立授权和严格验证。
需要长期技术维护或远程问题排查？
我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。
如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：
- ✅ PHP / Laravel / Yii2 老项目无人维护
- ✅ Go / Gin 后端接口需要排查或优化
- ✅ WordPress 网站访问慢、报错或插件冲突
- ✅ Nginx / MySQL / Redis / Linux 服务器异常
- ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
- ✅ 需要长期远程技术支持或兼职维护
更多介绍请查看：关于我 & 合作
微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan
发表回复