Recently, I organized and committed my WordPress AI translation optimization project to GitHub. The local repository was already initialized, and code modifications, offline testing, and Git commits could all be handled by Codex.
However, I encountered a problem when actually pushing the code:
Codex can modify and commit code, but when executing
git push, it cannot read the GitHub HTTPS credentials.
If I had to exit Codex every time and return to a standard terminal to manually enter my GitHub username and credentials, the entire automation workflow would be interrupted.
Therefore, this time I used GitHub CLI to complete browser authorization and configured Git to obtain HTTPS credentials through GitHub CLI. After configuration, Codex was able to push local commits directly to GitHub.
This article documents the complete process.
1. Problem Background
The commit I needed to push this time was a protected token fix.
Codex had already completed a strict fix for uniquely misnumbered adjacent tokens and passed all offline tests.
Then, it created a Git commit:
2c9cba5 fix: repair uniquely misnumbered adjacent tokens
The local working tree was clean, but Codex failed when executing:
git push origin main
.
The error message was as follows:
fatal: could not read Username for 'https://github.com': No such device or address
2. Why Codex Cannot Push Directly
The remote URL for the current repository uses HTTPS:
https://github.com/shuijingwan/wordpress-ai-translation-pipeline.git
Without a credential helper configured, Git pushes typically require interactive input for authentication.
A standard terminal can prompt for a username and credentials, but Codex is not suited to pause and wait for manual input when executing commands. This is why:
- Codex can modify files;
- Codex can run tests;
- Codex can execute
git add; - Codex can create commits;
- but it fails at the
git pushstage.
For long-term use, a more reasonable approach is to configure a secure, reusable GitHub credential helper for the current Linux user, rather than manually entering authentication information every time.
3. Why I Chose GitHub CLI
I ultimately chose to use GitHub CLI, which is gh.
It is well-suited for the current scenario, mainly for the following reasons:
- It can complete GitHub authorization through a browser;
- It does not require manually creating and copying a Personal Access Token;
- It can configure Git to obtain HTTPS credentials through
gh; - Codex and the local terminal use the same Linux user environment;
- Once configured, standard
git pushno longer requires repeatedly entering a username and credentials; - There is no need to change the existing HTTPS remote to SSH.
The repository was already accessible via HTTPS, so there was no need to switch to SSH just for automatic pushing.
4. Installing GitHub CLI
The current system can install gh directly from the Ubuntu software repositories.
Execute:
sudo apt install gh \
&& gh --version
After installation, the output is:
gh version 2.46.0 (2025-12-13 Ubuntu 2.46.0-4)
This step only installs GitHub CLI; it does not modify the repository or automatically grant GitHub account permissions.
5. Logging into GitHub via Browser
Once installation is complete, execute:
gh auth login --hostname github.com --git-protocol https --web
This command specifies three key parameters:
--hostname github.com
indicates logging into GitHub.com.
--git-protocol https
indicates that subsequent Git operations will continue to use HTTPS.
--web
indicates that authentication is completed via a browser.
The terminal first asks:
? Authenticate Git with your GitHub credentials? Yes
Select Yes.
The terminal then displays a one-time device verification code:
! First copy your one-time code: XXXX-XXXX
Press Enter to open github.com in your browser...
This verification code should only be entered on the official GitHub device authorization page; it should not be posted in chat logs, screenshots, or public articles.
6. Completing Device Authorization on the GitHub Page
Once the browser opens, it will navigate to the GitHub device authorization page.
The page requires you to enter the one-time verification code displayed in the terminal.
After entering the verification code and continuing, GitHub also requires confirmation for a sensitive operation.
Because my GitHub account has two-factor authentication enabled, it asks for a dynamic verification code generated by Google Authenticator rather than my account password.
Once verification is complete, the page displays:
Congratulations, you're all set!
Your device is now connected.
A special note here:
Whether it prompts for a password, an authenticator code, or another verification method depends on the security settings currently enabled on the GitHub account.
If TOTP two-factor authentication is enabled for the account, it may require a dynamic verification code generated by an authenticator app like Google Authenticator.
7. Confirming GitHub CLI Login Success
After completing browser authorization, the terminal returns:
✓ Authentication complete.
- gh config set -h github.com git_protocol https
✓ Configured git protocol
✓ Logged in as shuijingwan
This indicates:
- GitHub CLI authentication is complete;
- The Git protocol has been set to HTTPS;
- The currently logged-in account is
shuijingwan.
You can then execute:
gh auth status --hostname github.com
The output is as follows:
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'
The token here is automatically masked and does not need to be copied manually.
gh auth status8. Configuring Git to Use GitHub CLI Credentials
Simply completing gh auth login is not enough.
You also need to configure Git to obtain credentials through GitHub CLI when accessing GitHub HTTPS remotes.
Execute:
gh auth setup-git --hostname github.com
Then check the credential helper corresponding to GitHub:
git config --global --get-all credential.https://github.com.helper
Output:
!/usr/bin/gh auth git-credential
This means that when Git accesses a GitHub HTTPS remote in the future, it will call:
/usr/bin/gh auth git-credential
GitHub CLI will provide the authentication information.
9. Why I Did Not Use credential.helper store
A simpler but riskier approach is:
git config --global credential.helper store
This method may save credentials in a directly readable format within the user’s directory.
Although simple to execute, it is not suitable for long-term use, and even less appropriate for casual configuration in an environment containing automated development tools.
By using GitHub CLI this time, the authentication information is managed by the system keyring and gh, eliminating the need to write the GitHub token directly into the repository, shell scripts, or plain text files.
At the same time, there is no need to:
- Write the token into
.env; - Write the token into the Git remote URL;
- Provide the token in Codex prompts;
- Manually enter the account credentials on every push;
- Hand over the GitHub password to an automation tool.
10. Letting Codex Execute the Push Again
After completing the authentication configuration, I had Codex only push the existing commit, disallowing file modifications or creating new commits.
Codex first confirmed the current status:
git status --short --branch
The previous status was:
## main...origin/main [ahead 1]
This indicates that the local main is one commit ahead of the remote origin/main.
The local commit pending push was:
2c9cba5 fix: repair uniquely misnumbered adjacent tokens
Codex then executed:
git push origin main
This time, it did not ask for a GitHub username or credentials, and the push succeeded:
To https://github.com/shuijingwan/wordpress-ai-translation-pipeline.git
32fd767..2c9cba5 main -> main
11. Verifying Local and Remote Commits Match
After the push, continue by executing:
git fetch origin
git status --short --branch
git rev-parse HEAD
git rev-parse origin/main
Local HEAD:
2c9cba59cd083a45feeda3c991bfa36571877a72
Remote origin/main:
2c9cba59cd083a45feeda3c991bfa36571877a72
The two full commit hashes are identical.
Final status:
## main...origin/main
This indicates:
- There are no uncommitted changes locally;
- There are no unpushed commits locally;
- The remote has no commits that have not been fetched locally;
mainandorigin/mainare fully synchronized.
12. Actual Workflow After Configuration
After completing this configuration, Codex can continuously complete the following workflow:
Check code
→ Modify local files
→ Run syntax check
→ Run offline tests
→ git diff --check
→ git add
→ git commit
→ git push
→ Verify HEAD and origin/main
Previously, the final git push required switching back to a standard terminal and manually entering authentication information.
Now that GitHub CLI has configured an HTTPS credential helper for the current user, Codex can complete the entire local Git workflow directly.
Of course, this does not mean Codex should be allowed to automatically commit and push under all circumstances in the future.
For production projects, I will still require Codex to complete the following before pushing:
- Explicitly restrict the files allowed to be modified;
- Run PHP syntax checks;
- Execute offline tests;
- Check
git diff --check; - Review the scope of staged files;
- Use a standard push, disallowing force push;
- Verify local and remote commit hashes after pushing;
- Production deployment remains separately authorized.
Authentication automation solves an operational efficiency problem; it does not eliminate code review.
13. GitHub Authentication and Production Deployment Remain Separate
What was completed this time was:
Local modifications
→ Offline tests
→ Git commit
→ GitHub push
The production server was not affected.
Specifically, this time I did not:
- Modify MU plugins on the production server;
- Call the GLM API;
- Re-translate articles;
- Modify production
/tmpdiagnostic files; - Clear the production cache;
- Publish any new articles.
A successful GitHub push only means the new code has been safely saved to the remote repository.
Formal deployment still needs to be done separately:
Read-only confirmation before deployment
→ Verify production file hashes
→ Create production backup
→ Upload or replace files
→ PHP syntax check
→ WordPress plugin load check
→ Functional verification
→ Then decide whether to re-translate
These two stages should not be merged.
14. Security Boundaries for Codex Automatic Pushes
With GitHub credentials configured, Codex does indeed have the ability to push.
This also means that subsequent instructions given to Codex should be more explicit.
For example, when executing a push, it is recommended to specify clearly:
Only allow standard git push origin main
Disable force push
Disable modifying remote
Disable operating on tags
Disable amend
Disable rebase
Disable creating additional commits
For working directories containing multiple repositories, you should also specify:
Workspace:
/home/wangqiang/code/wordpress-ai-translation-pipeline
This prevents Codex from executing Git operations in the wrong repository.
Additionally, it is not recommended to let Codex execute the following high-risk commands:
git push --force
git reset --hard
git clean -fd
git remote set-url
git rebase
unless the risks have been explicitly analyzed and it is truly necessary.
15. Final Result of This Configuration
After this configuration, the current status is:
GitHub CLI: Installed
GitHub account: Logged in
Git protocol: HTTPS
Credential storage: System keyring
Git credential helper: gh auth git-credential
Codex automatic push: Verification successful
The commit successfully pushed this time was:
2c9cba59cd083a45feeda3c991bfa36571877a72
Commit message:
fix: repair uniquely misnumbered adjacent tokens
Final repository status:
## main...origin/main
16. Summary
The initial problem was not complex: Codex could modify and commit code, but it could not enter GitHub HTTPS credentials in a non-interactive environment, so git push failed.
The final resolution workflow was:
Install GitHub CLI
→ gh auth login
→ Browser device authorization
→ Complete two-factor verification
→ gh auth setup-git
→ Git uses gh credential helper
→ Codex executes git push again
→ Push successful
There are only a few core commands actually used:
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
After configuration, not only can Codex push automatically, but local terminal executions of GitHub HTTPS operations also no longer require repeatedly entering a username and credentials.
For local development workflows that require frequent “modify, test, commit, push” cycles, this configuration significantly reduces manual context switching. However, automatic authentication and automatic pushing do not equate to automatic deployment; production server operations should still maintain independent authorization and strict verification.
需要长期技术维护或远程问题排查？
我是拥有 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