Repository navigation
Bug: parallel-run-merge-gate-misparses-pr-number #691
Description
- Work Mode: full-bug
Summary
The parallel-orchestrator's PR-merge gate extracts the PR number by scanning the entire shell command text for the first standalone digit run, instead of parsing it from the gh pr merge argument specifically. A command prefixed with cd into a worktree path that itself contains a standalone 4-digit number (e.g. a year-prefixed worktree directory) gets its PR number misread from the path, and the merge is denied.
Environment
- OS/version: Windows, PowerShell
- Command/flags used:
cd C:\Users\DanMoisan\repos\TaskMaster-wt\2026-08-29T00-11 && gh pr merge --merge 688 - Data source or fixture: parallel-orchestrator final report for run
bugs-635-440, section "Corrections to things I told you earlier"
Steps to Reproduce
- Work from a worktree whose path contains a standalone digit run (e.g.
...\TaskMaster-wt\2026-08-29T00-11). - Run a PR-merge command prefixed with a
cdinto that path, e.g.cd C:\Users\DanMoisan\repos\TaskMaster-wt\2026-08-29T00-11 && gh pr merge --merge 688. - Observe the merge gate parses the PR number as
2026(the first standalone digit run in the full command text) rather than688. - The gate denies the command because PR
2026is not the expected/pinned PR for the run.
Expected Behavior
The gate should parse the PR number from the gh pr merge invocation specifically (e.g. the argument following --merge, or the PR number/URL argument), regardless of what other digit runs appear earlier in the command line.
Actual Behavior
A bare gh pr merge --merge 688 (no cd prefix) is accepted; the same command prefixed with cd into a path containing a standalone digit run is denied because the gate parsed the wrong number.
Logs / Screenshots
- Attached minimal logs or screenshot
- Snippet: Reported verbatim by the parallel-orchestrator: "The merge gate has a real defect. It parses the PR number by scanning the entire command text for the first standalone digit run, so my
cd .../2026-08-29T00-11 && gh pr merge --merge 688was read as PR2026and denied. The checkpoint was correct throughout. Bare commands work."
Impact / Severity
- Blocker
- High
- Medium
- Low
Source
From: docs/features/potential/2026-08-29-parallel-run-merge-gate-misparses-pr-number.md
Activity
drmoisan commentedon Sep 11, 2026
Routed upstream (2026-09-11)
The parser at fault lives in
.claude/hooks/hook-command-invocation.ps1, which is push-down owned from the drm-copilot repository (last overwritten by the harness 1.1.11 push-down, commit 8cf89a2 on 2026-09-11). A fix made here would be reverted by the next push-down. A prompt artifact for the upstream fix is committed atartifacts/drm-copilot-merge-gate-pr-number-parse-prompt.md. This issue stays open as the TaskMaster-side tracker and closes when the corrected hook arrives by push-down and the reproduction in the issue body no longer denies the merge.Interim mitigation already in force: this repository's Bash allowlist does not permit
cd-prefixed compound commands, so the triggering command shape is not issued by agents here.drmoisan commentedon Sep 28, 2026
Verified fixed. The PR number is now read only from the
gh pr mergesegment itself:Get-EpicMergeGateCommandPrNumberin.claude/hooks/enforce-epic-merge-gate.ps1:146-190takes the positional operand or the--mergevalue and fails closed otherwise. The fix came from drm-copilot commit fdf1c84c (v1.1.11) and arrived here with the harness 1.1.11 push-down 8cf89a2. The current copy is byte-identical to upstream. Closing.