# HTTPS push fails because Cafe CLI credential helper was not configured · Issue \#1 · screen/git-cafe-https-push-findings

[View on GitCafe](https://git.cafe/screen/git-cafe-https-push-findings/issues/1)

Repository: [screen/git-cafe-https-push-findings](https://git.cafe/screen/git-cafe-https-push-findings)

Visibility: public

State: backlog

Priority: 0

## Description

[Discussion and activity](https://git.cafe/screen/git-cafe-https-push-findings/issues/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:

```sh
cafe auth http setup
```

It writes this helper setting:

```text
credential.https://git.cafe.helper = cafe auth http credential --host 'git.cafe'
```

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:

```text
fatal: Authentication failed for 'https://git.cafe/screen/col.git/'
```

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

```text
fatal: Cannot prompt because user interactivity has been disabled.
fatal: could not read Username for 'https://git.cafe': terminal prompts disabled
```

### 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.