Repository navigation
SDK: ctx.pm_root points to non-existent <workspace>/.agents/pm in root-layout workspaces, breaking every extension that shells back into pm #495
Description
Environment
pm CLI 2026.7.10, pm-starter extension (spawnSync child pattern shared by most fleet extensions)
Reproduction (100%)
mkdir /tmp/fx-root && cd /tmp/fx-root
pm init . # root-layout: tracker dirs + settings.json directly in cwd (GH-488 flow)
pm install <path-to-pm-starter> # extension installs + activates fine
pm create task tt --acceptance-criteria a # works — parent CLI resolves the root tracker correctly
pm starter search tt # FAILSShim-captured child invocation shows the cause:
SHIM-ARGS: starter search tt
SHIM-ARGS: --path /tmp/fx-root/.agents/pm search --json -- tt
The extension forwards ctx.pm_root, and the SDK populated it with /tmp/fx-root/.agents/pm — a directory that does not exist in this layout. The actual tracker root the parent process resolved (and used to load the extension and create the item!) is /tmp/fx-root.
Why this matters for agents
- Parent command resolves the tracker; the context object it hands extensions contradicts that resolution. Every extension using the documented
spawnSync('pm', ['--path', ctx.pm_root, ...])pattern is dead in root-layout workspaces while appearing healthy in .agents/pm layouts — a silent, layout-dependent failure class. - Surfaced as a confusing downstream error (
pm starter search: \pm search` failed: {.` — first line of the child's JSON error), so agents burn tokens debugging the extension instead of the SDK.
Expected
ctx.pm_root (and any sibling context paths) should carry the tracker root the CLI actually resolved for the current invocation, regardless of layout. A regression test: init with pm init ., run an extension that spawns pm --path ctx.pm_root stats, assert exit 0.
Verified adjacent behavior
pm --path /tmp/fx-root search --json -- tt (correct root) exits 0. So only the context value is wrong, not the child CLI.
Activity
coderabbitai commentedon Jul 10, 2026
🔗 Related PRs
#73 - Fix nightly macOS realpath + Windows .cmd EINVAL and dedup extension-policy override builder [closed]
#142 - Guard pm tracker path targeting for agents [closed]
#266 - Harden init targeting and extension command contracts [merged]
#407 - Harden package scaffold command roots [merged]
#428 - Harden SDK extension runtime packaging [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 10, 2026
Fixed in bac1c4c (2026.7.10+main). Root cause: ancestor discovery in resolvePmRoot only probed
.agents/pmlayouts, so every implicit invocation — and the pm_root handed to extension commands — fell back to a non-existent<cwd>/.agents/pmin root-layout workspaces. Discovery now adopts<dir>/settings.jsontrackers (guarded by pm markers so an unrelated settings.json can never hijack resolution), with.agents/pmprecedence per level and explicit--path/PM_PATHunchanged. The suggested regression is in tests/integration/init-path-guard.integration.spec.ts: root-layout init + probe extension assertingctx.pm_root== workspace root + the documentedpm --pm-path <ctx.pm_root> statsspawn-back exiting 0. Tracked as pm-kvev.unbraind commentedon Jul 11, 2026
pm tracker item:
pm-kvev— SDK: ctx.pm_root points to non-existent <workspace>/.agents/pm in root-layout workspaces, breaking every extension that shells back into pm #495: extension context pm_root ignores root-layout trackers (falls back to non-existent .agents/pm)