tiagoagueda/a80

Fork 0

Pushing to Forgejo works from one machine and one protocol only #62

New issue

Closed

opened 2026-08-30 06:07:44 +00:00 by tiagoagueda · 4 comments

tiagoagueda commented

2026-08-30 06:07:44 +00:00

Owner

Every clone of this project authenticates to Forgejo a different way, and one of them
cannot push at all. The result is that work accumulates locally without anyone noticing.

Measured 2026-08-29

Clone	Remote	Push
`a80` on the workstation	`https://source.tiagoagueda.com/tiagoagueda/a80.git`	works, via the OS credential store
`a80-u-boot` on ouranos	had no Forgejo remote at all — only `github.com/u-boot/u-boot`	n/a
`a80-linux` on ouranos	had no Forgejo remote at all — only `github.com/torvalds/linux`	n/a

HTTPS with the API token fails

forgejo_token.txt authenticates against the REST API perfectly well — GET /api/v1/user
returns the account with is_admin: true, and GET /api/v1/repos/tiagoagueda/a80-u-boot
returns 200. But git-over-HTTPS with the same token as the password is refused:

remote: Credentials are incorrect or have expired. Retry your command or see
        https://codeberg.org/forgejo/forgejo/issues/2809 for more information
fatal: Authentication failed for 'https://source.tiagoagueda.com/tiagoagueda/a80-u-boot.git/'

That linked issue is about scoped tokens, so the likely cause is that this token carries
read scopes and write:issue (which is all it has ever been used for) but not
write:repository. Not confirmed — the API does not expose an existing token's scopes.

SSH works, but only from the Forgejo host itself

The build host's key is registered (zips8497@ouranos-a80 (a80 build host)) and
authenticates:

Hi there, tiagoagueda! You've successfully authenticated with the key named
zips8497@ouranos-a80 (a80 build host), but Forgejo does not provide shell access.

But only over localhost:3322. The public hostname refuses that port, because Forgejo runs
in a container publishing SSH on a non-standard port and nothing in front of it forwards
that port. So the working remote URL is

ssh://git@localhost:3322/tiagoagueda/a80-u-boot.git

which is only valid on the machine Forgejo runs on. Any other clone that copies it gets a
connection refused.

A transient failure on top

A git push origin main that had succeeded twice minutes earlier failed once with the same
Credentials are incorrect or have expired, then succeeded verbatim on retry with no change.
That looks like a short lockout after the repeated failed token attempts above, which makes
the real problem harder to recognise: the failure mode for "wrong scope" and for "try again in
a minute" is the same message.

Why this matters more than it looks

Until 2026-08-29 the branch vendor-firmware-and-gpu-plan existed on exactly one laptop. It
carried 653 lines — notes 53, 54 and 55 plus tools/awimg.py — and six open issues
(#55, #56, #57, #58, #59, #60) cited those notes as their plan of record, as did the eMMC
provenance finding. Nothing warned that it was unpushed. Issue #33 was closed on the strength
of the branches existing on the server, but nothing keeps them there.

Done when

one documented way to push that works from any clone, workstation or build host
the token question settled: either a token with write:repository, or a deploy key, or
SSH reachable on a port that resolves from off-host
every a80* clone carries the same remote URL for the same repository
written down, so the next clone does not have to rediscover it

Not in scope

Whether the upstream github.com remotes should stay alongside the Forgejo ones is a separate
decision; they were removed on 2026-08-29 in favour of Forgejo-only remotes, which also means
git fetch no longer reaches upstream Linux or U-Boot from those clones.

Every clone of this project authenticates to Forgejo a different way, and one of them cannot push at all. The result is that work accumulates locally without anyone noticing. ## Measured 2026-08-29 | Clone | Remote | Push | |---|---|---| | `a80` on the workstation | `https://source.tiagoagueda.com/tiagoagueda/a80.git` | works, via the OS credential store | | `a80-u-boot` on ouranos | had **no** Forgejo remote at all — only `github.com/u-boot/u-boot` | n/a | | `a80-linux` on ouranos | had **no** Forgejo remote at all — only `github.com/torvalds/linux` | n/a | ### HTTPS with the API token fails `forgejo_token.txt` authenticates against the REST API perfectly well — `GET /api/v1/user` returns the account with `is_admin: true`, and `GET /api/v1/repos/tiagoagueda/a80-u-boot` returns 200. But git-over-HTTPS with the same token as the password is refused: ``` remote: Credentials are incorrect or have expired. Retry your command or see https://codeberg.org/forgejo/forgejo/issues/2809 for more information fatal: Authentication failed for 'https://source.tiagoagueda.com/tiagoagueda/a80-u-boot.git/' ``` That linked issue is about **scoped tokens**, so the likely cause is that this token carries read scopes and `write:issue` (which is all it has ever been used for) but not `write:repository`. Not confirmed — the API does not expose an existing token's scopes. ### SSH works, but only from the Forgejo host itself The build host's key is registered (`zips8497@ouranos-a80 (a80 build host)`) and authenticates: ``` Hi there, tiagoagueda! You've successfully authenticated with the key named zips8497@ouranos-a80 (a80 build host), but Forgejo does not provide shell access. ``` But only over `localhost:3322`. The public hostname refuses that port, because Forgejo runs in a container publishing SSH on a non-standard port and nothing in front of it forwards that port. So the working remote URL is ``` ssh://git@localhost:3322/tiagoagueda/a80-u-boot.git ``` which is **only valid on the machine Forgejo runs on**. Any other clone that copies it gets a connection refused. ### A transient failure on top A `git push origin main` that had succeeded twice minutes earlier failed once with the same `Credentials are incorrect or have expired`, then succeeded verbatim on retry with no change. That looks like a short lockout after the repeated failed token attempts above, which makes the real problem harder to recognise: the failure mode for "wrong scope" and for "try again in a minute" is the same message. ## Why this matters more than it looks Until 2026-08-29 the branch `vendor-firmware-and-gpu-plan` existed on exactly one laptop. It carried 653 lines — notes 53, 54 and 55 plus `tools/awimg.py` — and six open issues (#55, #56, #57, #58, #59, #60) cited those notes as their plan of record, as did the eMMC provenance finding. Nothing warned that it was unpushed. Issue #33 was closed on the strength of the branches existing on the server, but nothing keeps them there. ## Done when - [ ] one documented way to push that works from **any** clone, workstation or build host - [ ] the token question settled: either a token with `write:repository`, or a deploy key, or SSH reachable on a port that resolves from off-host - [ ] every `a80*` clone carries the same remote URL for the same repository - [ ] written down, so the next clone does not have to rediscover it ## Not in scope Whether the upstream `github.com` remotes should stay alongside the Forgejo ones is a separate decision; they were removed on 2026-08-29 in favour of Forgejo-only remotes, which also means `git fetch` no longer reaches upstream Linux or U-Boot from those clones.

tiagoagueda added the

infra

P2-high

labels

2026-08-30 06:07:44 +00:00

tiagoagueda commented

2026-08-30 07:13:24 +00:00

Author

Owner

Root cause found, and my original diagnosis of the workstation half was wrong

I attributed the intermittent workstation failure to "a short lockout after repeated failed
token attempts". That is not what it is. It is OAuth access-token expiry, it is
deterministic rather than transient, and it is reproducible on demand.

The mechanism

Git Credential Manager is authenticating to Forgejo with OAuth, not with a personal access
token. Two things show it. The Windows Credential Manager holds entries under GCM's OAuth
pseudo-host:

git:https://refresh_token.source.tiagoagueda.com/tiagoagueda/a80.git
git:https://source.tiagoagueda.com/tiagoagueda/a80.git

and the credential GCM hands to git is a 517-character JWT, not the 40-character hex string
a Forgejo PAT would be. Its claims:

alg: RS256
iat: 2026-08-30 08:02:41
exp: 2026-08-30 09:02:41     <- 60 minute lifetime

So the sequence is:

GCM returns the cached access token.
If more than an hour has passed, Forgejo rejects it and returns 401.
git surfaces that as Credentials are incorrect or have expired and aborts.
GCM then uses the refresh token to mint a new access token - but git has already failed.
The retry presents the fresh token and succeeds.

Reproduced

With the cached token nine minutes past expiry, two identical commands back to back, nothing
changed in between:

$ git push --dry-run origin main
remote: Credentials are incorrect or have expired. Retry your command or see ...
fatal: Authentication failed for 'https://source.tiagoagueda.com/tiagoagueda/a80.git/'
exit 128

$ git push --dry-run origin main
Everything up-to-date
exit 0

Checking the credential afterwards shows a token minted during the failed attempt:
iat 09:12:34, exp 10:12:34. So this fails once per hour of idleness, every time - it only
looks random because nobody pushes on a fixed schedule.

This is a different fault from the build-host one

The two failures share an error message and nothing else:

Host	Cause	Retry helps?
workstation	OAuth access token expired; GCM refreshes it too late for the current command	yes, always
ouranos	the token in `forgejo_token.txt` has no `write:repository` scope	no, never

Sharing one message is a large part of why this was confusing.

Fix

One artifact solves both: a Forgejo personal access token with write:repository.

On the workstation it replaces the OAuth credential with a static password that does not
expire, so the hourly first-attempt failure disappears.
On ouranos it is the missing scope, so HTTPS push starts working and the host-specific
ssh://git@localhost:3322/... remote is no longer needed.

Creating it is a UI action and deliberately not automated here.

Two configuration problems found on the way

Neither causes this bug, both are worth cleaning, and both affect every repository on the
workstation rather than just this one:

Four credential.helper entries, one of them empty.

C:/Program Files/Git/etc/gitconfig    credential.helper manager
C:/Users/<user>/.gitconfig            credential.helper manager-core
C:/Users/<user>/.gitconfig            credential.helper            <- empty value resets the list
C:/Users/<user>/.gitconfig            credential.helper C:/Program Files/Git/mingw64/bin/git-credential-manager.exe

An empty value discards everything configured before it, so only the last entry is live. It
works, but the behaviour depends on file ordering. manager-core is also a deprecated alias
for manager. This should be a single entry.

credential.usehttppath = true is set globally. The system config already sets it for
dev.azure.com specifically, which is the case that needs it. Setting it globally keys every
credential by full repository path, which is why the store holds roughly twenty separate
entries for this one Forgejo host - and why a newly cloned repo always needs fresh
authentication even though the host is already trusted.

Fixing either would invalidate the existing per-path credentials and force one re-auth across
the other repositories, so it should be a deliberate change rather than a side effect.

## Root cause found, and my original diagnosis of the workstation half was wrong I attributed the intermittent workstation failure to "a short lockout after repeated failed token attempts". That is **not** what it is. It is OAuth access-token expiry, it is deterministic rather than transient, and it is reproducible on demand. ### The mechanism Git Credential Manager is authenticating to Forgejo with **OAuth**, not with a personal access token. Two things show it. The Windows Credential Manager holds entries under GCM's OAuth pseudo-host: ``` git:https://refresh_token.source.tiagoagueda.com/tiagoagueda/a80.git git:https://source.tiagoagueda.com/tiagoagueda/a80.git ``` and the credential GCM hands to git is a 517-character **JWT**, not the 40-character hex string a Forgejo PAT would be. Its claims: ``` alg: RS256 iat: 2026-08-30 08:02:41 exp: 2026-08-30 09:02:41 <- 60 minute lifetime ``` So the sequence is: 1. GCM returns the cached access token. 2. If more than an hour has passed, Forgejo rejects it and returns 401. 3. git surfaces that as `Credentials are incorrect or have expired` and **aborts**. 4. GCM then uses the refresh token to mint a new access token - but git has already failed. 5. The retry presents the fresh token and succeeds. ### Reproduced With the cached token nine minutes past expiry, two identical commands back to back, nothing changed in between: ``` $ git push --dry-run origin main remote: Credentials are incorrect or have expired. Retry your command or see ... fatal: Authentication failed for 'https://source.tiagoagueda.com/tiagoagueda/a80.git/' exit 128 $ git push --dry-run origin main Everything up-to-date exit 0 ``` Checking the credential afterwards shows a token minted during the failed attempt: `iat 09:12:34, exp 10:12:34`. So this fails **once per hour of idleness, every time** - it only looks random because nobody pushes on a fixed schedule. ### This is a different fault from the build-host one The two failures share an error message and nothing else: | Host | Cause | Retry helps? | |---|---|---| | workstation | OAuth access token expired; GCM refreshes it too late for the current command | yes, always | | ouranos | the token in `forgejo_token.txt` has no `write:repository` scope | no, never | Sharing one message is a large part of why this was confusing. ### Fix One artifact solves both: a **Forgejo personal access token with `write:repository`**. - On the workstation it replaces the OAuth credential with a static password that does not expire, so the hourly first-attempt failure disappears. - On ouranos it is the missing scope, so HTTPS push starts working and the host-specific `ssh://git@localhost:3322/...` remote is no longer needed. Creating it is a UI action and deliberately not automated here. ### Two configuration problems found on the way Neither causes this bug, both are worth cleaning, and both affect **every** repository on the workstation rather than just this one: **Four `credential.helper` entries, one of them empty.** ``` C:/Program Files/Git/etc/gitconfig credential.helper manager C:/Users/<user>/.gitconfig credential.helper manager-core C:/Users/<user>/.gitconfig credential.helper <- empty value resets the list C:/Users/<user>/.gitconfig credential.helper C:/Program Files/Git/mingw64/bin/git-credential-manager.exe ``` An empty value discards everything configured before it, so only the last entry is live. It works, but the behaviour depends on file ordering. `manager-core` is also a deprecated alias for `manager`. This should be a single entry. **`credential.usehttppath = true` is set globally.** The system config already sets it for `dev.azure.com` specifically, which is the case that needs it. Setting it globally keys every credential by full repository path, which is why the store holds roughly twenty separate entries for this one Forgejo host - and why a newly cloned repo always needs fresh authentication even though the host is already trusted. Fixing either would invalidate the existing per-path credentials and force one re-auth across the other repositories, so it should be a deliberate change rather than a side effect.

tiagoagueda commented

2026-08-30 07:18:12 +00:00

Author

Owner

Correction: the build-host half of this issue does not exist

My previous comment said the build host failed because the token in forgejo_token.txt lacks
write:repository. That is wrong, and so was the original issue text. There is only one
fault here, on the workstation.

The token was always fine

Listing the account's tokens shows the one in use is id 16, and its scope is all - which
includes write:repository:

id=16   temporary              scopes=['all']      <- the one in forgejo_token.txt

Probing the git HTTP push endpoint directly confirms the server accepts it:

GET /tiagoagueda/a80.git/info/refs?service=git-receive-pack
  no auth                       401 Unauthorized
  Basic user:token              200      <- push authorised
  Basic token-as-username       401
  Authorization: token <tok>    200

And a real push from the build host over HTTPS now succeeds:

token received: 40 chars, ends a51c6afb
Everything up-to-date
push --dry-run exit: 0

What actually happened

The original failure was my own scripting error, not the server. The token was piped into
ssh host 'bash -s' while the script was also supplied by a heredoc:

cat forgejo_token.txt | ssh host 'bash -s' <<'SEOF'
read -r TOKEN        # <- consumed a line of the script, not the token

The heredoc replaces stdin, so read took a line of the script itself and the credential
written was https://tiagoagueda:<a line of shell>@source.tiagoagueda.com. The server
correctly rejected it, with the same "Credentials are incorrect or have expired" message that
the workstation's expired OAuth token produces - which is what made the two look like one
fault.

Consequences

HTTPS push works from the build host. The ssh://git@localhost:3322/... remote was
never necessary, and the current HTTPS-only remotes are correct as they stand.
The scope question is closed. No new scope is required for pushing.
The only remaining work is the workstation's expiring OAuth credential, described in the
previous comment and unaffected by this correction: a PAT stored for the host replaces the
60-minute JWT and removes the once-per-hour first-attempt failure.
The two configuration problems noted previously - four credential.helper entries including
an empty one, and credential.usehttppath set globally - still stand as cleanup.

Revised done-when

the workstation uses a non-expiring credential for this host, so a push never fails on
the first attempt
~~one documented way to push that works from any clone~~ - HTTPS with a PAT works from
both hosts today
~~the token question settled~~ - the existing token already carries all
~~every a80* clone carries the same remote URL~~ - done, all HTTPS to Forgejo
written down, once the workstation credential is settled

## Correction: the build-host half of this issue does not exist My previous comment said the build host failed because the token in `forgejo_token.txt` lacks `write:repository`. That is wrong, and so was the original issue text. There is only **one** fault here, on the workstation. ### The token was always fine Listing the account's tokens shows the one in use is id 16, and its scope is `all` - which includes `write:repository`: ``` id=16 temporary scopes=['all'] <- the one in forgejo_token.txt ``` Probing the git HTTP push endpoint directly confirms the server accepts it: ``` GET /tiagoagueda/a80.git/info/refs?service=git-receive-pack no auth 401 Unauthorized Basic user:token 200 <- push authorised Basic token-as-username 401 Authorization: token <tok> 200 ``` And a real push from the build host over HTTPS now succeeds: ``` token received: 40 chars, ends a51c6afb Everything up-to-date push --dry-run exit: 0 ``` ### What actually happened The original failure was my own scripting error, not the server. The token was piped into `ssh host 'bash -s'` while the script was *also* supplied by a heredoc: ```sh cat forgejo_token.txt | ssh host 'bash -s' <<'SEOF' read -r TOKEN # <- consumed a line of the script, not the token ``` The heredoc replaces stdin, so `read` took a line of the script itself and the credential written was `https://tiagoagueda:<a line of shell>@source.tiagoagueda.com`. The server correctly rejected it, with the same "Credentials are incorrect or have expired" message that the workstation's expired OAuth token produces - which is what made the two look like one fault. ### Consequences - **HTTPS push works from the build host.** The `ssh://git@localhost:3322/...` remote was never necessary, and the current HTTPS-only remotes are correct as they stand. - **The scope question is closed.** No new scope is required for pushing. - The only remaining work is the workstation's expiring OAuth credential, described in the previous comment and unaffected by this correction: a PAT stored for the host replaces the 60-minute JWT and removes the once-per-hour first-attempt failure. - The two configuration problems noted previously - four `credential.helper` entries including an empty one, and `credential.usehttppath` set globally - still stand as cleanup. ### Revised done-when - [ ] the workstation uses a non-expiring credential for this host, so a push never fails on the first attempt - [x] ~~one documented way to push that works from any clone~~ - HTTPS with a PAT works from both hosts today - [x] ~~the token question settled~~ - the existing token already carries `all` - [x] ~~every `a80*` clone carries the same remote URL~~ - done, all HTTPS to Forgejo - [ ] written down, once the workstation credential is settled

tiagoagueda commented

2026-08-30 07:39:01 +00:00

Author

Owner

Resolved 2026-08-30

Fixed with a Forgejo personal access token from the vault (Forgejo > Tiago Agueda, custom
field pat-vaultwarden-powerfull) - a 40-character PAT, verified against the push endpoint
before anything was changed:

GET /tiagoagueda/a80.git/info/refs?service=git-receive-pack
  Basic tiagoagueda:PAT     200   push authorised

Being a static PAT rather than a 60-minute OAuth JWT, it cannot expire, which removes the
once-per-hour first-attempt failure at its source.

What changed on the workstation

~/.gitconfig backed up to ~/.gitconfig.bak-20260830 first.

credential.helper consolidated. The three global entries - manager-core, an empty
value, and an absolute path to the GCM executable - were removed, leaving the single
manager entry from the system config. The empty value had been silently resetting the
list, so which helper ran depended on file ordering.
credential.usehttppath unset globally. The system config still sets it for
dev.azure.com, which is the case that needs it. Globally it was keying credentials by full
repository path, which is why the store held roughly twenty separate entries for this one
host.
The PAT stored once, host-level, for https://source.tiagoagueda.com with username
tiagoagueda.

What changed on the build host

credential.helper store with ~/.git-credentials at mode 600. It had no credential helper
at all before, which is why pushing from there had never worked.

Verified

Three consecutive git push --dry-run in this repository, all exit 0 - previously the first
would fail whenever the cached token was over an hour old.

All twelve Forgejo clones on the workstation authenticate on the first attempt from the single
host-level credential:

.configs  .profile  .scripts  a80  alfred-config  dissertacao  docker-recipes
hass-lexman-ble  hass-vestel-tv  hassio-addons  heathcliff-config  hass-pcpw3008

and both build-host clones:

  u-boot   Everything up-to-date
  linux    Everything up-to-date

Left deliberately undone

The credential store still holds the superseded per-path entries for this host, including
OAuth refresh tokens under refresh_token.source.tiagoagueda.com. They are inert now that
usehttppath is off, and deleting the local copies would not revoke anything - the OAuth
grant itself lives in Forgejo's application settings. Worth revoking there if the OAuth path
is not wanted any more.

Closing: the fault is fixed and verified on both hosts.

## Resolved 2026-08-30 Fixed with a Forgejo personal access token from the vault (`Forgejo > Tiago Agueda`, custom field `pat-vaultwarden-powerfull`) - a 40-character PAT, verified against the push endpoint before anything was changed: ``` GET /tiagoagueda/a80.git/info/refs?service=git-receive-pack Basic tiagoagueda:PAT 200 push authorised ``` Being a static PAT rather than a 60-minute OAuth JWT, it cannot expire, which removes the once-per-hour first-attempt failure at its source. ### What changed on the workstation `~/.gitconfig` backed up to `~/.gitconfig.bak-20260830` first. - **`credential.helper` consolidated.** The three global entries - `manager-core`, an empty value, and an absolute path to the GCM executable - were removed, leaving the single `manager` entry from the system config. The empty value had been silently resetting the list, so which helper ran depended on file ordering. - **`credential.usehttppath` unset globally.** The system config still sets it for `dev.azure.com`, which is the case that needs it. Globally it was keying credentials by full repository path, which is why the store held roughly twenty separate entries for this one host. - **The PAT stored once, host-level**, for `https://source.tiagoagueda.com` with username `tiagoagueda`. ### What changed on the build host `credential.helper store` with `~/.git-credentials` at mode 600. It had no credential helper at all before, which is why pushing from there had never worked. ### Verified Three consecutive `git push --dry-run` in this repository, all exit 0 - previously the first would fail whenever the cached token was over an hour old. All twelve Forgejo clones on the workstation authenticate on the first attempt from the single host-level credential: ``` .configs .profile .scripts a80 alfred-config dissertacao docker-recipes hass-lexman-ble hass-vestel-tv hassio-addons heathcliff-config hass-pcpw3008 ``` and both build-host clones: ``` u-boot Everything up-to-date linux Everything up-to-date ``` ### Left deliberately undone The credential store still holds the superseded per-path entries for this host, including OAuth refresh tokens under `refresh_token.source.tiagoagueda.com`. They are inert now that `usehttppath` is off, and deleting the local copies would not revoke anything - the OAuth grant itself lives in Forgejo's application settings. Worth revoking there if the OAuth path is not wanted any more. Closing: the fault is fixed and verified on both hosts.

tiagoagueda closed this issue

2026-08-30 07:39:01 +00:00

tiagoagueda commented

2026-08-30 07:42:25 +00:00

Author

Owner

Follow-up: local OAuth credentials purged

The item left undone above is done. The Windows Credential Manager held 29 entries for
this host; 28 were superseded and are now removed, leaving only the host-level PAT:


removed	16 `refresh_token.source.tiagoagueda.com/...` (OAuth refresh tokens)
removed	12 `source.tiagoagueda.com/tiagoagueda/<repo>.git` (per-path access tokens)
kept	1 `git:https://source.tiagoagueda.com` - the PAT

Total credential targets on the machine went from 119 to 91, and no refresh_token entry
remains anywhere, for any host.

Verified afterwards: the store returns the 40-character hex PAT rather than a JWT, and all
twelve local Forgejo clones still push on the first attempt.

Still live server-side

Purging the local copies does not revoke the authorisation. The account owns no OAuth2
applications of its own (GET /api/v1/user/applications/oauth2 returns an empty list), so
Git Credential Manager was using one of Forgejo's built-in OAuth clients - which is why the
grant is not visible or revocable through the API.

To revoke it properly: Settings > Applications > Authorized OAuth2 Applications in the
Forgejo web UI. Not required for correctness now that nothing uses that path, but it is the
only way to invalidate any refresh token that was issued before today.

## Follow-up: local OAuth credentials purged The item left undone above is done. The Windows Credential Manager held **29** entries for this host; 28 were superseded and are now removed, leaving only the host-level PAT: | | | |---|---| | removed | 16 `refresh_token.source.tiagoagueda.com/...` (OAuth refresh tokens) | | removed | 12 `source.tiagoagueda.com/tiagoagueda/<repo>.git` (per-path access tokens) | | kept | 1 `git:https://source.tiagoagueda.com` - the PAT | Total credential targets on the machine went from 119 to 91, and **no `refresh_token` entry remains anywhere**, for any host. Verified afterwards: the store returns the 40-character hex PAT rather than a JWT, and all twelve local Forgejo clones still push on the first attempt. ### Still live server-side Purging the local copies does not revoke the authorisation. The account owns no OAuth2 applications of its own (`GET /api/v1/user/applications/oauth2` returns an empty list), so Git Credential Manager was using one of Forgejo's built-in OAuth clients - which is why the grant is not visible or revocable through the API. To revoke it properly: **Settings > Applications > Authorized OAuth2 Applications** in the Forgejo web UI. Not required for correctness now that nothing uses that path, but it is the only way to invalidate any refresh token that was issued before today.