[omartelo]

Why

gh keeps one active account per host, globally. On a machine signed in as two GitHub accounts, a private repository only the second one can see answers every lookup with:

gh pr view: GraphQL: Could not resolve to a Repository with the name 'acme/private'. (repository)

GitHub does not distinguish 404 from 403, so the message reads as "this repository does not exist" — and lich pasted it on screen verbatim, command prefix and all. The screen looked broken on a repository that was fine.

What this does

A project names the GitHub account its calls run as. vcs.account in the store (project-scoped — gh already has a global answer, and this exists to override it for one repository), resolved to a token via gh auth token --user <login> and passed to gh in GH_TOKEN. Every gh call routes through one seam (Service.gh), so the badge, the list, the detail, the checks, the diff, the merge and the PR checkout all answer as the same account. Unset, nothing changes.

A checkout is addressed by path everywhere in the project services, so the path → project mapping is resolved in the store: the project's own directory, or a session's (a worktree lives outside the project directory, so only its session row ties it back). No RPC signature changed.

A new Version Control section in Settings picks the account, filled from gh auth status.

The badge was shelling out to gh on its own, outside the seam — it would have kept answering as gh's active account while the screen beside it used the project's, vanishing on exactly the repositories the picker exists for. It takes the same path now.

Neither tool's stderr reaches the screen anymore. gherror.go and giterror.go each hold a table of the failures lich can actually hit; toolerror.go holds what they share. gh's GraphQL envelopes, git's fatal: lines, and — when git refuses by exit status alone (check-ref-format) — the literal words exit status 1 are replaced by a sentence that says what to do. The raw text goes to lich's log, which is where it was always the more useful half.

the tool said	the screen says
GraphQL: Could not resolve to a Repository with the name '…'	GitHub does not show this repository to the account lich is using here. Choose the account that can see it in Settings → Version Control.
To get started with GitHub CLI, please run: gh auth login	gh is not signed in to GitHub. Run gh auth login in a terminal.
git check-ref-format: exit status 1	"has space" is not a name git accepts for a branch.
fatal: '…' contains modified or untracked files, use --force to delete it	That worktree has uncommitted changes. Remove it from the sidebar to discard them.

Approving a pull request no longer means opening the browser. An Approve button sits beside Merge and files the approving review through the project's account. Once it lands the button reads Approved and stops offering itself — GitHub would take a second review, but nobody means to send one. The gate is not the merge gate: a draft and a conflicting pull request can both still be reviewed, only one already merged or closed cannot. Reviews with a body and requesting changes are deliberately absent — a review comment belongs to the line it is about, and lich has nowhere to attach one yet.

Ceiling

The account governs what lich reads from GitHub, not what git does: a push still rides the remote's ssh key and signs with the global user.email, so a PR can be read by one account and its commits land under another with no error anywhere. Documented as a Known Ceiling; per-worktree core.sshCommand + user.email is the upgrade path.

Test plan

• End-to-end against the real repository that produced the bug, driven over the RPC on an isolated instance: before — Could not resolve to a Repository; after setting the account — the list of open PRs.
• project.GitHubAccounts against the real gh auth status returns ["omartelo", "marcelo-filho_snk"].
• Every git failure path exercised over the RPC against real git (invalid name, taken name, non-repository, unknown worktree) — each answers with its sentence, and the raw stderr is in the log.
• Settings pane smoked in headless Chromium (the frontend gate is node-only and cannot render): the section renders, the picker opens with gh's active account + both logins, the stored value is selected, no page errors.
• TestGHMessageLeaksNothing / TestGitMessageLeaksNothing assert the rule, not just the cases: no message may contain graphql, http 4xx, exit status, fatal:, hint:, --force.
• TestRunGitMessage runs real git against a non-repository and asserts the sentence — the whole path, not just the table.
• go test ./..., gofmt -l ., go vet ./... clean; frontend biome check (0 errors), vitest 468 passed, tsc --noEmit clean, vite build ok.
• Cross-compile loop for linux/darwin/windows (build + vet).
• Open in Session was the bug homologation found: gh pr checkout runs inside the worktree it just created, which has no session row yet, so the account resolved to none and the checkout fell back to gh's active one. Fixed by separating "where the command runs" from "whose account it runs as" (ghFor); the regression test fails without the fix with token "".
• Approve verified by hand in the dev instance, and its one real refusal was triggered against this very PR to read GitHub's exact wording: Review Can not approve your own pull request.
• Merge failures were exercised through their message table, not against a live refusal from GitHub.

Five backend tests changed: they asserted the command prefix and the tool's own words, which is precisely what leaked. Each now asserts the message passes through unchanged.

🤖 Generated with Claude Code