A scheduled job that commits and pushes over HTTPS runs fine for a while, then fails after the container image updates with
could not read Username for 'https://github.com': terminal prompts disabled
The token is still there and still valid. gh auth status reports it happily. Only the binding between git and the token has gone. This is openclaw/openclaw#173059.
Why it happens
gh auth setup-git writes the credential helper into the global $HOME/.gitconfig. In a container deployment only some paths are persistent volumes, and a global gitconfig usually is not one of them, so it lives in the ephemeral image layer and vanishes on every image update. Nothing warns you. The credential store itself may well be on a persistent path - the token survives, the helper that points git at it does not.
The nastier half is the failure report. The local commit succeeds, so the job looks like it completed, while the remote falls behind a little more every run. A job whose whole purpose is off-host backup can report success for days.
The fix
Put the binding on a persistent path instead of the global one. Either point the job at a repository-local helper inside the persistent volume, or persist the home directory itself where the deployment offers that option. For the OpenClaw container, the documented home volume does it:
OPENCLAW_HOME_VOLUME=openclaw_home
Whatever you choose, do not let the push step depend on ambient global git config that the image can drop. And make the failure visible - verify the remote ref after pushing rather than trusting a zero exit from git commit. A commit that never leaves the box is not a backup.