Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

fix(pr-triage): the mark-ready guard can be bypassed with a repeated or comma-separated --add-label

Closed
  • Is something wrong?
#1,493 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
security, testing-qa, tooling

Research direction

Start with plugins/magpie-pr-management/skills/pr-triage/guards/mark_ready.py and the _opt_value() implementation in tools/agent-guard/src/agent_guard/init.py. Trace how dispatch() parses repeated and --flag=value arguments, then update the guard and run tools/agent-guard/tests/test_skill_guards.py. Done means repeated and comma-separated --add-label values containing the ready label are denied, while the existing fail-open cases remain unchanged.

Written by the indexing model from the issue text.

Description

What

plugins/magpie-pr-management/skills/pr-triage/guards/mark_ready.py enforces Golden rule 1b: never add the "ready for maintainer review" label while the PR head still has GitHub Actions runs awaiting approval. It decides whether a gh pr edit adds that label with:

label = ctx.opt("", "--add-label")

ctx.opt() is _opt_value() (tools/agent-guard/src/agent_guard/__init__.py:204-212), which returns the value of the first matching flag and stops. gh pr edit accepts --add-label more than once, and each value can be a comma-separated list, so two forms add the ready label without the guard looking at it. Using the same fake gh as test_mark_ready_pending_denied (two runs awaiting approval), through dispatch():

DENY   gh pr edit 5 --repo o/r --add-label "ready for maintainer review"
ALLOW  gh pr edit 5 --repo o/r --add-label triaged --add-label "ready for maintainer review"
ALLOW  gh pr edit 5 --repo o/r --add-label "triaged,ready for maintainer review"
Why it matters

The guard is the deterministic check behind rule 1b. In the two forms above it does not see the ready label, so the rule is left to the skill's instructions alone. The guard's fail-open paths (no PR number, a failed gh lookup) are deliberate; this one is not.

#1246 fixed the neighbouring class, flag values mistaken for positionals. It did not cover repeated or comma-separated values.

Suggested fix
  1. Add a multi-value accessor next to opt() on the guard context that returns every value of a flag, in both --flag value and --flag=value form.
  2. In mark_ready.py, split each --add-label value on commas and deny when any of them equals the ready label (trimmed and case-insensitive, as today).
  3. Add the two ALLOW cases above to tools/agent-guard/tests/test_skill_guards.py as DENY cases.
Found via

An architecture pass over how agent-guard parses gh argv; reproduced through dispatch() on main (37670575).

Related
  • #1246: fix(agent-guard): consume gh flag values so guards cannot be bypassed by flag order.
  • command_kinds() (__init__.py:686-687) still classifies a gh call by argv[1], so gh -R o/r pr edit ... is kind gh:-R. No shipped guard triggers on a gh:<group> kind today (they all declare ["gh"]), so this is latent. git already goes through git_subcommand_index(); gh_subcommand() could do the same job for gh.
Dominant language
Python
Stars
108
Forks
94
Avg merge
9h 53m
Merged PRs (30d)
343

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/magpie

All issues in apache/magpie

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.