Visibility API: mirror-specific HTTP 401 and allowed version-boundary HTTP 500#2

Investigation result

Two visibility API behaviors were checked on 8 October 2026 using Cafe CLI 0.6.0 and direct HTTP requests with the same stored credential:

1. Mirror-specific HTTP 401: reproduced, but not confirmed as a permissions defect. The credential is accepted for a standalone repository. The failure is associated with the GitHub-mirrored repository's authorization path and may reflect additional provider authorization requirements.
2. Version-boundary HTTP 500: reproduced directly at the server. An expectedVersion explicitly allowed by the live OpenAPI schema causes an internal server error rather than a normal rejection.

The original Bun executable lookup failure was an error in my transfer script. Different local branches and tags were normal Git history differences. Neither is evidence of a git.cafe defect.

Mirror authorization finding

The same bearer credential produced these responses:

Both repositories had configuration version 0 before and after the probes. The standalone control remained private; the original mirror remained public. These requests used a nonmatching version so they could not perform the requested settings change under the API's version fence.

The mirrored-repository 401 was reproduced at 18:40:19 UTC through direct HTTP, bypassing the Cafe CLI. The response was:

The stored device grant includes repository metadata-write and administration capabilities with all-resource selectors. Other authenticated repository reads and the issue update work with this credential.

GET /api/repos/screen/portfolio.site/github/status reports an active mirror, authorization: current, and renewalSuggested: false. It also reports one blocked pull job with authority-changed and import state needs-attention. The API reports no mirror for screen/portfolio.site-private.

Interpretation and remaining question

The visibility documentation requires renewable GitHub authorization for a connected mirror. The live API separately marks /api/github/status and /api/github/repositories/verify as browser-session-only; device grants cannot satisfy those endpoints. Calling /api/github/status with the CLI credential returns HTTP 401 as documented.

That supports a provider/session authorization explanation, but does not prove which check the visibility handler performs. The visibility endpoint itself advertises bearer authentication and repository metadata-write requirements, subject to resource policy.

Please determine whether this mirror's visibility operation legitimately requires browser-linked provider authority. If it does, document the CLI limitation and return an actionable explanation rather than the generic suggestion to run cafe auth login again. If bearer access should support this operation, investigate the mirror-specific authorization rejection.

This report does not establish an expired GitCafe token or a general CLI authentication failure. A browser-session comparison and server authorization logs were not available in this investigation.

Confirmed version-boundary server error

The live OpenAPI schema defines expectedVersion as an integer from 0 through 9007199254740991. On the standalone private control at version 0, this request returned HTTP 500 both through the raw CLI API command and through direct bearer-authenticated HTTP:

The direct response at 18:41:21 UTC was:

Using expectedVersion: 1 with the same repository, credential, and requested visibility returns HTTP 409 instead. The control stayed private at version 0 after both probes.

Expected: reject a nonmatching version normally. If the backend supports a smaller numeric range, the schema and request validation should enforce that range and return a validation response instead of HTTP 500. The underlying server exception is not known.

Transfer state and resolved local findings

• The public screen/portfolio.site received no Git push during the transfer and remains on hold until the user makes it private.
• A separate private copy, screen/portfolio.site-private, had already been created and uploaded before the hold instruction arrived.
• The other 13 matching repositories were verified against GitHub's latest branches and tags. Uncommitted files remained local.
• spawnSync bun ENOENT was fixed by invoking the installed bun.exe by its full path.
• Three local Col branch histories and one PocketCLI tag were preserved under separate names instead of overwriting another version.
• No Git pushes, visibility changes, mirror renewals, or GitHub reconnections were performed during this investigation. Readback confirmed unchanged visibility and configuration versions for both probed repositories.

Issue #1 concerns an earlier HTTPS Git credential-helper setup problem. It is not an established cause of either visibility API behavior above.