Agent safety: an unsupported --dry-run makes the recovery bundle suggest the real mutation (close, update, claim) #1337

What happens (pm 2026.9.28)

--dry-run exists on close many, update many and some other paths, but not on close, update or claim. An agent that adds it to preview a mutation gets an error. Good so far. The recovery bundle then proposes the same command without --dry-run, labelled as the correction:

$ pm close pm-cli-website-rdlp x --validate-close warn --dry-run
Error: Unknown option --dry-run
  - Replay with suggested correction: pm close pm-cli-website-rdlp x --validate-close warn
  suggested_retry: pm close pm-cli-website-rdlp x --validate-close warn

$ pm update pm-cli-website-rdlp --status open --dry-run
  suggested_retry: pm update pm-cli-website-rdlp --status open

$ pm claim pm-cli-website-g23l --dry-run
  suggested_retry: pm claim pm-cli-website-g23l

An agent that follows suggested_retry, which is what the field invites, performs exactly the change it was trying to preview: it closes the item, rewrites its status, or takes the claim. Dropping an unknown flag is a reasonable repair for most flags, but not for one whose whole meaning is "do not change anything".

Expected

When the rejected option is --dry-run (or another no-side-effect flag such as --check or --plan), the bundle must not offer the stripped command as a correction. It could:

• name the paths that do accept it (close many, update many, …) and the read-only way to see the effect (pm get <id>, or pm close many --ids <id> --dry-run if that is equivalent), and
• leave suggested_retry empty, or mark it mutates: true so harnesses can refuse to replay it automatically.

Better still, accept --dry-run on every mutating single-item command, since many already implements it.

Why it matters

Agents are told to preview before they mutate, and to follow the recovery bundle when a command fails. Here those two instructions combine to perform the very mutation the agent wanted to avoid.