Pathbase sharing is unusable in practice, and the failure degrades to anonymous upload rather than failing closed

[bdelanghe]

Observed 2026-08-13 in a front-desk cloud session (working drift-gate#17). Filing the consumer-side half; the detection half is #155's and I nearly commented there instead — see "Relationship to existing issues" below.

What happened

setup-toolpath.sh reported at SessionStart:

toolpath: Pathbase lease minted a code but the REDEEM failed — sharing will be
anonymous. Vendor redeem endpoint unreachable or code rejected (.github#119).
toolpath: installing path-cli in the background

The install itself succeeded (path 0.16.1, ~4 min). No credentials file was written. So the session ran to completion — merged a PR, filed two issues — and when the maintainer asked for its Pathbase link at the end, there was none to give, and no way to produce one except an anonymous upload.

This is the same fault #155 recorded on 2026-08-11 (pathbase.dev blocked at CONNECT, infra#283). Still failing two days later, and still detected only by a human happening to read a session-start line.

The part that is not already filed: the fallback direction is wrong

#119 was explicit about the broker side:

Fail closed if a mint-mode entry gets a non-200 from request-grant — a failed mint is anonymous sharing, not a fallback to releasing the master credential.

The consumer side does the opposite. When the redeem fails, setup-toolpath.sh does not fail closed — it announces that sharing will be anonymous and carries on. path share remains runnable, and --anon is a first-class flag on the stock CLI.

Why that matters more than it looks:

• A session's transcript is not scoped to public repos. This one read .github-private throughout — injected org context, internal docs, a full private issue body — because that is the normal front-desk working set (claude/session-repos.json attaches it by intent).
• An anonymous upload lands under no account. There is no DELETE /api/v1/auth/sessions/{id} for it and nothing to revoke — the per-session revocability that was the whole point of the PREREQUISITE for lease go-live: mint short-lived grant codes instead of vaulting the Pathbase pat #119 mint ratchet is exactly what the failure path discards.
• Uploads are unlisted-by-UUID rather than public, which bounds this, but unlisted is not private and a UUID in a PR body is not a secret.

So the degraded mode converts an auth failure into a potential disclosure of private-repo material with no revocation path. The safe degradation is no sharing, not unattributable sharing.

I did not run path share — I asked the maintainer first, precisely because of the above. But nothing in the tooling would have stopped me, and a session with a shorter fuse would have shipped a link.

What is being asked for

Per the maintainer: "we should have the creds or be able to rotate them."

1. Have them — the lease should actually complete in a session. Today it cannot, because the redeem leg is blocked at the session egress boundary (infra#283). That is an environment-owner lever, not something a session can repair.
2. Rotate them — a rotation path that does not depend on noticing breakage by eye. I2: make the Pathbase lease lane the first enforced synthetic exercise #155 already argues rotation should be event-driven (on exposure) rather than calendar-driven, conditional on a synthetic exercise existing. That reasoning looks right and this issue does not reopen it; it just notes that with neither the exercise nor a working lane, there is currently no cadence at all.

Suggested, smallest first

• Make the consumer fail closed. When the redeem fails, say sharing is unavailable rather than anonymous, and do not leave --anon as the path of least resistance for a session holding private-repo context. Cheapest change here, and independent of the egress fix.
• Unblock the redeem leg (infra#283) so a session can hold its own token — the "have the creds" half.
• Land I2: make the Pathbase lease lane the first enforced synthetic exercise #155's CI leg so this stops being detected by a human reading a line. Note I2: make the Pathbase lease lane the first enforced synthetic exercise #155's own point: the CI leg would not have caught this fault, since a runner sits outside session egress. Both legs are needed and they attest to different things.
• Decide whether anonymous sharing should exist at all for sessions with private repos attached, or be gated behind an explicit opt-in per share.

Relationship to existing issues

Deliberately not duplicating:

• Close the Pathbase auth gap: broker-family lease vs stored-session secret vs upstream token flag #115 — the auth gap and lease design. Open, still the parent.
• PREREQUISITE for lease go-live: mint short-lived grant codes instead of vaulting the Pathbase pat #119 — the mint ratchet. Closed/completed; this issue reports its consumer-side fail direction not matching the broker-side rule it set.
• I2: make the Pathbase lease lane the first enforced synthetic exercise #155 — the synthetic exercise, and the rotation-cadence reasoning. Owns the detection half. This issue is the "what the user hits when it is broken" half plus the fallback-direction bug.
• infra#283 — the blocked leg (outside my repo scope this session; not verified first-hand beyond reproducing the symptom).

If maintainers would rather this were a comment on #155, it collapses cleanly into one — the only genuinely separable item is the fail-closed change.

Not verified here

I confirmed the symptom (no credentials file, hook's own message) and read setup-toolpath.sh. I did not probe the broker, test request-grant, or confirm the current state of PATHBASE_PAT — all outside what I had in front of me, and guessing at them is how the boundary mistake in .github-private#417 happened. The "still failing on 2026-08-13" claim rests on the hook's message alone.