Pre-submission checks
zizmor version
1.23.1
Expected behavior
Running zizmor against a workflow that references a pinned public action completes the audit, regardless of whether GH_TOKEN happens to be accepted by github.com. A 401 on a supplementary tag lookup in artipacked should not take down the entire run.
Actual behavior
Any GH_TOKEN that github.com rejects (invalid, expired, or scoped to a different GitHub Enterprise Server) causes artipacked to crash with a 401 before any other audit can emit findings. The end result is fatal: no audit was performed — zero findings across every audit in the run.
Neither of the obvious knobs fixes it:
--no-online-audits doesn't cover artipacked — it's treated as a static audit even though it does a git ls-remote against github.com internally.
--gh-hostname / GH_HOST doesn't help either — it only rewrites REST API URLs, not the hardcoded https://github.com/<owner>/<repo>.git git-protocol URL used by this audit, so pointing it at a GHES host just swaps one 401 for another.
The only way to make a run complete is --offline (which also disables genuinely useful online audits like impostor-commit) or unset GH_TOKEN before invoking zizmor.
Reproduction steps
-
Save this as wf.yml:
name: repro
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
-
Run zizmor with any GH_TOKEN github.com won't accept:
GH_TOKEN=ghs_invalid uvx zizmor wf.yml
-
Observe the crash below. Running the same command with unset GH_TOKEN first passes cleanly via anonymous github.com access.
Logs
🌈 zizmor v1.23.1
fatal: no audit was performed
'artipacked' audit failed on file://wf.yml
Caused by:
0: error in 'artipacked' audit
1: couldn't list tags for actions/checkout
2: request error while accessing GitHub API
3: HTTP status client error (401 Unauthorized) for url (https://github.com/actions/checkout.git/git-upload-pack)
Additional context
Hit this on a self-hosted GitHub Enterprise Server runner, where the auto-injected GITHUB_TOKEN is GHES-scoped and github.com naturally rejects it. zizmorcore/[email protected] has no way to suppress the inherited token or pass --offline, so there's no supported configuration of the action that finishes a run on a GHES runner — had to stop using the action and call uvx zizmor from a run: step with unset GH_TOKEN GITHUB_TOKEN before it.
Disclaimer
I used Claude to help write this issue based on its investigation work.
Pre-submission checks
zizmor version
1.23.1
Expected behavior
Running zizmor against a workflow that references a pinned public action completes the audit, regardless of whether
GH_TOKENhappens to be accepted by github.com. A 401 on a supplementary tag lookup inartipackedshould not take down the entire run.Actual behavior
Any
GH_TOKENthat github.com rejects (invalid, expired, or scoped to a different GitHub Enterprise Server) causesartipackedto crash with a 401 before any other audit can emit findings. The end result isfatal: no audit was performed— zero findings across every audit in the run.Neither of the obvious knobs fixes it:
--no-online-auditsdoesn't coverartipacked— it's treated as a static audit even though it does agit ls-remoteagainst github.com internally.--gh-hostname/GH_HOSTdoesn't help either — it only rewrites REST API URLs, not the hardcodedhttps://github.com/<owner>/<repo>.gitgit-protocol URL used by this audit, so pointing it at a GHES host just swaps one 401 for another.The only way to make a run complete is
--offline(which also disables genuinely useful online audits likeimpostor-commit) orunset GH_TOKENbefore invoking zizmor.Reproduction steps
Save this as
wf.yml:Run zizmor with any
GH_TOKENgithub.com won't accept:Observe the crash below. Running the same command with
unset GH_TOKENfirst passes cleanly via anonymous github.com access.Logs
Additional context
Hit this on a self-hosted GitHub Enterprise Server runner, where the auto-injected
GITHUB_TOKENis GHES-scoped and github.com naturally rejects it.zizmorcore/[email protected]has no way to suppress the inherited token or pass--offline, so there's no supported configuration of the action that finishes a run on a GHES runner — had to stop using the action and calluvx zizmorfrom arun:step withunset GH_TOKEN GITHUB_TOKENbefore it.Disclaimer
I used Claude to help write this issue based on its investigation work.