Summary
One invalid flag on one command disables every command in the extension. The GH-719 validation added in 2026.7.27 is correct and its diagnostics are genuinely good — this is about the blast radius of the failure, and one misleading remediation line.
Upgrading to 2026.7.27 turned this into a live problem across a 18-package fleet: 9 packages each had at least one command declaring --json, and every one of them lost its entire command surface.
Reproduction
pm-todos declares --json on exactly one of its commands (todos validate). Activating it against 2026.7.27:
const a = await activateExtensionForTest(mod, { name: "pm-todos", capabilities: ["commands","schema"] });
console.log(a.registrations.commands.map(c => c.name)); // []
console.log(a.registrations.flags.length); // 0commands registered: (none)
flags registered: 0
Every other command in the package — todos import, todos export, todos sync, … — is valid and unaffected by the collision, but none of them register. To the user:
$ pm todos validate
Error: Unknown command todos
What already works well
Both diagnostics are good and should not change:
pm install prints the offending command, the flag index, and the exact hint (read it from context.global instead).- The unknown-command error carries an
Extension activation failures: section naming the extension and the same hint.
The two asks
1. Consider per-command quarantine instead of whole-extension failure. Dropping only the invalid registration and activating the rest would keep the other N commands usable, with the failure still reported exactly as it is now. If all-or-nothing is a deliberate integrity choice, it would help to say so in the error text — right now the output explains what is invalid but never says "so the whole extension was skipped", which is the part that surprises.
2. Fix the misleading remediation. The unknown-command error's Next steps says:
- If this command comes from an optional package, install it with: pm install todos
The package is installed — that is why the activation-failure section exists a few lines below. Following that suggestion cannot help. Two problems compound here: todos is also a bundled alias, so pm install todos resolves to something different from the failing pm-todos extension, and a user who runs it gets no closer to the cause.
When the dispatcher already knows an activation failure produced the missing command path, that branch should suppress the generic "install it" suggestion and instead point at the failure it is about to print.
Environment
@unbrained/pm-cli 2026.7.27, Linux, Node 26.5.0- Observed across pm-beads, pm-brief, pm-context, pm-csv, pm-ops, pm-presets, pm-slack, pm-todos, pm-web (22 shadowing declarations total)
Note on the underlying validation
To be clear, the GH-719 check itself is a good change and caught real bugs in our packages — every one of those 22 declarations was a latent conflict with a host global. We are fixing them all package-side. This issue is only about how much surface one bad declaration takes down with it.
Summary
One invalid flag on one command disables every command in the extension. The GH-719 validation added in 2026.7.27 is correct and its diagnostics are genuinely good — this is about the blast radius of the failure, and one misleading remediation line.
Upgrading to 2026.7.27 turned this into a live problem across a 18-package fleet: 9 packages each had at least one command declaring
--json, and every one of them lost its entire command surface.Reproduction
pm-todosdeclares--jsonon exactly one of its commands (todos validate). Activating it against 2026.7.27:Every other command in the package —
todos import,todos export,todos sync, … — is valid and unaffected by the collision, but none of them register. To the user:What already works well
Both diagnostics are good and should not change:
pm installprints the offending command, the flag index, and the exact hint (read it from context.global instead).Extension activation failures:section naming the extension and the same hint.The two asks
1. Consider per-command quarantine instead of whole-extension failure. Dropping only the invalid registration and activating the rest would keep the other N commands usable, with the failure still reported exactly as it is now. If all-or-nothing is a deliberate integrity choice, it would help to say so in the error text — right now the output explains what is invalid but never says "so the whole extension was skipped", which is the part that surprises.
2. Fix the misleading remediation. The unknown-command error's Next steps says:
The package is installed — that is why the activation-failure section exists a few lines below. Following that suggestion cannot help. Two problems compound here:
todosis also a bundled alias, sopm install todosresolves to something different from the failingpm-todosextension, and a user who runs it gets no closer to the cause.When the dispatcher already knows an activation failure produced the missing command path, that branch should suppress the generic "install it" suggestion and instead point at the failure it is about to print.
Environment
@unbrained/pm-cli2026.7.27, Linux, Node 26.5.0Note on the underlying validation
To be clear, the GH-719 check itself is a good change and caught real bugs in our packages — every one of those 22 declarations was a latent conflict with a host global. We are fixing them all package-side. This issue is only about how much surface one bad declaration takes down with it.