Route centralized command dispatches to the triggering PR branch and harden PR checkout runtime

[Copilot]

Centralized agentic_commands dispatch was triggering decentralized slash/label workflows on router context refs instead of the event’s branch context. This change makes dispatch branch-aware, including issue-comment and label events that originate from a PR thread.

• Runtime: branch-aware dispatch ref resolution

  • route_slash_command.cjs now resolves dispatch refs in PR-first order:
    1. GITHUB_HEAD_REF
    2. payload.pull_request.head.ref
    3. issue-backed PR lookup via pulls.get (for issues / issue_comment on PRs)
    4. existing fallback refs/default branch
  • Added ref normalization so branch names and full refs/* inputs are handled consistently.

• Runtime: issue-backed PR handling

  • For issue events that are actually PR-backed, router now fetches the PR head ref and dispatches to that branch, so slash/label workflows run against the correct PR code state.

• Compiler: router permission alignment

  • central_slash_command_workflow.go now emits pull-requests: write when merged events include issue/issue_comment paths that may require PR head resolution.
  • Refactored permission decision into a focused helper (needsPullRequestsPermission) for readability and maintenance.

• Compiler: workflow_dispatch PR-checkout condition alignment

  • pr.go now treats relayed workflow_dispatch runs as PR-checkout eligible when aw_context.item_type == 'pull_request' (without filtering on aw_context.event_type).
  • This ensures the existing “Checkout PR branch” step runs for dispatched PR contexts based on PR item context directly.

• Runtime: PR checkout safety guardrails

  • checkout_pr_branch.cjs now asserts trusted runtime context before checking out PR code:
    • refuses checkout when the workflow runtime repository is a fork
    • requires the triggering actor to have write, maintain, or admin access
  • This prevents accidental over-permission behavior during PR branch checkout.

• Coverage updates

  • Extended JS routing tests with branch-ref assertions for:
    • slash command on issue_comment over PR
    • label routing on issue-backed PR label events
  • Added Go workflow generation coverage for pull-request permission emission on issue_comment routes.
  • Updated unit coverage for the compiler-generated PR checkout condition to assert workflow_dispatch + aw_context.item_type == 'pull_request' behavior.
  • Added JS unit coverage for PR checkout runtime guardrails (forked runtime and insufficient actor permission paths).

// route_slash_command.cjs (simplified)
if (context.payload?.issue?.pull_request) {
  const pr = await github.rest.pulls.get({ owner, repo, pull_number });
  return `refs/heads/${pr.data.head.ref}`;
}

---

pr-sous-chef: requested branch update in workflow run 27063217612.

> Generated by 👨‍🍳 PR Sous Chef · 30.7 AIC · ⌖ 4.72 AIC · ◷

[pelikhan]

/scout do a security review on this change

[github-actions]

🔭 Recon complete! Scout has charted the territory. Map ready! 🗺️

[github-actions]

🔍 Scout Research Report

Triggered by @github-actions[bot]

Executive Summary

This PR resolves a well-known GitHub Actions limitation: issue_comment (and issues/label) events always run in the context of the default branch, never the PR head branch. The community consensus — across GitHub Docs, Security Lab, and multiple discussions — strongly validates the PR's core approach: when an issue event is PR-backed, call pulls.get to resolve head.ref and dispatch against that branch. The PR's PR-first resolution order (GITHUB_HEAD_REF → payload.pull_request.head.ref → issue-backed pulls.get → fallback) matches the recommended pattern almost exactly.

Research surfaced two correctness gotchas and one security consideration worth confirming the PR handles. They are summarized below the fold.

Click to expand detailed findings

Research Findings

1. The root cause is confirmed and intentional GitHub behavior

The issue_comment event "occurs for comments on both issues and pull requests" but runs in the context of the default branch, not the PR branch (GitHub Docs — events). There is a long-standing open feature request to add a dedicated pull_request_comment event or expose head/base ref directly (community #59389, #49628). The PR's pulls.get lookup is the canonical workaround; community examples use the identical call:

const pr = await github.rest.pulls.get({ owner, repo, pull_number: context.payload.issue.number });
// dispatch ref: pr.data.head.ref

2. ⚠️ Gotcha — workflow_dispatch requires the workflow file to exist on BOTH the target ref AND the default branch

This is the highest-risk edge case for branch-aware dispatch. A createWorkflowDispatch call fails if:

• the workflow .yml does not exist on the repo's default branch → HTTP 404: workflow X not found on the default branch ([SO 76461307]((stackoverflow.com/redacted), and
• the workflow on the dispatched ref lacks a workflow_dispatch trigger → Workflow does not have 'workflow_dispatch' trigger (community #24657).

Implication for this PR: when dispatching to a PR head branch, if that PR itself modifies or adds the decentralized slash/label workflow file, the dispatched run executes the head-branch version of the workflow definition. Worth confirming tests cover: (a) PR that edits the target workflow, (b) PR whose head branch is missing the workflow entirely.

3. ⚠️ Gotcha — fork PR head refs are not branches in the base repo

pr.data.head.ref returns the bare branch name (e.g. patch-1), but for a fork PR that branch lives in the contributor's fork, not the base repo. Dispatching refs/heads/patch-1 against the base repo will 404 (or, worse, silently match an unrelated same-named base-repo branch). The PR description's fallback chain handles the no-PR case; recommend verifying the fork path explicitly (pr.data.head.repo.full_name !== base repo → fall back to default branch rather than dispatching a non-existent ref).

4. 🔒 Security — pwn request exposure when running PR head code with elevated permissions

The PR adds pull-requests: write to the router. GitHub Security Lab warns that dispatching workflows that check out and run untrusted PR head code with write permissions/secrets is the classic "pwn request" pattern (Preventing pwn requests, [Arctiq pitfalls]((arctiq.com/redacted) The router permission bump itself is low-risk (it only reads the PR to resolve a ref). The risk lives in the dispatched workflow if it both runs head code and holds write scope — keep the privileged router and the code-executing workflow separated (which this architecture already does via dispatch).

5. GITHUB_HEAD_REF is only populated on pull_request/pull_request_target

Confirms the PR's resolution ordering is correct: GITHUB_HEAD_REF is empty for issue_comment, issues, label, and pull_request_review events (Contexts reference, community #25773), so falling through to pulls.get for issue-backed events is necessary, not redundant.

Recommendations

• ✅ Approach is sound and matches community/GitHub-recommended patterns — proceed.
• Add/confirm a test for the fork PR case (head ref not present in base repo) so dispatch falls back gracefully instead of 404-ing.
• Add/confirm a test for a PR that modifies the dispatched workflow file itself, since the head-branch definition is what executes.
• Document (in the workflow or PR) that the decentralized target workflow must keep a workflow_dispatch trigger and remain present on the default branch, or dispatch silently breaks.
• Keep the privileged router (pull-requests: write) strictly separate from any step that executes untrusted PR head code.

Key Sources

• GitHub Docs — Events that trigger workflows
• community #59389 — feature request: issue_comment on non-default branches
• community #24657 — workflow_dispatch on non-default branch errors
• GitHub Security Lab — Preventing pwn requests
• [DEV — Trigger workflow for PR comments (head_ref resolution)]((dev.to/redacted)

Suggested Next Steps

1. Verify fork-PR dispatch behavior in JS routing tests.
2. Verify dispatch when the PR edits the target workflow file.
3. Note the default-branch + workflow_dispatch-trigger preconditions in maintainer docs.

🔭 Intelligence gathered by Scout · opus48 267.3K · agent 80.2 AIC · threat-detection 12.6 AIC · ◷

[pelikhan]

@copilot the compiler already includes a step to checkout the pull-request branch. For issue_comment workflows, it needs to update the expression to support workflow_dispatch with a specific branch provided in the context.

[Copilot]

@copilot the compiler already includes a step to checkout the pull-request branch. For issue_comment workflows, it needs to update the expression to support workflow_dispatch with a specific branch pr...

Updated in f4c8810. The compiler now includes workflow_dispatch + aw_context(issue_comment + pull_request item_type) in the PR checkout step condition, and I added a unit test to cover the generated expression.

[github-actions]

🧠 Matt Pocock Skills Reviewer failed during the skills-based review.

[github-actions]

❌ Test Quality Sentinel failed during test quality analysis.

[github-actions]

⚠️ PR Code Quality Reviewer failed during code quality review.

[github-actions]

❌ Design Decision Gate 🏗️ failed during design decision gate check.

[Copilot]

Pull request overview

This PR fixes centralized agentic_commands workflow dispatch so decentralized slash/label workflows run against the triggering PR’s head branch (instead of the router’s ref), including issue/label events that originate from PR-backed issues.

Changes:

• Updated JS router ref resolution to prefer PR head refs (env GITHUB_HEAD_REF, PR payload head ref, then PR lookup via pulls.get for issue-backed PR events) and normalized refs consistently.
• Updated workflow compiler logic to treat dispatched workflow_dispatch runs with aw_context indicating issue_comment on a pull_request as eligible for “Checkout PR branch”.
• Updated central router workflow permission emission to include pull-requests: write when issue/issue_comment routes may require PR head resolution, plus added/extended unit tests.

Show a summary per file

File	Description
pkg/workflow/pr.go	Extends PR checkout step condition to include dispatched issue_comment PR contexts via aw_context.
pkg/workflow/pr_test.go	Adds coverage asserting the new workflow_dispatch + aw_context PR-checkout condition is emitted.
pkg/workflow/central_slash_command_workflow.go	Refactors PR permission decision into needsPullRequestsPermission, expanding to issue/issue_comment-backed PR cases.
pkg/workflow/central_slash_command_workflow_test.go	Adds coverage ensuring issue_comment centralized routes emit pull-requests: write.
actions/setup/js/route_slash_command.cjs	Makes dispatch ref resolution branch-aware (PR-first ordering + issue-backed PR lookup) and normalizes refs.
actions/setup/js/route_slash_command.test.cjs	Adds assertions that issue-comment and label events on PR-backed issues dispatch to the PR head branch.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 6/6 changed files
• Comments generated: 0

[github-actions]

@copilot review all comments and fix the failing test/build-wasm jobs before re-evaluating.

Generated by 👨‍🍳 PR Sous Chef · agent 45.4 AIC · threat-detection 4.79 AIC · ◷

[pelikhan]

@copilot merge main and recompile

[Copilot]

@copilot merge main and recompile

Done in 9262185: merged latest origin/main and ran make recompile.

[github-actions]

@copilot review all comments and address unresolved review feedback.

Please refresh the branch and summarize any remaining blockers.

Generated by 👨‍🍳 PR Sous Chef · 43.2 AIC · ⌖ 4.94 AIC · ◷

[github-actions]

``
Refresh the branch and rerun checks, then summarize any remaining blockers.

Generated by 👨‍🍳 PR Sous Chef · 30.7 AIC · ⌖ 4.72 AIC · ◷

[pelikhan]

@copilot also handle pull request review comment

[pelikhan]

@copilot this checkout PR step must assert in the runtime that the repository is not forked and the actor has at least write access.
this is to prevent accidental over permissions

[Copilot]

@copilot also handle pull request review comment

Done in 9e5618c: workflow_dispatch PR checkout conditions now also cover pull_request_review_comment contexts (aw_context.event_type + item_type == pull_request).

[github-actions]

@copilot refresh the branch from main, then rerun checks.

Generated by 👨‍🍳 PR Sous Chef · 99.8 AIC · ⌖ 5.17 AIC · ◷

[Copilot]

@copilot this checkout PR step must assert in the runtime that the repository is not forked and the actor has at least write access.
this is to prevent accidental over permissions

Implemented in 8ee1261.

The checkout step now enforces runtime safety before any PR branch checkout:

• refuses checkout when the runtime repository context is a fork
• requires the triggering actor to have write/maintain/admin permission on the repo

I also added focused tests for both failure paths in checkout_pr_branch.test.cjs.

[pelikhan]

@copilot merge main and recompile

[pelikhan]

@copilot you don't need to filter on the issue_comment event type. It just matters that the context is a pull request.

[Copilot]

Updated in 2fdc2b6: the workflow_dispatch checkout condition now only checks aw_context.item_type == 'pull_request' (no event_type filter).

[Copilot]

@copilot merge main and recompile

Done in 91ce8fa and 2fdc2b6: merged latest origin/main, then recompiled after the checkout-condition update.