bug: gh commands in a clone of this fork target block/buzz unless a default repo is set

[serina-mcfall]

Security check

• This is not a security vulnerability. I understand vulnerabilities go to a private advisory, not a public issue.

No credential or exposure is involved. It is a wrong-target defect: commands aimed at this fork
land on block/buzz instead.

Observed behaviour

This repository is a GitHub fork of block/buzz. In a fresh clone, gh resolves pull request
and issue operations to the parent repository, so any command without an explicit --repo
targets upstream rather than this fork. Measured 2026-08-12 on a clone with both remotes
(origin → launchpad-26/buzz, upstream → block/buzz).

No default was set:

$ gh repo set-default --view
X No default remote repository has been set. To learn more about the default repository, run: gh repo set-default --help

A read aimed at an issue that exists here failed, because it was not looking here — issue #116
is open in this repository:

$ gh issue view 116
GraphQL: Could not resolve to an Issue with the number of 116. (repository.issue)

And a write named the wrong repository outright. This is the clearest evidence: it reports
block/buzz#124, not launchpad-26/buzz#124:

$ gh pr ready 124
X Pull request block/buzz#124 is closed. Only draft pull requests can be marked as "ready for review"

That command was intended for this fork's PR #124, which was open and in draft at the time. It
reached upstream's PR #124 — a different, closed pull request that has nothing to do with this
fork — and only failed because that PR happens to be closed.

Expected behaviour

A command run inside a clone of this repository should act on this repository. Contributors
should not have to remember --repo launchpad-26/buzz on every invocation, because the one
they forget is the one that goes to the wrong place.

The fix is one command per clone, and it is not something the repository can carry for you —
it writes to local git config, not to a tracked file:

gh repo set-default launchpad-26/buzz

It belongs in the setup instructions alongside cloning, in launchpad/README.md and
launchpad/AGENTS.md §6 where the gh pr create examples live.

Worth knowing, because it makes the fix cheaper than it looks: the setting lands in the
shared .git/config as remote.origin.gh-resolved, and git worktrees share that file unless
extensions.worktreeConfig is set — which it is not here. So one invocation fixes the clone
and every worktree hanging off it, not one worktree at a time.

Reproduction

1. Clone this fork and add upstream: git remote add upstream git@github.com:block/buzz.git
2. Do not run gh repo set-default.
3. Run gh repo set-default --view. Observe that no default is set.
4. Run gh issue view 116 with no --repo. Observe the GraphQL resolution failure, despite
   issue task: deterministic pre-flight for the PR review agent #116 being open in this repository.
5. Run gh pr view 12 with no --repo. Observe that it returns upstream's PR chore: sync launchpad with upstream block/buzz main (64 commits) #12, not this
   fork's.
6. Run gh repo set-default launchpad-26/buzz, then repeat step 4. It now resolves.

Environment

gh 2.93.0 on Linux 6.6.87.2-microsoft-standard-WSL2. Clone at
/home/serina/Launchpad/buzz with origin → launchpad-26/buzz and upstream →
block/buzz. Measured 2026-08-12. extensions.worktreeConfig unset.

Impacted components

launchpad/README.md      setup steps — add the one-time gh repo set-default
launchpad/AGENTS.md      §6, where the gh pr create examples live

Why this is worth an issue rather than folklore

The failure mode is a wrong write, not an error. Steps 4 and 5 fail loudly and merely waste
time. The dangerous version is a command that succeeds: gh issue create and gh pr comment
resolve through the same base-repository path, so a cohort process issue — or a comment
containing our internal discussion — can be filed into upstream's public tracker by
someone who simply forgot a flag. Undoing that means deleting content from a repository we do
not own, after it has already been emailed to upstream's watchers.

Agents are more exposed than people here, not less. launchpad/AGENTS.md instructs agents to
create issues and PRs with gh, and an agent that builds a command programmatically and omits
--repo gets no warning at all — it just posts somewhere else. I hit exactly this twice in one
session while working on #116.

Passing --repo everywhere is not a sufficient answer. It works, but it is a habit rather
than a setting, and some local tooling refuses commands that target a repository by name
precisely because a name cannot be verified against the checkout it was run from. That leaves
set-default as the only path that is both safe and always available.

Related: #85, which is the same class — a gh behaviour that does not match what
launchpad/AGENTS.md tells contributors to type.

Not verified

• I did not test whether gh issue create or gh pr comment actually writes to upstream,
  and I will not: the only honest test would create real content in block/buzz. The claim
  rests on those commands using the same base-repository resolution as the two failures
  measured above, not on an observed write.
• I did not check whether a clone with no upstream remote is affected. It may resolve
  correctly, which would mean this only bites contributors who added upstream in order to sync.
• I did not check gh versions other than 2.93.0, or whether a newer version changed the
  default-resolution behaviour for forks.
• I did not audit which other cohort scripts invoke gh without --repo.
• I did not verify how this interacts with GH_REPO if someone sets it in their environment.