[bug] "No github access for X" blames authorization for an unknown owner, and calls a permanent failure transient

[serge-ivo]

Split out of #320, where it was a comment. Different subsystem, different fix — and a fix for
#320 would leave this reachable.

Observed

Coder Lead, 2026-08-06 22:36:

❌ github_list_issues  Couldn't reach GitHub for "fws" (No github access for "fws".).
                       This is usually transient — try again. If it kee…

The agent concluded, reasonably:

You may need to re-authorize the ProAgentStore GitHub App for that repo.

Access was fine. Calling the same tool with the real coordinates —
freewebstore-online/platform — returns 30 open issues. The App is installed and working. The
caller had simply passed "fws", a display name that is not a GitHub owner.

Both halves of the message point at the wrong thing

• "No github access for X" describes an authorization failure. The actual condition is X is not
  an owner we could ever have an installation for. A user following this goes and re-authorizes an
  App that is already correctly installed — real time spent on a non-problem.
• "This is usually transient — try again" is false for this cause. Retrying an unknown owner
  fails identically, forever. The hint recommends precisely the loop it should prevent.

Same shape as #271, where a 409 appended "(and run pags up)" unconditionally and sent a user
chasing a runner that was already up, and as #259, where the supervisor inferred "no runner" from a
signal that did not mean that. An error naming the wrong remedy is worse than a terse one, because
it is confidently actionable in the wrong direction.

Fix

Distinguish the causes where the token is minted (lib/github-app.ts, installationTokenForOwner):

condition	message
known owner, no installation	"the ProAgentStore GitHub App is not installed on <owner>" + install URL — the current wording, correct here only
owner unknown / not an owner	"<owner> is not a GitHub owner" + the repo's real github_repo if the caller has one
genuine transient (5xx, timeout)	keep "try again" — and only then

Only the third is transient, so only the third should say so.

Why separately from #320

#320's third point ships githubRepo in subordinate_status, which stops this caller passing a
bad owner. It does not touch the message, so any other caller with a wrong owner gets the same
misdirection — and someone closing #320 having done the supervision work would reasonably consider
it finished.

That is not hypothetical: #257 was closed after its history half shipped while the session-lifecycle
half, raised in a comment, became untracked and needed re-filing as #271. Same failure mode, so:
its own ticket.

[serge-ivo]

Fixed in 99bf6d8.

The connector's reasoning was the bug: "a retryable fault names itself; 'not installed' does not fail, it returns nothing." False — connectorClient.token() throws for every failure, so the permanent conditions inherited the transient branch's "try again", and the message they carried (No github access for "X") named authorization for an owner that had never been resolved.

lib/github-app.ts now classifies what it was collapsing, with retryable as a field rather than an inference:

state	condition	retryable
app-not-configured	no GITHUB_APP_ID/PRIVATE_KEY, or GitHub refusing the App's own credentials (401/403 on the App JWT)	no — "nothing in your own settings changes this"
owner-unknown	404 on /users/<owner> — "fws" is not a GitHub account	no — "This is not an authorization problem — the owner passed is wrong", + "use repo.githubRepo, not repo.name", + "retrying with the same value will fail identically"
not-installed	a real owner, App not installed	no — the install URL
not-authorized	installed, but this user has no verified binding	no — "Connect GitHub in Settings"
transient	5xx/network/timeout, or a bound installation whose mint fails now	yes — the only one that says "try again"

A test asserts /try again/ appears in exactly the states whose retryable is true, and that the four non-installation states never say "Install".

The existence probe runs only on the failure path, and only under diagnose: true — the connector opts in; installationTokenForOwner, whose callers treat "no token" as "clone it publicly", does not pay two extra GitHub calls for prose nobody reads. When GitHub will not say whether the owner exists, it reports not-installed and does not claim the owner is unknown.

The IDOR guard is untouched: tokens still mint only for a binding authorizeInstallation created. What changed is what the absence of one is called.

github.ts no longer guesses — it branches on the status the minter set (502 = the one retryable state), relays a permanent message verbatim, and a one-part repo ("fws") now points at repo.githubRepo instead of at authorization.