copilot_driver.cjs not found - workflow compiled with v0.68.3 but setup action is v0.74.1

[jonathanpeppers]

Summary

The dotnes PR Reviewer workflow consistently fails in the Execute GitHub Copilot CLI step with:

Error: Cannot find module '/home/runner/work/_temp/gh-aw/actions/copilot_driver.cjs'

This is preceded by:

[entrypoint][WARN] Failed to transfer /host/home/runner/work/_temp/gh-aw/safeoutputs ownership to chroot user

The failure is reproducible on re-run (not transient).

Details

• Run URL: https://github.com/jonathanpeppers/dotnes/actions/runs/25993796204
• Workflow: dotnes-reviewer.lock.yml (compiled with gh aw compile)
• Compiler version: v0.68.3
• Setup action: github/gh-aw-actions/setup@b07cf98ac5874e8f51c34ba52099d8a6fac2ef93 (v0.74.1)
• Copilot CLI version: 1.0.21
• Runner: ubuntu-latest (Ubuntu 24.04)

Root cause

Dependabot bumped only the github/gh-aw-actions/setup SHA from v0.68.3 to v0.74.1 in the lock file (jonathanpeppers/dotnes@448cd30) without recompiling. This left the rest of the workflow (Copilot CLI v1.0.21, containers, etc.) at v0.68.3-era versions, creating a mismatch where the v0.74.1 setup action expected copilot_driver.cjs in a location that didn't exist.

Fixes applied

1. Fix reviewer workflow: recompile lock file and ignore gh-aw-actions in Dependabot jonathanpeppers/dotnes#504 (merged) - Recompiled dotnes-reviewer.lock.yml with gh aw compile v0.72.1, bringing all components into alignment
2. Ignore github/gh-aw-actions in Dependabot jonathanpeppers/dotnes#505 - Added Dependabot ignore rule for github/gh-aw-actions to prevent partial SHA bumps in the future

Suggestion for gh-aw

It may be worth considering whether gh-aw lock files should be marked in a way that Dependabot does not attempt partial version bumps on them. The lock file format looks like a regular GitHub Actions workflow with pinned SHAs, so Dependabot treats it as something it can update - but partial updates break the internal version consistency.

[pelikhan]

Yes it is a problem and we are looking into this.

[pelikhan]

/scout look for the dependabot support in the "init" command.

[github-actions]

🏕️ Lost in the wilderness! Scout failed to deliver outputs. Sending search party...

[github-actions]

🔍 Scout Research Report

Triggered by @github-actions[bot] — research request: "look for the dependabot support in the init command" (re: partial SHA bumps breaking lock files)

Executive Summary

The init command has no Dependabot support at all. All Dependabot handling lives in compile. Most importantly, gh-aw already ships the exact protection this issue asks for — a compiler-managed ignore rule that version-locks github/gh-aw-actions so Dependabot cannot partial-bump it — but it is applied during compile, is a no-op unless a github-actions block already exists in .github/dependabot.yml, and is never seeded by init. That gap is the actionable finding.

Click to expand detailed findings

Research Findings

1. init does not touch Dependabot

gh aw init (pkg/cli/init.go, pkg/cli/init_command.go) creates skills, the custom agent, .github/mcp.json, copilot-setup-steps.yml, and agentics-maintenance.yml. A grep across both files returns zero dependabot / reconcile references. So there is currently nothing in init that configures .github/dependabot.yml or guards lock files.

2. Where Dependabot support actually lives — compile

• gh aw compile --dependabot → GenerateDependabotManifests (pkg/workflow/dependabot.go) scans workflows and emits package.json/package-lock.json, requirements.txt, go.mod, plus a .github/dependabot.yml with the detected ecosystems (npm/pip/gomod) pointed at /.github/workflows.
• Every compile (not just --dependabot) calls ReconcileManagedDependabotIgnoresInRepo (compile_pipeline.go:527 and :580). This injects/normalizes an ignore entry into any existing github-actions update block:

  - package-ecosystem: github-actions
    ignore:
      - dependency-name: "github/gh-aw-actions" # Managed by gh aw compile. Version-locked to the gh-aw compiler; do not bump.

The ignored name comes from effectiveActionsRepo() (default GitHubActionsOrgRepo = github/gh-aw-actions) — i.e. the setup action whose partial SHA bump caused this very issue (#32893).

3. The gap relevant to #32893

ReconcileManagedDependabotIgnores is explicitly a no-op when there is no package-ecosystem: github-actions block (documented in docs/.../reference/dependabot.md). Consequences:

• A repo that pins actions and has a github-actions Dependabot block is protected — after the next compile. The dotnes failure happened because Dependabot bumped the setup SHA without recompiling, so the version-lock had not yet been written. The mechanism is the right fix; it just was not in place/triggered there.
• A repo with no github-actions block (or no dependabot.yml at all) gets no seeded protection from gh-aw today.

4. External validation

Dependabot's ignore + dependency-name is the established way to stop updates to a specific action (dependabot-core#11263), with known edge cases around hash-pinned actions (#13466). So the chosen mechanism is sound, but only works if the entry is actually present.

Recommendations

• Seed protection in init. Have gh aw init create/merge .github/dependabot.yml with a github-actions block (directory /) carrying the managed github/gh-aw-actions ignore rule, reusing ReconcileManagedDependabotIgnores. This closes the out-of-the-box gap for repos that never configured a github-actions ecosystem — exactly the scenario in this issue's suggestion.
• Alternatively/additionally, make compile's reconcile create the github-actions block when missing (today it only edits an existing one), so protection does not depend on the user having set one up.
• Document the dependency on recompiling: the version-lock only protects after a compile writes it — emphasize this in the dependabot reference and the dependabot-repair agent docs.

Key Sources

• pkg/workflow/dependabot.go — ReconcileManagedDependabotIgnores, managedDependabotIgnoreComment, effectiveActionsRepo
• pkg/cli/compile_pipeline.go:527,580 — reconcile wired into every compile
• pkg/cli/init.go / init_command.go — no Dependabot handling
• docs/src/content/docs/reference/dependabot.md — documents the no-op-without-github-actions-block behavior
• dependabot-core#11263, #13466

Suggested Next Steps

1. Decide ownership: seed the ignore rule at init time, or have compile create the github-actions block when absent (or both).
2. Reuse ReconcileManagedDependabotIgnores / DependabotConfigPath from the init flow to keep one source of truth for the managed comment + pattern.
3. Add a test mirroring copilot_driver.cjs not found - workflow compiled with v0.68.3 but setup action is v0.74.1 #32893: repo with no dependabot.yml → init → assert the github/gh-aw-actions ignore rule is present.

🔭 Intelligence gathered by Scout · 140.1 AIC · ⌖ 12.1 AIC · ◷

[pelikhan]

run

gh aw compile --dependabot