workflow_dispatch targeted issue binding ignored — agent never reads bound issue, emits noop, workflow succeeds

[samuelkahessay]

Context

Observed on 2026-03-17 while retesting a repo-assist workflow compiled with gh-aw v0.60.0. A targeted workflow_dispatch with issue_number=7 produced the correct activation prompt binding, but the agent never read issue #7. Instead, it queried unrelated issues (#14, #9, #11, #13), concluded the repository had been "reset or cleaned," emitted a single noop, and the workflow finished success.

The same repo and workflow on v0.59.0 did follow issue #7 and reached the create_pull_request path in run 23211258497, so this looks like a regression rather than a repo configuration problem.

The run is public and the activation logs show the full prompt.

Problem

The activation prompt correctly contains:

If 7 is non-empty, this run was dispatched for a specific issue and is bound to issue #7.
Treat issue #7 as the only candidate for Task 1 in this run.

But the agent's execution path was:

1. Activation bound the run to issue #7
2. Called issue_read for #14, #9, #11, #13
3. Never called issue_read for #7
4. Concluded: "It appears this repository has been reset or cleaned. There are no open issues, no open PRs, and no implementation code."
5. Emitted noop

The framework constructed the correct prompt, but in this run the bound issue was never read before a noop was accepted. When the agent ignores the binding and exits via noop, the workflow reports success even though the targeted work was never attempted.

Location

The targeted dispatch binding is constructed in the activation prompt step. The observed failure is that a noop was accepted even though the bound issue was never read.

Relevant areas (not pinned to exact lines since the prompt construction spans multiple files):

• Activation prompt template: targeted issue dispatch instructions
• Agent execution path: selected unrelated issues instead of the bound issue
• noop handling / post-agent validation: accepted a noop after the bound issue was skipped

Reproduction

1. Create a repository with a repo-assist workflow compiled with gh-aw v0.60.0
2. Ensure the repo has an open issue #7 with pipeline + infra labels
3. Run workflow_dispatch with issue_number=7
4. Observe that the activation prompt correctly binds to issue #7
5. Observe whether the agent actually reads issue #7
6. In the failing case, the agent reads unrelated issues instead, emits noop, and the workflow concludes success

In the observed failing run, stale references to other issue numbers were present in memory/history, but this report does not depend on proving that memory is the root cause. The key failure is that the bound issue was not read before noop was accepted.

Expected behavior

When issue_number is provided via workflow_dispatch:

• The agent should read issue #7 before making any decisions about the run
• If the agent emits noop without having read the bound issue, the workflow should reject the noop or flag it as a validation failure
• A targeted dispatch run should not conclude success when the bound issue was never read

Evidence

v0.60.0 run (regression): 23214643269

• Branch: codex/gh-aw-v060-retest
• Activation prompt: "If 7 is non-empty, this run was dispatched for a specific issue and is bound to issue #7."
• Agent issue_read calls: #14, #9, #11, #13 — no #7
• Agent reasoning: "It appears this repository has been reset or cleaned"
• safe_outputs summary: Total messages: 1, Successful: 0, Failed: 0, Skipped (standalone step): 1
• Noop comment posted to issue #17 ([aw] No-Op Runs)
• Issue #7 unchanged, no PRs created

v0.59.0 run (working): 23211258497

• Branch: codex/gh-aw-v059-retest
• Same repo, same workflow, same issue #7
• Agent followed issue #7 and reached create_pull_request (failed on protected files, but the binding was honored)

Proposed fix

Add a runtime validation when targeted dispatch is active and the agent emits noop:

1. After the agent step completes, check the MCP gateway logs or agent step summary for issue_read calls
2. If issue_number was provided and the agent never called issue_read for that issue number, reject the noop with a clear error: "Targeted dispatch bound to issue #N but the agent never read issue #N"
3. This turns a silent success-with-no-work into a visible failure that can be triaged

Alternatively, strengthen the activation path so the bound issue is harder to skip — for example, inject the bound issue's title and body directly into the prompt context rather than relying entirely on the agent to fetch it.

Environment

• Regression run: v0.60.0, run 23214643269
• Working run: v0.59.0, run 23211258497
• Repo: samuelkahessay/team-standup-tracker

[pelikhan]

/scout investigate repo-assist based on this description.

[github-actions]

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

[github-actions]

🔍 Scout Research Report

Triggered by @pelikhan

Executive Summary

This report investigates the workflow_dispatch targeted issue binding regression between gh-aw v0.59.0 and v0.60.0 for repo-assist-style workflows. The core failure has two layers: the framework correctly builds the activation prompt with the issue binding, but (a) the agent ignores the binding due to stale cache/repo memory content, and (b) the framework has no post-execution guard that rejects a noop when the bound issue was never read. The most likely regression trigger is the activation artifact restructuring (prompt generated in activation job, uploaded, then downloaded by agent), combined with changes to prompt section ordering or expression substitution timing.

Click to expand detailed findings

Research Findings

How the Targeted Dispatch Binding Is Constructed

The repo-assist workflow (sourced from githubnext/agentics) includes a workflow_dispatch trigger with an issue_number input. The activation prompt template in that workflow's markdown contains text such as:

"If ${{ inputs.issue_number }} is non-empty, this run was dispatched for a specific issue and is bound to issue #${{ inputs.issue_number }}."

The gh-aw compiler resolves this expression during the prompt creation step inside the activation job (compiler_activation_job.go, generatePromptInActivationJob). The resulting prompt.txt (with 7 substituted for the expression) is uploaded as the activation artifact and downloaded by the agent job.

The prompt text itself is correct — this is confirmed by the issue reporter ("activation prompt correctly contains…"). The bug is downstream of prompt generation.

Why the Agent Ignores the Binding

The repo-assist workflow uses repo-memory (or cache-memory). The memory prompt (actions/setup/md/repo_memory_prompt.md) tells the agent it has access to a persistent folder backed by a git branch: files created in previous runs (e.g., notes about issues #14, #9, #11, #13) survive into the new run. When the agent starts, it reads those memory files first, picks up the stale issue references, and begins resolving them — all before checking the activation binding instruction.

Key source: pkg/workflow/unified_prompt_step.go:collectPromptSections() assembles prompt sections in this order:

0. XPIA instructions
1. Temp folder
2. Markdown generation
3. Playwright (if enabled)
4. Agentic-workflows guide (if enabled)
5. Trial mode note
6. Cache memory instructions  ← stale issue refs land here
7. Repo memory instructions   ← stale issue refs land here
8. Safe outputs instructions
9. GitHub context
10. PR context

The targeted dispatch binding instruction (from the user's workflow markdown) comes after the built-in sections. Memory is referenced in sections 6–7, so the agent may resolve memory content before it reaches the binding instruction in section order.

The Missing Post-Execution Validation

actions/setup/js/noop_handler.cjs only validates that the message field is present and non-empty. There is no check for:

• Whether inputs.issue_number was set (targeted dispatch was active)
• Whether the agent ever called issue_read for that specific issue number before emitting noop

Similarly, actions/setup/js/noop.cjs processes noop messages only for logging/summary — no binding validation is performed.

Result: a targeted dispatch run can complete with success and a noop comment on the noop-runs issue, while the bound issue is completely untouched.

Most Likely Regression Factor (v0.59.0 → v0.60.0)

Based on the changesets in this repo, the most impactful changes between these versions are:

Changeset	Description
patch-activation-activation-artifact	Prompt generation moved to activation job; prompt.txt + aw_info.json uploaded together as activation artifact
patch-move-github-checkout	.github/.agents sparse checkout moved into activation job
patch-generate-needs-expressions	Substitution step now always publishes known needs.* expression mappings and rewrites needs.activation.outputs.* refs
patch-merge-validate-context	Lockdown validation merged into generate_aw_info step

The activation artifact change is the most likely regression trigger. Previously the prompt was created inline in the agent job, where expression evaluation context (e.g., inputs.issue_number) was immediate. Now it is evaluated in the activation job, serialized to a file, and re-read by the agent. If expression substitution timing or order changed subtly, the binding instruction could be affected — although the reporter confirms the substitution is correct (7 appears in the prompt).

A secondary regression risk: the patch-generate-needs-expressions change rewrites known activation output references. If inputs.issue_number became mapped to an empty or incorrect expression through this rewrite, it could cause silent failures in some prompt paths (though again, the reporter sees 7 correctly).

The Most Likely True Root Cause

The stale memory reading pattern predates this regression. What v0.60.0 may have changed is the relative weight or prominence of the activation binding instruction in the assembled prompt. If the prompt ordering or section content changed (e.g., new content was added to sections 6–7, or the user prompt binding instruction now appears further from the top), the model may weight it lower against the memory context.

Recommendations

1. Add targeted dispatch noop validation: After the agent completes, check the MCP gateway logs (already available) for issue_read calls. If inputs.issue_number (or inputs.item_number) was provided and the agent emitted noop without reading that issue, surface a warning or fail the safe-outputs step with a clear error:

   "Targeted dispatch bound to issue #N but the agent never read issue #N — noop rejected"

2. Inject bound issue content directly into the prompt: Rather than relying on the agent to fetch the issue, inject its title and body into the activation prompt context (similarly to how needs.activation.outputs.text is injected for comment triggers). This makes the binding impossible to skip via memory distraction.

3. Strengthen the binding instruction's position: In collectPromptSections(), consider inserting a targeted-dispatch section after memory sections (currently 6–7) and before safe-outputs (8), so it appears closer to the agent's decision point.

4. Add a test case for targeted-dispatch noop rejection: A golden test that compiles a workflow with issue_number input, simulates an agent noop without an issue_read call for the bound issue, and asserts that the safe-outputs step fails validation.

Key Sources

• pkg/workflow/unified_prompt_step.go — collectPromptSections() at line 221
• pkg/workflow/compiler_activation_job.go — buildActivationJob() and generatePromptInActivationJob() at lines 17 and 551
• actions/setup/js/noop_handler.cjs — noop validation logic (lines 43–51)
• actions/setup/js/noop.cjs — noop processing (no binding validation)
• actions/setup/md/repo_memory_prompt.md / cache_memory_prompt.md — memory section prompts
• pkg/workflow/tools.go:392 — injectWorkflowDispatchForIssue (trial mode path)
• .changeset/patch-activation-activation-artifact.md — the most relevant v0.60.0 change

Suggested Next Steps

1. Audit the generate_aw_info.cjs and collect_ndjson_output.cjs to confirm what env vars are available when the activation artifact is downloaded by the agent job — specifically whether inputs.issue_number is accessible at validation time.
2. Check whether the MCP gateway logs (already streamed by the framework) include enough issue_read call data to implement post-execution binding validation without adding new infrastructure.
3. Compare the compiled prompt.txt artifact from a v0.59.0 run against a v0.60.0 run (both available as public artifacts on the linked runs) to isolate whether any content ordering or section content changed between versions.
4. Consider short-circuiting the issue: add a validation step to the safe_outputs job that reads GH_AW_DISPATCH_ISSUE_NUMBER (or equivalent) and checks the agent output NDJSON for a matching issue_read call before allowing noop to succeed.

References:

• Regression run §23214643269
• Working run §23211258497
• Scout run §23225236481

🔭 Intelligence gathered by Scout · ◷

[dsyme]

Hi @samuelkahessay

I think this is (mostly) not a GH-AW bug per se but more of a prompting bug which you might need to work on. You've added this new targeted issue mode which is cool. The agent is indeed however confused by this:

Agent: 3. The instructions variable is "${{ steps.sanitized.outputs.text }}" - this appears to be a template variable that hasn't been resolved, suggesting this is likely scheduled mode
Agent: 4. The issue number `7` is also just "#" - meaning no targeted issue dispatch

The reasoning at step 4 "The issue number 7 is also just "#" - meaning no targeted issue dispatch" is just poor agent reasoning but I think the "Mode" prompting could be a bit clearer.

There is however one bug for us here - the text "${{ steps.sanitized.outputs.text }}" is still in the prompt but should be empty. Equally your prompting around this case needs work I think as it would just be

## Command Mode

Take heed of **instructions**: ""

which is a bit confusing.

[dsyme]

I'll close this out, thanks, the other things covered in #21624