What happens
When running a workflow (e.g. archon-fix-github-issue) for the first time against a private GitHub repo, the fetch-issue bash node fails with what looks like a 404. The actual error is the GitHub GraphQL message:
Could not resolve to a Repository with the name '<owner>/<repo>'.
Which GitHub returns when an unauthenticated request asks for a private repo (it hides existence from unauthed callers — indistinguishable from "doesn't exist").
Why
gh stores its OAuth token in the macOS Keychain (and equivalent on other OSes). Archon's bash nodes spawn in a subprocess that doesn't inherit the keyring session — so gh runs unauthenticated even though gh auth status from the user's interactive shell shows them as logged in.
Repro
- Fresh
gh install with gh auth login (OAuth flow).
- Create a private GitHub repo with at least one issue.
archon workflow run archon-fix-github-issue <issue#> from the repo's CWD.
- The fetch-issue node fails with the "Could not resolve" error.
The same gh issue view <issue#> command works fine from the user's interactive shell.
Workaround (verified 2026-04-28)
Append GITHUB_TOKEN and GH_TOKEN to ~/.archon/.env:
TOKEN=$(gh auth token)
{
echo "GITHUB_TOKEN=$TOKEN"
echo "GH_TOKEN=$TOKEN"
} >> ~/.archon/.env
chmod 0600 ~/.archon/.env
After this: clean end-to-end run, draft PR shipped in ~12 minutes.
Suggested fix
One of:
- Option A (in-workflow): have the bundled
fetch-issue (and any other bash node that calls gh) shell-source the user's gh token at the top: export GH_TOKEN=\${GH_TOKEN:-\$(gh auth token 2>/dev/null || true)} — picks up the keyring on demand without requiring .env edits.
- Option B (docs-only): add a README note that fresh installs against private repos need
GITHUB_TOKEN exported in ~/.archon/.env. Cheaper but leaves the silent-failure UX.
- Option C (CLI): detect the failure mode in
archon itself and print an actionable hint — currently the error surfaces as the raw GraphQL message.
Happy to PR Option A if you'd like the patch.
Environment
- macOS 14, zsh
- bun 1.3.13
- archon 0.3.9
- gh 2.91.0
What happens
When running a workflow (e.g.
archon-fix-github-issue) for the first time against a private GitHub repo, thefetch-issuebash node fails with what looks like a 404. The actual error is the GitHub GraphQL message:Which GitHub returns when an unauthenticated request asks for a private repo (it hides existence from unauthed callers — indistinguishable from "doesn't exist").
Why
ghstores its OAuth token in the macOS Keychain (and equivalent on other OSes). Archon's bash nodes spawn in a subprocess that doesn't inherit the keyring session — soghruns unauthenticated even thoughgh auth statusfrom the user's interactive shell shows them as logged in.Repro
ghinstall withgh auth login(OAuth flow).archon workflow run archon-fix-github-issue <issue#>from the repo's CWD.The same
gh issue view <issue#>command works fine from the user's interactive shell.Workaround (verified 2026-04-28)
Append
GITHUB_TOKENandGH_TOKENto~/.archon/.env:After this: clean end-to-end run, draft PR shipped in ~12 minutes.
Suggested fix
One of:
fetch-issue(and any other bash node that callsgh) shell-source the user's gh token at the top:export GH_TOKEN=\${GH_TOKEN:-\$(gh auth token 2>/dev/null || true)}— picks up the keyring on demand without requiring.envedits.GITHUB_TOKENexported in~/.archon/.env. Cheaper but leaves the silent-failure UX.archonitself and print an actionable hint — currently the error surfaces as the raw GraphQL message.Happy to PR Option A if you'd like the patch.
Environment