在让dsh 开发一些插件的时候，或者对dsh本身做一些操作的时候，应该加上一些限制

[1498659268]

开发插件的时候，直接导致整个服务不能使用了，报错了，应该加上一个核心限制，所有的操作不能对dsh产生影响

[weijiafu14]

这个诉求我认为成立——"让 agent 开发插件"和"agent 跑在这个 harness 上"共用一个实例，本来就是个危险的组合。但在官方加限制之前，有一条今天就能用的隔离办法：用另一个 profile 开发。

dsh plugin --profile dev add <你在开发的插件>
dsh --profile dev                  # 在这里试

profile 之间的插件组合是隔离的：装进 dev 的插件只在 dev 生效，它把 dev 搞崩了，你天天用的那个 profile 一点事没有。等验证没问题再装进主 profile。

为什么会"整个服务不能用"：现在的形态是「一个插件 = 组合里的一条记录」，任何一条挂载失败都会带崩整个 profile 的启动，不是那一条自己报错、其余照常。已经崩了的话，把那条记录从当前 preset 的 agent.cordis.yml 里注释掉或删掉再重启就能回来（#708 是同一个情况，我在那边写了详细步骤）。

文件层面的限制，DSH 有官方的沙箱套件（@deepseek-ai/dsh-fs-sandbox 等），配合权限预设把 shell、写文件这类保留成"每次询问"，能挡住一部分误伤（#2421 那边我列过清单）。

但要说清楚：profile 隔离挡的是"插件把 profile 搞崩"，沙箱挡的是"写到不该写的地方"，都挡不住"agent 改坏了 DSH 自己的安装目录或配置" 这种情况。你要的那个"所有操作不能对 dsh 本身产生影响"的核心限制，真要做到得是进程/容器级隔离，那是官方的事——你这个 feature request 我觉得该提。

另外别用"第二个模型审批每次工具调用"那类插件当边界——它对"帮忙看着点"有用，但是模型判断，不是硬边界。

利益相关：我维护 pi2dsh，这条回复里全是 DSH 官方机制，跟我的包无关。