dispatch-workflow: omitted `ref` on command (issue_comment) triggers silently dispatches the default branch, bypassing allowed-refs

[blozano-tt]

Summary

When an agent omits the (optional) ref argument on a dispatch-workflow safe-output call, dispatch_workflow.cjs silently falls back to the dispatching workflow's own ref. On a command / issue_comment trigger that is always refs/heads/main — so the dispatched CI runs test the default branch instead of the PR the command was issued on, and report green for code that was never exercised. allowed-refs cannot prevent this because it is only validated against explicit refs; the fallback bypasses it entirely.

This is the follow-up failure mode to the (all fixed, thank you!) #49400 → #49408, #49713, #50027 chain: the agent can now pass ref per call — but nothing makes it have to, and the failure when it doesn't is silent and wrong rather than loud.

Evidence run

https://github.com/tenstorrent/tt-metal/actions/runs/32947659949 — the /test command workflow in tenstorrent/tt-metal (source: test-command.md, compiled with gh-aw v0.86.2, dispatch-workflow configured with allowed-refs: ["**"] and 34 allowlisted workflows).

• Trigger: /test comment on PR [WIP] [test-parallel] Daily Go Test Parallelizer: work in progress #54397 (head branch aswinmcw/gelu-bw-fp32-scalar-immediates).
• gh-aw's own checkout logic did the right thing: checkout_pr_branch.cjs logged Detected issue_comment event on PR #54397, will fetch PR ref and checked out the PR head. The agent literally ran on the PR branch.
• The generated per-workflow dispatch tools correctly exposed the ref parameter (the dispatch-workflow: per-workflow tool schema never exposes the ref parameter added in #49408 #49713/dispatch-workflow: per-call ref override lands in inputs, causing 422 "Unexpected inputs provided" and/or dispatching the wrong ref #50027 fixes are working).
• The agent (Copilot engine, claude-sonnet-5) selected two pipelines and called the tools without ref — despite the workflow prompt instructing, in bold, that every dispatch must set it, and despite correctly naming the PR branch in its own summary comment ("Ref for both dispatches: aswinmcw/gelu-bw-fp32-scalar-immediates"). Collected safe-output items:

{"type":"dispatch_workflow","workflow_name":"sanity-tests","inputs":{"run-blackhole":true, "...":"..."}}
{"type":"dispatch_workflow","workflow_name":"perf-device-models","inputs":{"architecture":"[\"blackhole\", \"wormhole_b0\"]"}}

• The safe_outputs job dispatched both with no warning about the ref, and both target runs report "headBranch": "main":
  • https://github.com/tenstorrent/tt-metal/actions/runs/32948096820 (Sanity tests, workflow_dispatch, headBranch main)
  • https://github.com/tenstorrent/tt-metal/actions/runs/32948107162 (Device perf regressions, workflow_dispatch, headBranch main)

Net effect: real hardware pipelines burned on main, and a PR author who trusts the badges gets a green signal that tested none of their code.

Root cause

actions/setup/js/dispatch_workflow.cjs resolves the default ref once, before processing items:

if (config["target-ref"]) {
  defaultRef = config["target-ref"];
} else if (process.env.GITHUB_HEAD_REF) {
  // We're in a pull_request event, use the PR branch ref
  defaultRef = `refs/heads/${process.env.GITHUB_HEAD_REF}`;
} else if (process.env.GITHUB_REF || context.ref) {
  defaultRef = process.env.GITHUB_REF || context.ref;
} else {
  defaultRef = await getDefaultBranchRef();
}

On issue_comment (which is what command:/slash_command: workflows compile to) GITHUB_HEAD_REF is unset and GITHUB_REF is refs/heads/<default-branch>, so defaultRef is always the default branch — even though the run is unambiguously a PR context (context.payload.issue.pull_request is set, and gh-aw's own checkout_pr_branch.cjs resolves the PR head for the very same run).

And the per-item handling only validates explicit refs:

const outputRef = typeof message.ref === "string" ? message.ref.trim() : "";
let ref = defaultRef;
if (outputRef) {
  ref = normalizeRef(outputRef);
  // ... allowed-refs checks happen only inside this block ...
}

So there is no configuration that fails closed: allowed-refs constrains what the agent may say, not what an omission does. target-ref can't help either — it's a single static string, and the correct branch differs per invocation.

A contributing factor: the injected ref schema description reads "If omitted, the dispatching workflow's ref is used." In a command workflow the agent has just been checked out onto the PR branch, so a model can quite reasonably conclude omission is safe — its checked-out ref is the PR branch. The description is technically about GITHUB_REF, but nothing in the tool surface says "omission = default branch" on comment triggers.

Expected behavior (any of these would close the gap)

1. Resolve the PR head in the fallback chain for issue_comment-on-PR events, mirroring checkout_pr_branch.cjs: when context.eventName === "issue_comment" and context.payload.issue.pull_request is set, fetch the PR head ref (the PR number is right there in the payload) instead of falling through to GITHUB_REF. This makes dispatch consistent with checkout — today the agent runs on the PR branch but dispatches at main.
2. Apply allowed-refs to the fallback ref too (fail closed): if the resolved default ref doesn't match the configured patterns, refuse the dispatch with an error instead of silently proceeding. Repos could then express "PR branches only, never main".
3. A require-ref: true (or similar) option on safe-outputs.dispatch-workflow that makes an omitted message.ref a hard per-item error, and marks ref as required in the generated per-workflow tool schemas.

Actual behavior

Omitted ref on an issue_comment-triggered workflow silently dispatches every target workflow against the default branch, with no warning and no way to configure a failure.

Reproduction

1. A gh-aw workflow with on: command (PR comments), safe-outputs.dispatch-workflow with allowed-refs: ["**"] and at least one target workflow.
2. Trigger it from a PR comment; have the agent call a dispatch tool without ref (models do this some fraction of the time even when instructed otherwise — that's the point of wanting a deterministic guard).
3. Observe the dispatched run's headBranch is the default branch.

Workaround we're shipping in tenstorrent/tt-metal

A post-steps step that rewrites /tmp/gh-aw/agent_output.json after gh-aw's "Ingest agent output" step, forcing ref on every dispatch_workflow item to the runner-resolved PR head branch (pre-fetched deterministically in pre-agent-steps). It works because post-steps are emitted between ingestion and the agent artifact upload that the safe_outputs job consumes — but it's coupled to those internals, which is why a first-class fix here would be better.

gh-aw version: v0.86.2 (actions github/gh-aw-actions@6aab9e5, awf v0.27.44).

[blozano-tt]

Follow-up data point from review of the downstream workaround (tenstorrent/tt-metal#54486), relevant to how a first-class fix should be shaped: a downstream post-step mitigation is harder to get right than it looks, because the agent artifact upload runs if: always() and the safe_outputs job gate is needs.agent.result != 'skipped' — so if the mitigation step itself errors, the un-rewritten items are still uploaded and dispatched (fail-open). We had to add explicit neutralize-on-any-exit trapping to make it fail closed. An upstream fix in dispatch_workflow.cjs wouldn't have this problem, since the ref resolution and the dispatch are in the same code path — one more reason options 1/2 in the issue body (PR-head-aware fallback, or validating the fallback against allowed-refs) are preferable to every consumer reimplementing this.

[blozano-tt]

One more hardening data point from the downstream workaround's review (tenstorrent/tt-metal#54486): any consumer-side ref enforcement must also keep its inputs outside the agent-writable mount. The awf sandbox mounts /tmp (including /tmp/gh-aw) read-write into the agent container, so files a pre-agent step stages under /tmp/gh-aw for a post-agent enforcement step are tamperable by a prompt-injected agent with bash. We moved the authoritative head-ref/fork facts to ${RUNNER_TEMP}/gh-aw-facts (host-owned; ${RUNNER_TEMP}/gh-aw is mounted :ro and sibling paths aren't mounted). An upstream fix in dispatch_workflow.cjs sidesteps this entire class of issues, since it runs in the safe_outputs job with no agent in the loop — a third reason to prefer options 1/2 from the issue body over per-repo mitigations.