Repository navigation
Give the side-scan a copilot it can reach from the chroot - #387
Conversation
Every warning on the detection ledger was one failure: the compiled detection job hardcoded /usr/local/bin/copilot, which does not exist inside its chroot sandbox, so the scan died at spawn in four milliseconds with zero output and the empty log read as parse_error. The lanes have never actually scanned anything since the side-scan returned. Compiling with gh-aw v0.86.2 points the detection harness at the runner-temp copilot the chroot can see; the model pins stay, the external-detector path with its unpinned fetch does not compile in, and the only moved action pin is gh-aw's own setup at its matching sha. The version is a pinned prerelease because stable v0.85.4 is what emits the dead path, and the extension now installs from github/gh-aw, where the project moved.
📝 WalkthroughWalkthroughThe PR upgrades generated gh-aw workflows and action locks to v0.86.2. It updates prompt generation, Copilot execution, MCP gateway configuration, threat detection, validation schemas, runtime metadata, and safe-output job outputs. Changesgh-aw workflow upgrade
Estimated code review effort: 4 (Complex) | ~45 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/agentic_commands.yml:
- Line 56: Update the setup action reference in the workflow to use the locked
commit SHA 6aab9e5b5c91c615506061f09bedd81a23babe3c, retaining the v0.86.2
version comment.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 7c204ba4-9fad-4db6-94bb-f6e4a3426f4f
📒 Files selected for processing (5)
.github/aw/actions-lock.json.github/workflows/agent-mention.lock.yml.github/workflows/agent-review.lock.yml.github/workflows/agent-triage.lock.yml.github/workflows/agentic_commands.yml
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 5 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
Both reviewers are right that the one credentialed job still reached its setup action by mutable tag while every lock and the pin ledger hold the resolved sha. The compiler's commands dispatcher ignores its own ledger even under --action-mode action, an upstream gap, so the pin is applied by hand and holds until the next manual recompile.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Warning
The chroot copilot fix is real and consistent across all three lanes, but the claim that gh-aw setup was the only moved action pin is wrong: taiki-e/install-action also moved in every lock.
agent-mention.lock.yml#L470 — "only moved action pin" claim is inaccurate
The PR body says "the only moved action pin is gh-aw setup at its matching sha," but the install-action uses: line here also moved from cb33e69f (Release 2.85.8, 2026-08-04) to 18b1216 (Release 2.85.3, 2026-07-28) in all three lock files.
It reads as a consistency correction, not a deliberate downgrade: the base lock was internally inconsistent — its own manifest header and the source agent-mention.md#L26 already declared 18b1216 while the uses: line executed cb33e69f — and the recompile re-aligned the executed pin to the declared one. Same delta in agent-review.lock.yml and agent-triage.lock.yml.
Confidence: High that the pin moved and the claim is false; low that it was a deliberate downgrade.
Verified in the tree, not from the diff: the fix mechanics hold — copilot is copied from command -v copilot to ${RUNNER_TEMP}/gh-aw/bin/copilot, invoked quoted inside the chroot, and /tmp/gh-aw is mounted :rw, in both agent and detection paths of all three lock files, with no /usr/local/bin/copilot remaining anywhere. The dispatcher's setup pin is correctly SHA-locked (4b6f004), the deepseek model pins are unchanged, and the external-detector path is not compiled in.
| name: activation | ||
| path: /tmp/gh-aw | ||
| - uses: taiki-e/install-action@cb33e69fad06166ca28a42b2575e4dadabf62ee8 # 18b1216eba7f8039b0f8d131d5473787f0edce68 | ||
| - uses: taiki-e/install-action@18b1216eba7f8039b0f8d131d5473787f0edce68 # 18b1216eba7f8039b0f8d131d5473787f0edce68 |
There was a problem hiding this comment.
The PR body's claim that "the only moved action pin is gh-aw setup at its matching sha" is inaccurate: taiki-e/install-action's executed pin also moved in all three lock files.
The base lock ran cb33e69f (Release 2.85.8, 2026-08-04) and the head locks run 18b1216 (Release 2.85.3, 2026-07-28) — a step back one release. What makes it look like a correction rather than a chosen downgrade: the base lock was internally inconsistent (its own manifest header and the source agent-mention.md#L26 already declared 18b1216 while the uses: line executed cb33e69f), and the recompile re-aligned the executed pin to the declared one. Same delta in agent-review.lock.yml and agent-triage.lock.yml.
Confidence: High that the pin moved and the "only moved pin" claim is false; low that it was a deliberate downgrade — it re-aligns to the pin the source already declared.
Every warning on #373 is one failure repeated: the compiled detection job hardcodes /usr/local/bin/copilot, which does not exist inside its chroot sandbox, so the scan dies at spawn in four milliseconds with zero output and the empty log reads as parse_error. The side-scan has never actually scanned anything since it was turned back on; the earlier model fix cured the previous cause, not this one.
Recompiling with gh-aw v0.86.2 points the detection harness at the runner-temp copilot the chroot can see. The deepseek model pins stay, the external-detector path with its unpinned latest-release fetch does not compile in, and the only moved action pin is gh-aw setup at its matching sha. The version is a pinned prerelease on purpose: stable v0.85.4 is what emits the dead path, and the 0.86 line carries the detection chroot fixes. The extension now installs from github/gh-aw, where the project moved; the old githubnext home stops at v0.85.4 and made upgrade report up to date.
This PR is its own testbed: the review lane runs these locks against it, so a green detection job here with no fresh parse_error comment on #373 is the fix demonstrated live.
Summary by cubic
Fixes the side-scan crash in the chroot by pointing the detector to a reachable Copilot binary. Also pins the commands dispatcher to the locked setup SHA to prevent tag drift.
Bug Fixes
copilotinstead of/usr/local/bin/copilot, which wasn’t in the chroot.Dependencies
github/gh-aw-actions/setuptov0.86.2by SHA across workflows and the commands dispatcher; locks reflect the new compiler.github/gh-aw(moved fromgithubnext/gh-aw).Written for commit 4b6f004. Summary will update on new commits.
Summary by CodeRabbit