HTTPS push fails because Cafe CLI credential helper was not configured#1

Summary

Both cafe auth login tokens were valid when HTTPS pushes to Git Cafe failed on 8 October 2026. Git never used them because cafe auth http setup had not been run. The CLI token store was not connected to Git's HTTPS credential lookup.

The tokens were revoked after both failures. Revocation did not cause the push failures. This corrects the earlier diagnosis that no Git Cafe token was available on the machine.

Timeline

All times are UTC on 2026-10-08, from cafe auth token list --include-revoked and the migration thread's command log.

• 08:33:49: cafe auth login creates token 1, ending 913226e1, with a device authorization grant.
• 10:43:58: git push --dry-run to https://git.cafe/screen/col.git fails with fatal: Authentication failed.
• 10:50:32: A second cafe auth login creates token 2, ending d2f0683b.
• 10:55:05: The push fails again with prompts disabled: fatal: could not read Username for 'https://git.cafe': terminal prompts disabled.
• 11:01:47 / 11:01:48: Tokens 1 and 2 are revoked, 1.6 seconds apart.
• 11:09:14: SSH key LOQ, fingerprint SHA256:wHCkwKg0JTB3E4CIUgyx8eOH7+E5HbvYurOBp/ac5vE, is added and creates grant ssh:LOQ.
• 11:09:54: A push over SSH to git@git.cafe:screen/col succeeds and creates branch git-cafe-migration.
• 16:56:50: Another cafe auth login creates token ending 7305c6a9, the current token at the time of these findings.

Root cause

cafe auth login stores its token for the CLI in Windows Credential Manager as cafe-cli/api:https:git.cafe:, using the bun-secrets backend.

Git's HTTPS authentication goes through Git Credential Manager, which looks for a git:https://git.cafe entry. No such entry existed. The global .gitconfig contained only credential.https://git.cafe.provider generic, which selects generic credential handling but does not connect Git to the Cafe CLI token.

The missing setup command is:

It writes this helper setting:

At the time of these findings, cafe auth http status still reported configured: false, status: missing.

Logging in again at 10:50 did not change Git's credential lookup. Even with the current valid CLI token, HTTPS pushes will still fail until the helper setup runs.

Observed errors

The first dry-run push failed with:

A retry with GIT_TERMINAL_PROMPT=0 and GCM_INTERACTIVE=never failed with:

Effect on the GitHub mirror

The local origin configuration pushed to Git Cafe first and GitHub second. The Git Cafe authentication failure stopped the GitHub push too. The earlier assumption that GitHub would still receive the push was incorrect.

Token revocation remains unresolved

Git Cafe records revokedAt, but not who revoked a token. cafe audit reports itself as unavailable.

The migration agent thread never ran a cafe command. PowerShell history showed four cafe auth login commands and no logout or revoke commands.

The 1.6-second gap between revocations suggests a single action in Git Cafe's web token settings, roughly two minutes before the user returned from the settings page with an SSH key. This explanation is likely but unconfirmed. The available evidence does not identify who or what revoked the tokens.

Current state and remaining work

• origin uses SSH at git@git.cafe:screen/col, with ~/.ssh/id_ed25519_gitcafe, and works.
• To enable HTTPS, run cafe auth http setup, then verify the helper status and an HTTPS push. These findings do not claim that setup or verification has been completed.
• CONTRIBUTING.md still shows HTTPS push URLs for Git Cafe without mentioning the helper setup. Add that step or document the working SSH setup.
• Pull requests can also be opened with cafe pr create. The earlier migration thread did not know the CLI was installed.

Source

Corrected findings supplied from migration thread a0eac674-6660-456d-88e4-2bb37ae2dc7f, its command log, token records, and PowerShell history. This issue records that investigation, not a fresh reproduction.