repo-assist outdated lockfile required manual `gh aw compile` which removed action hash pins

[mlinksva]

I'm not sure whether this is 0, 1, or 2 bugs (or some other number!).

repo-assist started failing to run with:

Run details

Engine Configuration

Property	Value
Engine ID	copilot
Engine Name	GitHub Copilot CLI
Model	(default)

Network Configuration

Property	Value
Firewall	✅ Enabled
Firewall Version	v0.23.0

Allowed Domains

• defaults
• dotnet
• node
• python
• rust
• java

⚠️ Workflow Lock File Warning

WARNING: Lock file is outdated (frontmatter hash mismatch).

Files:

• Source: .github/workflows/repo-assist.md
  • Last commit: 2026-03-06T23:12:24.000Z
  • Commit SHA: 96618b6
  • Frontmatter hash: efd1eb6da9fd...
• Lock: .github/workflows/repo-assist.lock.yml
  • Last commit: 2026-03-02T03:15:28.000Z
  • Commit SHA: 3c15dd4
  • Stored hash: 5aed5f99021c...

Action Required: Run gh aw compile to regenerate the lock file.

I'm not sure whether this is intended, eg requiring recompile when repo-assit is updated, a bug, user error (perhaps I did something wrong setting up), or other.

When I did run gh aw compile I get uses: github/gh-aw/actions/setup@e422993ded9178a8a35804fbc44b1ca761513d15 # v0.51.4 replaced with uses: github/gh-aw/actions/setup@v0.51.4 which tools checking that all actions are pinned complain about:

I did notice the un-pinning before I committed the output of the recomplile but rather than re-pin myself I figured I'd get such a complaint and report it -- it's poissible the bug is not in gh aw compile but in Scorecard -- is the action immutable so pinning is superfluous or something?

Apologies for this somewhat messy issue, can't wait to see what the agents do with it. 😄

[dsyme]

@mlinksva THanks for the report!

Strange issue. cc @pelikhan . We should likely move to https://github.com/github/gh-aw

[pelikhan]

It's an old build. Could you try the latest release?

[pelikhan]

Is there a history changes in repo-assist.md? Maybe we have a non-deterministic go map serialization in the hash computation.

[mlinksva]

Tried the latest release and still get unpinned after running gh aw compile licensee/licensee@52592e1#diff-003eef2c82982ab4c5e7db3ad467392f8db2b31662648f4ae8c21285268b39d3R116

[dsyme]

cc @pelikhan for another look

[pelikhan]

It would be helpful to run the agentic-workflows agent on your side and ask it to debug the workflow run that unpinned and asked why.

If it was in the lock file, it should have kept long sha.

[mlinksva]

The unpinnng resulted from running gh aw compile -- as far as I understand, this is local, not a workflow run.

I asked Copilot to investigate and after a lot of back and forth got:

I think I understand the unpinning now.

This does not appear to be a workflow-run issue. The change happened locally in gh aw compile.

What seems to have changed is:

• gh-aw added ActionModeAction for github/gh-aw-actions in 2794315ec and started using it for release builds in 780f3f0cb (v0.59.0)
• that switched release output from github/gh-aw/actions/... to github/gh-aw-actions/...

For the specific unpinned setup ref, the likely cause is resolver fallback:

• github/gh-aw-actions does have a public v0.61.2 tag
• but the compiler resolves it via gh api /repos/github/gh-aw-actions/git/ref/tags/v0.61.2
• in my environment that API call fails with org SAML enforcement
• for ./actions/setup, the ActionModeAction path falls back to @v0.61.2 instead of consulting the embedded pin table, so the compiled lockfile ends up unpinned

So my current read is:

• expected current compiler behavior: switched to gh-aw-actions
• likely bug/regression: when SHA resolution fails, setup falls back to a tag ref instead of a pinned SHA, even though a pinning path exists elsewhere in the compiler