# Visibility API: mirror-specific HTTP 401 and allowed version-boundary HTTP 500 · Issue \#2 · screen/git-cafe-https-push-findings

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

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

Visibility: public

State: triage

Priority: 0

## Description

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

| Request | Result |
| --- | --- |
| `GET /api/auth/identity` | HTTP 200, identity `screen` |
| `GET /api/repos/screen/portfolio.site/settings` | HTTP 200 |
| `PUT /api/repos/screen/portfolio.site-private/settings/visibility`, stale version `1`, visibility `private` | HTTP 409, normal version/authority rejection |
| `PUT /api/repos/screen/portfolio.site/settings/visibility`, stale version `1`, visibility `private` | HTTP 401, credentials-required response |

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:

```json
{"type":"https://cafe.sh/errors/authentication-required","title":"Authentication required","status":401,"detail":"Valid credentials are required for this operation."}
```

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](https://git.cafe/docs/repositories/repository-danger-zone.md) 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](https://git.cafe/api/openapi/json) 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:

```http
PUT /api/repos/screen/portfolio.site-private/settings/visibility
Content-Type: application/json
Authorization: Bearer <redacted>

{"expectedVersion":9007199254740991,"visibility":"private"}
```

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

```json
{"type":"https://cafe.sh/errors/internal-error","title":"Internal server error","status":500,"detail":"The request could not be completed."}
```

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](https://git.cafe/screen/git-cafe-https-push-findings/issues/1) concerns an earlier HTTPS Git credential-helper setup problem. It is not an established cause of either visibility API behavior above.