Welcome to dsh-ops Discussions!

[T-Auto]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[YUsaltyfish]

喵

[Thatgfsj]

喵

[Nicholas023]

喵

[little3tar]

喵

[FuRongJun-1999]

喵

[ding0ronghao]

我踩的坑，供参考

工具恢复了 —— 而且我把这次的根因彻底查清了。这不是 dsh-ops 的锅，是 DSH 内置权限插件里的一个初始化死锁，dsh-ops 只是踩响了这颗地雷。

一、工具现状：已恢复

read / pwsh / glob / list_agents / 记忆写入都正常了。和你观察到的一致 —— 关掉 dsh-ops 就恢复。我确认了 profile 现在的状态：

位置	dsh-ops
package.json → dependencies	✅ 还在（^0.3.0，375 个包都装着）
package.json → dsh.profile.bundles	❌ 已移除 ← 这才是"关闭"的实质

所以它是"装好了但没启用"，真正生效与否只看 bundles。

二、根因：一个不可自愈的鸡生蛋死锁

我把 app.asar 里内置的 @deepseek-ai/dsh-permission-presets 源码抠出来读了，逐字命中了你截图里的那行报错：

pinInitialPermission(session) {
    const state = this.permissionState(session);
    const { preset, sandbox, approval, seeded } = state;
    if (preset === "auto") {
        if (this.autoAdmit === void 0)
            throw new Error('permission: cannot restore preset "auto" without its active integration');
        this.autoAdmit();
    }
    ...

而它是在自己挂载的时候就地遍历已有会话的：

ctx.on("session/created", (session) => { this.pinInitialPermission(session); });
for (const session of ctx.sessions.list()) this.pinInitialPermission(session);   // ← 凶手

于是形成闭环：

permission-presets 挂载
   └─ 发现已有会话 preset="auto"
        └─ 但 autoAdmit 还是 undefined
             └─ throw → permission-presets 激活失败
                  └─ 它本该提供的 permissionPresets 服务从未注册
                       └─ 唯一调用 registerAuto() 的 auto-review
                          永远 pending (waiting for service: permissionPresets)
                            └─ autoAdmit 永远是 undefined  → 回到第 2 行，锁死

关键点：registerAuto(admit) 的唯一调用者是 @deepseek-ai/dsh-experimental-auto-review（在 bundles 里确实有它），而它必须等 permissionPresets 服务存在才能注册。可 permissionPresets 又因为 autoAdmit 为空而挂掉。两条腿互相踩着对方，谁都起不来，重启也没用。

这也解释了为什么连 read、pwsh、subagent 全都报同一个错：PermissionPresetService 的 static inject 里包含 sessionProjections，这条链一断，所有依赖它的工具一起失效 —— 就是你看到的 cannot get required service "sessionProjections" in inactive context。

三、地雷的确切位置（已找到）

它藏在会话的持久化状态里，不在配置文件里：

~/.dsh/storages/session_projcache/sessions/session-a4c73caf-….json（就是当前这个会话）

"permissions": {
  "preset": "auto",
  "sandbox": "danger-full-access",
  "approval": "ask",
  "seeded": true
}

也就是说：你之前把权限切到了 "auto"，这个选择被持久化了。 之后只要启动时这个会话被恢复，permission-presets 就会在挂载阶段撞上 preset === "auto" 而炸掉。

⚠️ 这颗地雷现在还armed着 —— 我刚查过，preset 仍是 "auto"。所以只要你把 dsh-ops 一开回来，极可能立刻再炸一次。

（另外还有 3 个 2026-10-13 的旧会话也存着 auto：2bc18638、5bfe6513、9dd5da2a。但它们不在当前 workspace 的会话列表里，ctx.sessions.list() 大概只看得到当前 workspace 的 8 个，所以决定性的就是当前这个会话。）

四、关于「dsh-ops 为什么引爆它」

这部分我必须如实区分证据等级：

• 已证实（源码直接证据）：抛异常的确切条件、死锁环、auto 的持久化位置。
• 只是推断（未实机验证）：dsh-ops 的 cordis.patch.yml 用 - insert: 往加载树里插了 4 行（dsh-ops-shell / -file / -background / -ptc），这改变了挂载顺序/时序。它本身一个字节都没碰过权限预设（我 grep 过它的 lib/，只匹配到一条无关的注释）。

所以更准确的说法是：地雷早就埋好了，dsh-ops 只是让挂载顺序变了一点点，踩响了它。 卸掉它，时序回到原来，地雷就不再被触发。

五、安全的重新启用步骤（纯 GUI，不用命令行）

如果你想继续用 dsh-ops，顺序很重要 —— 必须先拆雷，再开插件：

1. 先把当前会话的权限从 auto 切走。
   在输入框工具栏点那个 「Permission」 按钮（就是 /permission 命令的图形入口），选一个具名预设。可选项和代价：

   选它	sandbox	approval	说明
   danger-full-access	danger-full-access	never	与你现在的沙箱一致，但关掉了每次审批
   workspace-write	workspace-write	ask	保留审批，但写入范围收窄到工作区

   你现在实际是 danger-full-access + ask（这正是 auto 推导出来的组合）。具名预设里没有这个精确组合 —— 这是切走 auto 的代价，你得挑一个更接近的。

2. 确认切成功后（工具栏显示的权限标签不再是 auto / 自动），再回到 设置 → 插件列表 把 dsh-ops 装回来。

3. 如果又炸了，关掉 dsh-ops 就能回到现在这个可用状态 —— 这个退路已验证有效两次。

六、我需要你决定

我没有擅自去改会话 JSON（那属于运行中的会话状态，程序内存里握着一份，手改会被覆盖，而且风险更高），也没有擅自把 dsh-ops 装回来 —— 在雷还armed着的时候重装，几乎必然再砖一次。

请告诉我你想怎么做：

• A：先切权限、再重装 dsh-ops —— 我给你逐步盯着，装完立刻验证工具是否正常；
• B：干脆不用 dsh-ops 了 —— 我可以把它从 dependencies 里彻底清掉（375 个包，省空间），profile 回归干净；
• C：先不动，就这样用 —— 目前一切正常，只是 dsh-ops 的能力没有。

顺带一提，我上一轮修的 pnpm 那个问题（minimumReleaseAgeExclude 里 dsh-mcp-connector 重名遮断）修复完好无损，我刚复查过那行仍是合并后的 dsh-mcp-connector@0.2.73 || 0.2.74，而且 dsh-ops 正是靠它才装进 dependencies 的 —— 那条修复是有效的，只是被这个权限死锁挡住了最后一步。