Claude Code on Not That Kind of Agent

Hardening GitHub Actions workflows against supply chain attacks

Wed, 13 May 2026 00:00:00 -0700

I asked Claude Code to review the GitHub Actions workflows in this repo for supply chain attack risk. This post covers what it found, what we changed, and a prompt you can reuse on your own workflows.

The threat model

A supply chain attack via GitHub Actions works like this: a third-party action you depend on (say, some-org/some-action@v2) gets its tag force-pushed with malicious code. On your next workflow run, that code executes in your CI environment. It has access to your secrets and token permissions.

The same risk applies to npm. If a package in your node_modules tree is compromised, its postinstall script runs during npm ci. It can read any credentials in the job environment.

Neither is theoretical. Both attack types have hit real CI pipelines.

What I changed

1. Pin third-party actions to commit SHAs

GitHub’s version tags (e.g., @v2, @v8) are mutable. A tag can be moved to point to a different commit without notice. Pinning to a commit SHA means the code you reviewed is the code that runs, forever.

Immutable vs mutable

Git tags are just labels. The v8 tag is a pointer, and whoever controls the repo can move it to a different commit. Same name, different code. That’s what mutable means here.

A commit SHA is different. Git derives it from the content of the commit, so it can only refer to that one thing. You can’t redirect it.

That’s what makes SHA pinning an actual security control. Once you’ve reviewed what’s at a given SHA, nobody can swap something else in without you noticing.

I was using two third-party actions:

1
2
3
4
5
6
7


# Before
uses: peter-evans/create-pull-request@v8
uses: errata-ai/vale-action@v2

# After
uses: peter-evans/create-pull-request@5f6978faf089d4d20b00c7766989d076bb2fc7f1 # v8
uses: errata-ai/vale-action@d89dee975228ae261d22c15adcd03578634d429c # v2

The # v8 comment keeps it human-readable. To get the SHA for a tag:

1

gh api repos/peter-evans/create-pull-request/git/ref/tags/v8 --jq '.object.sha'

GitHub’s own first-party actions/* are lower risk, but if your threat model requires it, the same pinning applies.

2. Add explicit `permissions` blocks

Without an explicit permissions block, a workflow job inherits the repository’s default token permissions, which can be read/write depending on repo settings. Declaring minimum permissions limits what an attacker can do with a compromised token. This is the security principle of “least privilege.”

Three of my workflow files had no permissions block at all:

1
2
3


# Added to lint.yml, security.yml, vale.yml
permissions:
 contents: read

The deploy.yml and update-theme.yml workflows were already scoped correctly. deploy.yml needs pages: write and id-token: write for GitHub Pages deployment. update-theme.yml needs contents: write and pull-requests: write to create automated PRs.

3. Set `persist-credentials: false` on checkouts that don’t need to push

By default, actions/checkout writes the GITHUB_TOKEN into .git/config where it stays accessible to every subsequent step in the job. That includes npm ci, which runs third-party postinstall scripts.

For jobs that check out code but never push (linting, security scanning, prose review), there’s no reason for the credential to persist:

1
2
3


- uses: actions/checkout@v6
 with:
 persist-credentials: false

I applied this to lint.yml, security.yml, and vale.yml. The deploy.yml and update-theme.yml workflows keep the default because they run git operations that need authentication.

4. Add `timeout-minutes` to every job

Jobs without a timeout run for up to 6 hours by default. That’s a long window of live token exposure if something goes wrong. Tight timeouts also limit the damage from a hung or hijacked job.

1
2
3
4


jobs:
 lint:
 runs-on: ubuntu-latest
 timeout-minutes: 5

Each of these jobs completes in seconds, with the build and deploy pipeline taking under two minutes. I set all jobs to 5 minutes. That’s a reasonable buffer given actual run times, and a lot better than leaving the 6-hour default in place.

The prompt

Here’s the prompt I used. It works well with Claude Code in a repo with workflow files present:

Review the GitHub Actions workflows in .github/workflows/ for supply chain attack risk. For each workflow file, check:

Action pinning — Are any third-party actions (non-actions/*) pinned to a mutable version tag instead of a commit SHA? If so, fetch the current SHA for each tag using gh api repos/<owner>/<repo>/git/ref/tags/<tag> and pin them. Add the version tag as a comment for readability.

Permissions — Does every job have an explicit permissions block declaring the minimum required scopes? If not, add one. Jobs that only read code should use permissions: contents: read. Note which jobs legitimately need write scopes and why.

persist-credentials — Does actions/checkout default to persisting the GITHUB_TOKEN into .git/config? For any job that does not need to git push, add persist-credentials: false to the checkout step. This prevents the token from being readable by npm postinstall scripts or other downstream steps.

Timeouts — Does every job have a timeout-minutes value set? If not, add one. Base the value on a realistic upper bound for that job’s expected runtime.

For each finding, explain the risk and make the change. Do not pin GitHub’s own first-party actions/* actions unless I ask — focus on third-party dependencies.

Run this against a repo with a clean working tree. The diff lands in one place, which makes it easier to spot anything unexpected before you commit.

What this doesn’t cover

This review focuses on the workflow files themselves. It doesn’t cover:

Repository secrets — if you have a personal access token (PAT) with broad org-wide scope stored as a repo secret, that’s a higher-impact risk than anything in the workflow YAML. Audit your repo and org secrets separately.
pull_request_target — workflows using this trigger run with write permissions even for PRs from forks, which can give fork contributors unintended write access to your repo. None of my workflows use it, but it’s worth checking yours.
Dependabot for Actions — automatically opens PRs to bump action versions. Pairing it with SHA pinning requires extra config but keeps pinned SHAs from going stale.

Fixing error: GitHub Actions isn't allowed to open pull requests

Wed, 06 May 2026 00:00:00 -0700

In my last post, I updated the update-theme workflow to open a pull request instead of committing theme updates directly to main. Smart in theory. In practice, when the workflow needed to open a pull request to bump the hugo version, it failed. The workflow run also warned me about Node 20 actions being deprecated.

I used Claude Code to help diagnose and work through both issues. This post is my note-to-future-self on what needed to change and where.

Problem 1: GitHub Actions isn’t allowed to open pull requests

The workflow failed with this error from the GitHub REST API:

GitHub Actions is not permitted to create or approve pull requests.

The peter-evans/create-pull-request action uses the built-in GITHUB_TOKEN to open PRs. The workflow already had the right permissions declared:

1
2
3


permissions:
 contents: write
 pull-requests: write

But there are two separate settings in the repository that also need to be enabled, and both were off by default.

Setting 1: Actions allowlist

Go to Settings → Actions → General and look at the “Actions permissions” section. If you’re using the “Allow [org], and select non-[org], actions and reusable workflows” option, you need to explicitly list the third-party actions your workflows use in the allowlist field.

Here’s what I added:

1
2
3


peaceiris/actions-hugo@*,
peter-evans/create-pull-request@*,
errata-ai/vale-action@*

The @* wildcard covers any version tag, so this doesn’t need updating when action versions get bumped. GitHub’s own actions (actions/checkout, actions/setup-node, etc.) are covered separately by checking “Allow actions created by GitHub”.

Setting 2: Workflow permissions

Further down on the same Settings → Actions → General page is the “Workflow permissions” section. There’s a checkbox labeled “Allow GitHub Actions to create and approve pull requests” that is unchecked by default. Check it.

This is a separate gate from the permissions: block in the workflow YAML. Even with pull-requests: write in the workflow, the GITHUB_TOKEN cannot open PRs unless this repo-level setting is also enabled.

After enabling both, the workflow ran successfully and opened its first PR.

Problem 2: Node.js 20 deprecation warnings

With the workflow actually running, a new batch of warnings appeared:

Node.js 20 actions are deprecated. The following actions are running on Node.js 20 and may not work as expected: actions/checkout@v4, peaceiris/actions-hugo@v3, peter-evans/create-pull-request@v7. Actions will be forced to run with Node.js 24 by default starting June 2nd, 2026.

Node.js 20 reached end-of-life in April 2026. GitHub Actions is forcing a cutover to Node.js 24 on June 2nd, and removing Node.js 20 from runners entirely on September 16th.

This affected every workflow in the repo, not just update-theme. Claude Code helped me audit all five workflows and figure out what could be upgraded versus what needed a workaround.

Action version bumps

Several actions had new major versions available with Node.js 24 support.

Cross-workflow updates (applied to all five workflow files where used):

Action	Before	After
`actions/checkout`	v4 / v5	v6
`actions/setup-node`	v4	v6
`peter-evans/create-pull-request`	v7	v8

deploy.yml-specific updates:

Action	Before	After
`actions/setup-go`	v5	v6
`actions/configure-pages`	v5	v6
`actions/cache`	v4	v5
`actions/upload-pages-artifact`	v3	v5
`actions/deploy-pages`	v4	v5

Actions that don’t have a Node.js 24 release yet

One action was already at its latest major version with no Node.js 24-compatible release available:

errata-ai/vale-action@v2 (used in vale.yml)

For it, I added the opt-in environment variable to the affected job:

1
2


env:
 FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true

This tells the runner to use Node.js 24 for that action now, before GitHub forces it on June 2nd. If it breaks, that’s a signal to find an alternative or wait for an upstream update.

peaceiris/actions-hugo@v3 was in the same situation — no Node.js 24 release, same warning — but I replaced it entirely rather than applying the workaround. See below.

Replacing peaceiris/actions-hugo

peaceiris/actions-hugo@v3 is an unmaintained community wrapper that downloads Hugo from GitHub releases and puts it on PATH. Since it has no Node.js 24-native release and is just a thin wrapper around a direct download, the right move was to remove the dependency and do the download directly — the same pattern already used for Dart Sass in deploy.yml.

In deploy.yml, where the Hugo version is pinned in an environment variable:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


- name: Setup Hugo
 run: |
 mkdir -p "${HOME}/.local/bin"
 curl -sLo "hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz" \
 "https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz"
 curl -sLo "hugo_checksums.txt" \
 "https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_checksums.txt"
 sha256sum --check --ignore-missing "hugo_checksums.txt"
 tar -C "${HOME}/.local/bin" -xf "hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz" hugo
 rm "hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz" "hugo_checksums.txt"
 echo "${HOME}/.local/bin" >> "${GITHUB_PATH}"

In update-theme.yml, where the workflow always wants the latest Hugo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


- name: Setup Hugo
 env:
 GH_TOKEN: ${{ github.token }}
 run: |
 HUGO_VERSION=$(gh release view --repo gohugoio/hugo --json tagName --jq '.tagName | ltrimstr("v")')
 mkdir -p "${HOME}/.local/bin"
 curl -sLo "hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz" \
 "https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz"
 curl -sLo "hugo_checksums.txt" \
 "https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_checksums.txt"
 sha256sum --check --ignore-missing "hugo_checksums.txt"
 tar -C "${HOME}/.local/bin" -xf "hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz" hugo
 rm "hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz" "hugo_checksums.txt"
 echo "${HOME}/.local/bin" >> "${GITHUB_PATH}"

The sha256sum --check --ignore-missing step verifies the tarball against Hugo’s published checksums file before extracting. --ignore-missing is needed because the checksums file covers all platforms and editions; we only downloaded one of them. This is something peaceiris/actions-hugo never did, so the replacement is actually a supply chain improvement over what it replaced.

Aligning the pinned Node.js version

While auditing the workflows, I noticed the pinned node-version values were inconsistent:

Workflow	Node version (before)
`deploy.yml`	`24.12.0`
`lint.yml`	`22`
`security.yml`	`20`

Node.js 22 is now in Maintenance LTS (its Active LTS phase ended October 2025). Node.js 24 is the current Active LTS and what deploy.yml was already using. I updated lint.yml and security.yml to '24' so all workflows are consistent.

The two things to remember

If you set up a GitHub Actions workflow that opens PRs and it fails with a permissions error, check both places:

Settings → Actions → General → Actions permissions — add third-party actions to the allowlist
Settings → Actions → General → Workflow permissions — enable “Allow GitHub Actions to create and approve pull requests”

The permissions: block in the workflow YAML is necessary but not sufficient on its own. You need the repo-level checkbox too. Future me: check there first.