Feature Request: Strong per-workspace isolation for skills and MCP servers

[walle1027]

Environment

@deepseek-ai/dsh v0.1.0-rc.6
Using dsh web / dsh --profile tui to manage multiple project workspaces in one instance.
Problem

DSH can boot once and manage multiple workspaces, which is great.
But the plugin/MCP tree is composed once at boot (profile/cordis.patch.yml + home patch + --patch), so MCP servers are process-global and cannot switch per workspace.
Skills are already discovered per project (/.dsh/skills), but the MCP tools those skills depend on cannot be provided per project.
Result: project-specific MCPs either require one DSH instance per project (dsh web --patch .dsh/cordis.patch.yml), or must be placed globally — which exposes every workspace to every project's database tools and causes server-name conflicts.
Expected behavior

One global DSH instance, multiple workspaces.
When opening/switching a workspace, both skills and MCPs are strongly isolated per workspace:
Each workspace exposes only its own skills (project-level discovery already exists for skills; please keep tool visibility consistent with it).
Each workspace starts only its own MCP servers (e.g. auto-load /.dsh/cordis.patch.yml or /.dsh/mcp.json).
Leaving a workspace stops/disposes its MCP connections; credentials must never leak across projects.
Same serverName in different workspaces must not conflict; tool names should be namespaced or scoped per workspace.
Suggested direction

Move MCP from boot-time global tree to a workspace-scoped service, or at least filter tool visibility per active workspace.
Keep --patch as explicit override, while supporting automatic project-level patch discovery from /.dsh/, similar to how skills are discovered.
Current workaround

Run one DSH instance per project with --patch and different ports. It works, but loses the single-instance multi-workspace advantage.

[nokkies]

A mechanism note that may unblock part of this today, plus where the real gaps are.

The tool registry is scope-aware: a plugin mounted inside an agent's composition registers its tools into that agent's scope, and they unwind when the agent disposes. Agent presets are exactly such compositions - a yaml list of plugin rows mounted per session. mcp-client registers its tools with ctx.tools.register on the context it mounts under, so an mcp-client row placed in a PRESET (rather than the boot tree) already gives you:

• tools visible only to sessions composed from that preset (your visibility ask, at preset rather than workspace granularity);
• disposal when the session's agent goes away (your lifecycle ask, at session granularity);
• no cross-scope name conflicts - two presets can carry the same serverName because each registers into its own scope.

Since presets can be copied and selected per session (session.create takes agentPreset), a per-project preset carrying that project's MCP rows approximates the isolation you describe without any core change.

What preset-scoping does NOT give you, and where I think the feature request should aim:

1. Per-project auto-discovery - nothing reads <projectRoot>/.dsh/mcp.json or a project-level patch into the preset today; the MCP config lives in the preset document. This is the substantial missing piece.
2. Workspace-switch lifecycle - scoping is per agent lifetime, not per "workspace open/close"; an idle session's MCP subprocess lives as long as the agent does.
3. Credential separation across projects is only as good as the preset separation - there is no enforcement that a workspace uses its own preset.

So the suggested direction in your last paragraph (workspace-scoped subtree) is right for 1-3, but the visibility/conflict half of the ask is reachable now through preset placement, which might take the pressure off while the bigger design lands.

[weijiafu14]

The MCP half of this is available today; the skills half is not, so let me be precise about which is which.

pi-mcp-adapter (a Pi-ecosystem MCP runtime running unmodified on DSH through pi2dsh) reads the MCP ecosystem's own layered config — a project-level .mcp.json in the workspace plus machine-level layers — instead of being composed once into the plugin tree at boot. So a database MCP that belongs to one project lives in that project's file and does not follow you into other workspaces:

dsh plugin --profile web add pi2dsh
dsh plugin --profile web add pi-mcp-adapter
# restart dsh

Our suite plugin dsh-work-x additionally gives that a UI: a native MCP panel in the web client showing the merged configuration grouped by layer (this project / global), with per-project enable/disable, and a machine-wide view under Settings.

Two honest limits:

1. This does not fix dsh-mcp-client's process-global composition — it is a separate MCP runtime you use instead.
2. It solves MCP isolation only. Per-workspace skills isolation is not covered — that stays your open request against DSH.

Evidence: examples/tui-mcp · capability matrix