Bug: dsh plugin add with a github: spec links the dependency but does not append it to dsh.profile.bundles

[MicroHEROX]

Environment: dsh 0.1.0-rc.6, pnpm 11.21, Windows. Reporter is the author of the dsh-exa-mcp third-party bundle (https://github.com/MicroHEROX/dsh-exa-mcp).

Steps to reproduce:

1. dsh plugin --profile exa-key add github:MicroHEROX/dsh-exa-mcp (fresh profile; also reproduced after remove + re-add, twice)
2. pnpm reports success: + dsh-exa-mcp git+https://github.com/MicroHEROX/dsh-exa-mcp.git and Done
3. package.json dependencies gets dsh-exa-mcp: git+https://... and pnpm-lock records it
4. But dsh.profile.bundles is NOT appended - --dump-config shows no # == dsh-exa-mcp layer

Same flow with a local directory spec (add C:/path/dsh-exa-mcp, a link: dependency) DOES append the bundle correctly.

Root cause trace (from the shipped lib): runPlugin calls reconcilePlugins(before, dir) on success; reconcilePlugins calls exportsPatch(packageName, profileDir) which does resolveBundleDir(...) + readProfileManifest(...).dsh?.bundle?.patch !== undefined. For a git-hosted install that resolve appears to fail (returns false), so the bundle is never pushed and a warning declares no dsh.bundle is printed that is easy to miss.

Impact: any plugin installed via github:/git+ spec silently does not activate, while the install itself reports success. Workaround for users: manually append the bundle to dsh.profile.bundles in the profile package.json, or use --patch overlays / local path installs.

Happy to provide more details or test a fix.

[MicroHEROX]

Update: the same root cause affects remove too, with a worse symptom.

After dsh plugin --profile <p> remove dsh-exa-mcp (git-installed), pnpm removes the dependency, but dsh.profile.bundles still contains the dangling entry. The profile then fails to boot / dump-config with:

cannot resolve profile bundle "dsh-exa-mcp" from the dsh installation or <profileDir>

So a git-spec install + remove leaves the profile broken until the user manually edits dsh.profile.bundles. Same exportsPatch/resolveBundleDir failure as the add case.

[MicroHEROX]

Correction / root-cause update: my earlier diagnosis (exportsPatch/resolveBundleDir failing for git installs) was WRONG - I verified resolveBundleDir works fine for git-installed bundles, and with a healthy network the full add/remove flow works correctly (bundle appended on add, removed on remove, manifest consistent).

What actually happened in the failing runs: the machine has an unstable route to github.com (intermittent ECONNRESET / ETIMEDOUT on the git HEAD probe, with pnpm retries). During those windows:

• pnpm can fail the install outright (dsh prints 'pnpm failed ...' to stderr, easy to miss), or
• pnpm prints Done but the git checkout is still materializing, so reconcilePlugins runs against an empty node_modules and does not append the bundle; the later-finishing checkout is never reconciled, or
• a mid-failure rollback removes the dependency entry, leaving an inconsistent-looking manifest.

So this is not a deterministic CLI bug, but there is a robustness gap worth considering: reconcilePlugins runs immediately after pnpm exits; for git-hosted specs pnpm may not have finished materializing node_modules yet (async git checkout). Consider waiting for/verifying the checkout before reconciling, and surfacing pnpm failures more prominently. Thanks for reading - happy to close this if that's the expected behavior.