auto-dispatch hijacks interactive PR: re-labels origin:worker, opens competing PR, auto-closes the original

[superdav42]

Description

The auto-dispatch worker on a maintainer machine can hijack an interactive PR
opened by the same operator: the dispatcher re-labels the PR from
origin:interactive to origin:worker, treats the PR's title and body as a
worker task, opens a competing implementation branch (feature/auto-DATE-ghN)
plus a competing PR, and merges that competing PR with Resolves #N. This
silently auto-closes the original interactive PR even though the original
contained finished, browser-verified, CI-green work.

The dispatcher appears to enumerate auto-dispatch-eligible targets without
filtering on the GitHub object type — i.e. PRs and Issues are both consumed
as candidate inputs to the worker pipeline. An interactive PR matching the
heuristic is therefore indistinguishable from a worker-ready issue.

Expected Behavior

origin:interactive PRs must be a hard skip in the dispatcher's pre-flight,
regardless of any other heuristic. The pipeline should:

1. Detect the target is a PR (not an Issue) before re-labelling or assigning.
2. Detect origin:interactive and refuse to flip it to origin:worker.
3. Refuse to open a competing implementation against a target that is itself
   a PR (since "implementing a PR" is incoherent — the PR is the
   implementation).

In the live evidence below, all three guards would have prevented the hijack.

Reproducer

Symptom command (the hijack signature is observable from gh):

gh pr view 1108 --repo Ultimate-Multisite/ultimate-multisite \
  --json state,closed,closedAt,mergedAt,mergedBy,mergeCommit

Actual output:

{
  "closed": true,
  "closedAt": "2026-05-05T17:39:17Z",
  "mergeCommit": null,
  "mergedAt": null,
  "mergedBy": null,
  "state": "CLOSED"
}

PR #1108 was closed but never merged. Browse the timeline:

gh api repos/Ultimate-Multisite/ultimate-multisite/issues/1108/events

extracts to:

2026-05-05T17:24:04Z | superdav42 | labeled    | origin:interactive
2026-05-05T17:32:15Z | superdav42 | unlabeled  | origin:interactive
2026-05-05T17:32:15Z | superdav42 | labeled    | status:queued
2026-05-05T17:32:15Z | superdav42 | labeled    | origin:worker
2026-05-05T17:32:16Z | superdav42 | assigned   |
2026-05-05T17:38:21Z | superdav42 | unlabeled  | status:queued
2026-05-05T17:38:22Z | superdav42 | labeled    | status:in-review
2026-05-05T17:39:18Z | superdav42 | closed     |

PR #1108 was opened at 17:23 with origin:interactive. At 17:32:15 (8m 11s
later) the dispatcher unlabelled origin:interactive, applied
status:queued+origin:worker, self-assigned, and at 17:32:23 launched a
deterministic worker (audit comment: "Dispatching worker (deterministic).
Worker PID 217496, Model openai/gpt-5.5, Tier standard, Issue: #1108").

At 17:39:16 the worker merged a new PR #1109 (branch
feature/auto-20260505-113218-gh1108, title GH#1108: fix: secure template switching permission states, body containing Resolves #1108). #1109's
merge auto-closed #1108 at 17:39:17.

Expected output (the desired state):

{
  "closed": false,
  "state": "OPEN",
  "labels": ["origin:interactive", ...]
}

PR #1108 should still be open with its original labels intact, ready for
human review. PR #1109 should never have been created because PR #1108 is
itself a PR, not a dispatchable issue.

Causal code (suspected):

# The dispatcher enumerates auto-dispatch-eligible targets without checking
# the GitHub object type. Examples that need filtering:
rg -n 'gh_issue_list.*auto-dispatch|--label.*auto-dispatch' \
  ~/.aidevops/agents/scripts/pulse-triage-dispatch.sh \
  ~/.aidevops/agents/scripts/dispatch-single-issue-helper.sh \
  ~/.aidevops/agents/scripts/pulse-dispatch-worker-launch.sh

# `gh issue list` returns issues only — but if the dispatcher also accepts
# explicit issue numbers from elsewhere (manual claim, comment trigger,
# label-watcher), it must verify via `gh api repos/{slug}/issues/{N}`
# whether the response object has a `pull_request` key (PR) or not (Issue)
# before performing any write.

The fingerprint of the hijack — re-label origin:interactive→origin:worker
on a PR, self-assign, then open a sibling feature/auto-DATE-ghN branch —
is unique to this code path. Whichever script emits the audit comment
Dispatching worker (deterministic). ... Issue: #N is the entry point.

Steps to Reproduce

On a maintainer machine where the aidevops auto-dispatch pipeline runs in
the background (e.g. via launchd/cron pulse):

1. Open an interactive shell session in a project repo.
2. Open a PR via gh pr create with normal title prefix patterns (fix:,
   feat:, etc.) and any body containing fenced code or a runtime test
   instruction.
3. Wait 8–15 minutes (the pulse-triage interval).
4. Observe: the PR's origin:interactive label is removed, origin:worker
   is added, the maintainer is auto-assigned, a worker is dispatched against
   the PR number as if it were an issue, a feature/auto-DATE-ghN branch is
   created, a competing PR is opened with Resolves #N, and the competing
   PR auto-merges (closing the original PR unmerged).

Workarounds Applied

In the observing session (PR #1108 → #1109 hijack):

1. Verify functional equivalence after the fact: I diffed the merged
   commit against my closed branch via
   git diff fix/empty-template-switch-page origin/main -- <files> and
   confirmed the worker's version was a clean refactor of mine, so I
   accepted the merged outcome rather than re-opening. Systemic fix: the
   hijack should not happen in the first place; equivalence verification
   is an inappropriate manual cost.

2. Manual worktree + branch cleanup: after the close, my local worktree
   /home/dave/Git/ultimate-multisite-fix-empty-template-switch/ and local
   branch fix/empty-template-switch-page were stale and caused a
   Cannot redeclare class Automattic\Jetpack\Autoloader PHP-FPM fatal
   (two vendor copies of the autoloader registered the same namespaced
   class). I had to git worktree remove --force, git branch -D,
   git worktree prune, and reload PHP-FPM. Systemic fix candidate: when
   the dispatcher closes an interactive PR, it should at minimum log a
   "your branch was hijacked, here's how to clean up" comment on the
   closed PR — currently it leaves the operator with zero post-mortem
   guidance.

3. Memory note for future sessions: I stored
   mem_20260505114933_631de325 documenting the symptom and detection
   pattern (mergeCommit:null on the original at the same minute a
   feature/auto-DATE-ghN branch is merged with Resolves #N).

Environment

• aidevops version: 3.14.67
• Latest version: 3.14.67
• Install method: unknown (/home/dave/.local/bin/aidevops)
• AI Assistant: OpenCode 1.14.33
• OS: Ubuntu 24.04.4 LTS
• Shell: bash 5.2.21(1)-release
• gh CLI: gh version 2.45.0
• Worker model: openai/gpt-5.5 (per the dispatch audit comment)
• Worker aidevops version: 3.14.64 (per the dispatch audit comment) —
  i.e. the dispatcher and the worker are on slightly different versions on
  the same machine, suggesting the dispatcher pulls a snapshot before
  aidevops update ran.

Additional Context

• Original PR (hijacked, closed unmerged):
  fix: render permission state notices on template-switching page and authorize switch_template AJAX Ultimate-Multisite/ultimate-multisite#1108
• Competing PR (created by worker, merged):
  GH#1108: fix: secure template switching permission states Ultimate-Multisite/ultimate-multisite#1109
• Competing PR's commit on main: 7123cb51
• Worker's audit-trail comment on t286: Audit closed issues for false completions — t199.8 was closed with status:done but the worker had failed (clean_exit_no_signal) and only created a stub. The issue-sync pipeline auto-closed it. Audit all closed issues with status:done label to verify each has a merged PR with real deliverables. Check: (1) does the linked PR exist and is it merged? (2) does the PR contain substantive changes matching the task description? (3) are there any other tasks marked [x] in TODO.md that lack a valid pr: field? Output a report of any false completions found. #1108 (17:32:23Z): Dispatching worker (deterministic). Worker PID: 217496, Model: openai/gpt-5.5, Tier: standard, Issue: #1108. Note the literal Issue: #1108 — the
  dispatcher's metadata format does not distinguish issue from PR.
• Functionally the hijack ended OK in this case (the worker's
  reimplementation was equivalent), but the failure mode is bad on its own
  terms: it discards the human's verification work, opens a competing PR
  without notifying the human, and leaves stale local state behind.

The worst-case form of this bug is hijacking a PR whose CI is green and
which the human verified end-to-end against a real browser, in favour of a
worker re-implementation that has not been verified the same way. In this
session I verified PR #1109's behaviour matches PR #1108's via the same
browser test, but that re-verification took ~10 minutes I should not have
needed to spend.

Siblings

These are smaller workarounds the same root cause produced. They could be
filed separately or rolled into the primary fix:

• No post-hijack guidance comment on the closed interactive PR. When
  the dispatcher closes an interactive PR via the
  Resolves #N-on-competing-PR path, leave an explanatory comment on the
  closed PR pointing the operator at the merged competing PR and at the
  cleanup commands (git worktree remove --force, git branch -D,
  git worktree prune). The current behaviour is silent — the operator
  has to forensically reconstruct what happened from the timeline events
  and audit comments.

• Dispatcher metadata uses Issue: #N for both issue and PR targets.
  The audit comment format makes it impossible to tell from the comment
  alone whether the dispatcher saw the target as an issue or a PR. Adding
  a type tag (Issue: #N vs PR: #N) would have made this hijack visible
  in the timeline immediately — instead I had to compare gh pr view
  state to merge-commit timestamps to reconstruct the failure.

---

aidevops.sh v3.14.67 plugin for OpenCode v1.14.33 with claude-opus-4-7 spent 11h 19m and 226,200 tokens on this with the user in an interactive session.

[github-actions]

Thanks for the report, @superdav42.

This issue has been queued for maintainer review. A maintainer will review it and either:

• Approve it using: sudo aidevops approve issue 22948
• Ask for more information if the report needs clarification
• Close it if it's a duplicate or out of scope

Tip: For faster, higher-quality issue reporting, use /log-issue-aidevops in your AI assistant session. It gathers diagnostics automatically and checks for duplicates.

[marcusquinn]

Interactive session claimed by @marcusquinn on Marcus-MacBook-Pro.local.
Pulse dispatch blocked via status:in-review + self-assignment.

---

aidevops.sh v3.14.69 plugin for OpenCode v1.14.39 with gpt-5.5 spent 37s and 12,119 tokens on this with the user in an interactive session.

[marcusquinn]

Review: Approved

Pre-Review Context

Check	Result
Pre-existing duplicates	None exact. Related but not duplicate: #19688/#19731 (origin label mutex), #21862/#21914 (dual origin labels), #21468/#21485 (manual dispatch ceremony).
Superseded by recent work	Not superseded. Recent post-report commits checked (3e514ff7e, 15c69fe21) affect clean-room/zero-output dispatch, not PR-as-issue dispatch or origin/status takeover.
Framing matches reality	Yes. Current dispatch code treats targets as issue numbers and does not hard-stop when the GitHub issue API object is actually a PR.
Current file state matches issue body references	Partial drift only: the suspected entry points still exist; current hot path is pulse-dispatch-core.sh -> pulse-dispatch-worker-launch.sh.

Issue Validation

Check	Status	Notes
Reproducible	Plausible/Yes	The reported timeline matches existing code paths: pre-launch ceremony can remove origin:interactive, add origin:worker, assign the runner, post a deterministic dispatch comment, and launch a worker.
Not a pre-existing duplicate	Yes	Searches found adjacent origin-label bugs, but not this specific PR-target dispatch hole.
Not superseded by recent work	Yes	No landed fix found since issue creation for PR object detection or hard PR dispatch refusal.
Actual bug	Yes	Dispatching an implementation worker against a PR target is incoherent; the PR is already the implementation.
In scope	Yes	This touches the core dispatch safety gate.

Root Cause: Dispatch entry points load candidate metadata through issue-oriented paths and proceed without a PR-object hard stop before mutating labels/assignees. The current status:in-review path is the right collision signal once applied, but the dispatch path still needs to preserve it and refuse PR targets before any origin:* or status:* mutation.

Solution Evaluation

Criterion	Assessment	Notes
Simplicity	Good	Minimal fix: add a PR-target guard in the canonical dispatch metadata/preflight path and manual dispatch loader.
Correctness	Needs focused implementation	The fix must happen before _dlw_assign_and_label in .agents/scripts/pulse-dispatch-worker-launch.sh, which currently adds origin:worker and removes origin:interactive.
Completeness	Needs tests	Add regression coverage for PR-shaped issue API objects (pull_request key), status:in-review preservation, and manual dispatch refusal.
Consistency	Good	Existing status:in-review active-claim behavior already exists in .agents/scripts/dispatch-dedup-helper.sh; reuse it rather than adding a new label.

Alternatives: Use status:in-review as the interactive hold label and add a PR-object hard stop. Label-only is not enough because the safest invariant is stronger: dispatch should never implement a PR target, even if labels are missing, stale, or temporarily unsynced.

Second-Order Effects

Dimension	Finding
Architectural intent	Aligned. Existing tests already expect owner + status:in-review and owner + origin:interactive to block dispatch.
Safety gates touched	Dispatch dedup, origin labels, maintainer/interactive review state, worker provenance comments.
Symptom vs root cause	Root cause if implemented as PR-target refusal before mutation; symptom patch if only cleanup/post-hijack comments are added.
Ripple effects	Stops worker launch against PR numbers; preserves human review state; prevents competing worker PRs with Resolves #N; audit comment should distinguish Issue vs PR or never be emitted for PR dispatch refusal.
Rollback path	Revert the guard and tests if it blocks legitimate issue dispatch; low-risk if scoped to API objects with pull_request.

Scope & Recommendation

• Scope creep: Low if limited to pre-dispatch/manual-dispatch guards + regression tests.
• Complexity: Medium (tier:standard) because this is a dispatch safety gate.
• Decision: APPROVE.
• Labels: keep status:in-review; recommend bug, tier:standard; do not add auto-dispatch until the brief/test plan is ready.
• Implementation guidance:
  • In .agents/scripts/pulse-dispatch-core.sh, fetch or verify the issue API shape before dispatch proceeds; hard-block if the object has pull_request.
  • In .agents/scripts/dispatch-single-issue-helper.sh, reject PR targets before set_issue_status / set_origin_label can run.
  • In .agents/scripts/pulse-dispatch-worker-launch.sh, keep _dlw_assign_and_label unreachable for PR targets; do not remove origin:interactive or status:in-review on PRs.
  • Add tests under .agents/scripts/tests/ for PR-shaped issue JSON and for preserving status:in-review.
  • Verification: run the focused dispatch tests plus ShellCheck on touched scripts.

Dispatchability Assessment

Check	Status	Notes
Brief exists	No	No todo/tasks/*22948* brief found.
Brief has code blocks	No	Not applicable until a brief exists.
TODO entry with ref	No	No ref:GH#22948 entry found.
Task ID claimed	No	Not checked/claimed in this review.

Tier prerequisite met: No — needs a brief and TODO linkage before worker dispatch.
What is needed to dispatch: Add a worker-ready brief with files, reference patterns, and regression commands; then maintainer can approve/queue implementation.

---

aidevops.sh v3.14.69 plugin for OpenCode v1.14.39 with gpt-5.5 spent 2m and 77,320 tokens on this with the user in an interactive session.

[marcusquinn]

Maintainer Approval (cryptographically signed)

APPROVE:issue:marcusquinn/aidevops:22948:2026-05-05T21:26:13Z

-----BEGIN SSH SIGNATURE-----
U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgeu2Ii1FVuPun+49v51FONnIskf
TinwsexuL1MNgCwJ8AAAAQYWlkZXZvcHMtYXBwcm92ZQAAAAAAAAAGc2hhNTEyAAAAUwAA
AAtzc2gtZWQyNTUxOQAAAEDnl6NFgFJ3nJLu1ZsRnFC912qGucggsQ9LJh7Int3iz6P5+q
waWdp4dK504WJaiLlA9bDPvhzPip0GyF9gTzwM
-----END SSH SIGNATURE-----

This approval was signed with a root-protected SSH key. It cannot be forged by automation.

This issue is now locked. To propose scope changes, open a new issue referencing this one.

---

aidevops.sh v3.14.69 automated scan.

[marcusquinn]

DISPATCH_CLAIM nonce=c59eee788bb92f7e6ebcd52bbc7502d9 runner=marcusquinn ts=2026-05-05T21:27:42Z max_age_s=1800 version=3.14.69 opencode_version=1.14.39