Repository navigation
docs: installing gh also breaks the surface probe - #301
Merged
Merged
Conversation
The page told a run not to install `gh` on the grounds that the result would 403 — true, but it reads as an efficiency note, so an agent that is root with apt available can still talk itself into it. The sharper reason, measured: `gh auth status` exits 0 in a remote session even while printing "The token in GH_TOKEN is invalid", because the proxy-injected placeholder satisfies it. A session that installed `gh` then answers this page's own decide-once probe with `gh`, follows the commands as written, and walks into the 403s — the exact failure the probe exists to prevent. The probe is only honest while `gh` is absent. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NHQzyeUkEHqMmEZDo9zsNX
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #300, which is merged — this is a fresh branch off
main, not a reopen.Why
#300 recorded that an installed
gh403s on every repo-scoped call. True, but it reads as an efficiency note — "don't bother, it won't work" — and an agent in these sessions is root with apt available, so it can still talk itself into trying.The sharper reason turned up while verifying that #300 didn't break the local-CLI path.
gh auth statusexits 0 in a remote session even while printing:The
proxy-injectedplaceholder inGH_TOKENis enough to satisfy it. So the page's own decide-once probe —— answers
ghin a session that installed it. That run then reads the page's commands as commands and walks straight into the 403s: the exact failure the probe exists to prevent. The probe is only honest whileghis absent.That turns "do not install
gh" from advice about wasted effort into something load-bearing for the mechanism, which is what the page now says.What changed
One paragraph appended to the "Installing
ghdoes not work" section ofskills/GITHUB_ACCESS.md. Docs only.Testing
python3 -m pytest -q -n auto— 559 passed.ghinstalled, reproducing a laptop's condition, to confirm docs: put the GitHub-surface fact where every session already reads it #300 and this change leave theghsurface untouched: PyAutoBrain 559 passed, PyAutoMind 240 passed, and the probe correctly returnsghthere.Generated by Claude Code