Third-party plugin can silently disable core providers (fs-sandbox/bash/pwsh) via cordis.patch.yml

[Thomson555]

Summary

Installing the third-party plugin @struktoai/mirage-dsh via dsh plugin --profile web add @struktoai/mirage-dsh silently disables the core filesystem, shell, and PowerShell providers — even when the user never intends to use mirage's virtual workspace. A casual "install a plugin" leaves the agent without working file tools, bash, or PowerShell until the user manually removes the plugin.

Risk level: High — any third-party bundle can patch cordis.patch.yml rows to disabled: true on core components, and nothing warns the user at install time.

Environment

• dsh version: 0.1.0-rc.7
• Platform: Windows 11
• Plugin: @struktoai/mirage-dsh (installed via dsh plugin add)

What happened

After installing mirage and restarting dsh web, the composed config (dsh --profile web --dump-config) shows these core rows disabled:

- id: fs-sandbox
  disabled: true        # real filesystem sandbox OFF

- id: bash-sandbox
  disabled: true        # bash OFF

- id: pwsh-sandbox
  disabled: true        # PowerShell OFF

- id: tool-pwsh
  disabled: true        # PowerShell tool OFF

- id: tool-fs-search
  disabled: true        # file search OFF

Replaced by mirage virtual providers (mirage-fs, mirage-shell) with a single ram mount at /tmp. The user's file tools, bash, and PowerShell now operate on a virtual workspace instead of the host disk — or simply stop working if mirage's service fails to start.

This comes from mirage's own cordis.patch.yml (bundled with the package), which disables the host providers and inserts its own. The user never opts in — dsh plugin add mounts the bundle's patch layer automatically.

Impact

• An agent in a normal desktop workflow loses file read/write, bash, and PowerShell — the three most-used capabilities
• On Windows, pwsh is the primary shell; disabling it breaks most tool usage
• If the user doesn't inspect --dump-config, the failure is confusing: tools "exist" in the catalog but don't work
• Third-party bundles have no sandbox/guard against disabling core providers

Expected behavior

1. dsh plugin add should warn (or refuse) when a bundle's patch disables core provider rows (fs-sandbox, bash-sandbox, pwsh-sandbox, tool-pwsh, tool-fs-search)
2. Or: plugin bundles should only be able to extend the tree, not disable rows owned by dsh-base (allowlist the base rows)
3. At minimum, document this risk in the plugin installation flow

Repro

dsh plugin --profile web add @struktoai/mirage-dsh
# restart dsh web
dsh --profile web --dump-config | grep -A2 "fs-sandbox\|pwsh-sandbox\|tool-pwsh"
# -> disabled: true

Notes

This was found during a plugin audit on a real Windows install. Happy to provide more detail or test a fix.

[denial123789]

I independently inspected the exact public npm artifact for @struktoai/mirage-dsh@0.0.1 with lifecycle scripts disabled. The published cordis.patch.yml confirms all five overrides (fs-sandbox, bash-sandbox, pwsh-sandbox, tool-pwsh, tool-fs-search) plus the three inserted Mirage rows and initial RAM /tmp mount. Its registry integrity was sha512-lWC/zwQx1YZWSF9+990bY4o0F9fDvFtLicDQRVi+tCSsm2nBgZvK7lbpqKYOaKjpP8ccBA0v5MGC6XD3W+daYQ==.

One useful nuance: the published patch comments explicitly describe this as an intentional provider swap, so the artifact itself is not hiding the design. The unsafe UX boundary is that a successful dsh plugin add automatically adds any dependency declaring dsh.bundle.patch to the ordered layer stack without presenting the resulting core-row capability diff for approval.

A practical preflight would compose before/after through the same applyEntryPatches path as --dump-config, then classify at least: existing row disabled, provider identity replaced, config replaced, dormant row enabled, and new row inserted. Platform expressions matter: the base Bash/PowerShell rows are OS-gated, while a later literal disabled: true applies regardless of platform.

I expanded the handbook audit with the verified artifact, source-backed layer semantics, a pre-boot diff workflow, core-row watch list, and Agent-level workspace/shell probes: https://sandbaseai.github.io/deepseek-harness-handbook/deepseek-harness-plugin-audit.html