You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
pm test sandbox loses freshly installed project extension between child processes #678
pm test <id> --run with the default schema linked-test context can report a project extension as installed, activated, and freshly verified, yet a subsequent pm process in the same linked-test command cannot discover that extension's commands.
This makes release or acceptance commands that install and immediately invoke a PM extension fail only under the governed linked-test runner.
Environment
@unbrained/pm-cli: 2026.7.24-3 (latest published when reproduced)
Linux x64
Bun 1.3.11
Project extension: pm-changelog@2026.7.24
Linked-test context: default schema
Reproduction
Link a command that installs and then invokes a project extension in separate child processes:
The same install/invoke sequence succeeds from the repository shell.
Observed
The install response inside the linked-test sandbox reports:
scope: project
runtime_activation_status: ok
activated: true
command_paths:
- changelog export
- changelog generate
verification:
status: ok
module_graph_verification: fresh_snapshot
The immediately following PM process fails:
code: unknown_command
title: Unknown command changelog
detail: pm does not expose command path "changelog" in current runtime configuration.
The execution context also reports project_extensions_seeded: true and global_extensions_seeded: true.
Expected
An extension installed and verified in the linked-test sandbox should remain discoverable by subsequent PM child processes in that same linked-test command.
Impact
PM-governed acceptance cannot faithfully execute release pipelines that use project extensions, even though the identical clean-tree pipeline passes outside pm test.
Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.
Create Plan
🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your .coderabbit.yaml:
issue_enrichment:
auto_enrich:
enabled: false
💬 Have feedback or questions? Drop into our discord!
Follow-up reproduction: forcing pm test --pm-context tracker --override-linked-pm-context produces the same failure. The sandbox contains all 54 tracker items and reports both extension roots seeded, then pm install reports fresh verification and activation, but the next pm process still returns unknown_command for changelog.
Activity
coderabbitai commentedon Jul 24, 2026
🔗 Related PRs
#302 - Optimize npm package SDK installs [merged]
#428 - Harden SDK extension runtime packaging [merged]
#475 - Improve package install and annotation agent UX [merged]
#479 - feat(package): isolate project doctor diagnostics [merged]
#491 - Harden init target safety and package install verification [merged]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
unbraind commentedon Jul 24, 2026
Follow-up reproduction: forcing
pm test --pm-context tracker --override-linked-pm-contextproduces the same failure. The sandbox contains all 54 tracker items and reports both extension roots seeded, thenpm installreports fresh verification and activation, but the nextpmprocess still returnsunknown_commandforchangelog.unbraind commentedon Jul 25, 2026
Tracked as pm-jvken3.