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