[Jammy2211]

Why

Remote sessions have no gh, and skills/GITHUB_ACCESS.md already maps every gh operation onto its MCP tool. But the pointer to that page lives only inside skill bodies. A chat that isn't running one of those skills never sees it — it reaches for gh, gets command not found, and rediscovers the problem from scratch. That is the "loads of chats complain they can't use gh" symptom.

What changed

AGENTS.md — a third bullet in the remote-sessions block, next to the pytest -n auto and session_bootstrap lines. That block is in every session's context, so the fact now lands before anyone types gh. Nothing in any auto-loaded AGENTS.md mentioned GitHub at all previously.

skills/GITHUB_ACCESS.md — a new section recording why installing gh is not the fix. The page already said "do not try to install gh"; it now carries the reason, which matters because any capable agent in these sessions is root with apt available and will otherwise just do it.

tests/test_gh_surface.py — the guard walked PyAutoBrain/skills only, so the one gh-driving skill body outside it (PyAutoMind's create_issue) went uncovered and drifted. It now walks PyAutoMind's skill root too, skipping that leg when the sibling isn't checked out — the convention test_hygiene_conductor.py already uses for repos.yaml. Pointer resolution checks both spellings: the relative markdown link a same-repo body uses, and the bare workspace path a cross-repo one needs.

Merge order: PyAutoMind#344 goes first

Correcting an earlier claim in this description that the two PRs were independent — they are not, and this PR's own first CI run is what proved it.

tests.yml checks PyAutoMind out pinned to main, deliberately ("this gate tests Brain against the CURRENT organism identity"). So the widened guard asserts against PyAutoMind's live main, which does not yet carry the create_issue pointer — that is in PyAutoLabs/PyAutoMind#344. The first run here failed with exactly that, which is the guard doing its job across repos rather than a defect:

AssertionError: these drive `gh` without telling a gh-less session what to do
instead — add a pointer to skills/GITHUB_ACCESS.md:
    PyAutoMind/skills/create_issue/SKILL.md
1 failed, 558 passed

Merge PyAutoMind#344, then re-run this PR's CI — no change needed here.

The measurement behind it

Installed gh 2.45.0 via apt in a remote session, exercised it, then removed it:

Call	Result
gh api user, gh api rate_limit	works
gh api repos/{owner}/{repo} (and /pulls, /issues, /actions/runs)	403 — "GitHub access is not enabled for this session"
gh pr list, gh issue list, gh repo view	403 — "This GraphQL query is not enabled for this session"
gh auth status	reports the token invalid (it is a proxy placeholder)

Two independent walls: REST repo paths aren't served, and GraphQL is pinned to a small set of PR-review operations — which is where most of gh's porcelain lives. The same repos work fine through mcp__github__*, which carries a different, repo-scoped credential. Because of the second wall, gh could not be a drop-in here even if an org admin connected the GitHub App.

An installed-but-403ing gh is worse than none: the binary looks healthy, so a run burns turns retrying instead of switching surface.

Testing

• python3 -m pytest -q -n auto — 559 passed locally (where both repos are checked out at this branch's state).
• The widened guard was verified by regression, not just by going green: removing create_issue's pointer, and typo'ing its path, each fail the suite with a repo-qualified path.
• python3 PyAutoMind/scripts/repos_sync.py drift check — OK (the generated tables in AGENTS.md are untouched).