[Bug/修复建议] 会话中途切换 Full access 必定失败：持久 bash 存活时护栏无差别拦截，preset 半提交变 Custom

[zhongjjm-design]

环境

• dsh 0.1.0-rc.6（涉及包：@deepseek-ai/dsh-terminal-bash、dsh-permission-presets、dsh-client-ui-permission-presets、dsh-tool-bash-persistent），macOS
• 触发条件：部署组合包含 @deepseek-ai/dsh-tool-bash-persistent（持久 bash 工具）；与客户端形态无关，官方 web 组合该包后同样复现

复现步骤

1. 新建会话，保持默认 workspace-write + ask
2. 对话中让 agent 执行任意 bash 命令——此后该 agent 一直持有存活的持久 shell（PTY）
3. 在 composer 的 /permission 弹窗切换到 Full access
4. 完成风险双确认（勾选 + 启用）
5. 切换失败；无论重试多少次都同样失败，且权限选择器显示变为 Custom

错误信息：

cannot change sandbox mode from "workspace-write" to "danger-full-access" while persistent terminal sessions are open or being created; wait for creation to settle and close them first

根因（源码 + 会话日志定位）

1. dsh-terminal-bash 的 ensureSandboxModeFence()：只要 owner 有存活 PTY，任何 sandbox/mode 变化都会在 internal/dispatch 中抛错——护栏不区分「放宽」与「收紧」方向。但放宽方向其实无需拦截：旧 shell 只是不能继续用，杀掉后下次调用会按新模式重建（与现有超时重置同一路径）。
2. dsh-permission-presets 的 apply() 先 append permission/preset 事件、再 setSandboxMode() / setApprovalPolicy()。setSandboxMode 被护栏抛错后，preset 事件已写入日志、两个 knob 却没变——选择器于是推导出 custom，留下一个既不是旧预设也不是新预设的悬挂状态。
3. 会话日志中的证据链（多次尝试完全一致）：command/run (permission danger-full-access) → permission/preset: danger-full-access → command/done kind:"error"。
4. UX：风险确认门在选项阶段不检测存活 PTY，用户走完双确认后才收到面向开发者、不可操作的报错。

用户视角的体感：会话中途想从「边确认边写」切到 Full access，怎么点都改不了。

修复建议

1. 放宽方向（如 workspace-write → danger-full-access）：重置该 owner 的持久 shell 后放行；下次 bash 调用按新模式的 argv 重建（可复用现有超时重置路径）
2. 收紧方向保留护栏（安全上必须拦截），但报错文案改为可操作（提示关闭终端或新开会话）
3. 原子化：sandbox/mode 写入失败时回滚 permission/preset，避免 custom 悬挂态
4. UI 预检：/permission 弹窗在选项阶段检测存活 PTY，直接置灰并说明原因，而不是双确认后才失败

已验证的本地补丁（rc.6）

--- a/packages/terminal-bash (ensureSandboxModeFence)
+++ b
+const SANDBOX_MODE_PERMISSIVENESS = { "read-only": 0, "workspace-write": 1, "danger-full-access": 2 };
 ...
 if (event.data.mode === currentMode || !state.pty.hasOwnerActivity(owner)) return;
-throw new Error(`cannot change sandbox mode from "${currentMode}" to "${event.data.mode}" while persistent terminal sessions are open or being created; wait for creation to settle and close them first`);
+const rank = (mode) => SANDBOX_MODE_PERMISSIVENESS[mode] ?? -1;
+if (rank(event.data.mode) > rank(currentMode)) {
+    for (const snapshot of state.pty.list(owner)) {
+        state.pty.kill(owner, snapshot.sessionId, `sandbox mode widened from "${currentMode}" to "${event.data.mode}"; the persistent shell will respawn under the new mode on next use`).catch(() => {});
+    }
+    return;
+}
+throw new Error(`cannot tighten sandbox mode from "${currentMode}" to "${event.data.mode}" while this conversation still has a live persistent shell spawned under the wider mode; close the terminal or start a new session first`);

打补丁后原场景一次切换即成功，下次 bash 自动以新沙箱参数重建 shell；收紧方向仍被正确拦截。

如果方向上认可，我可以按这个思路提 PR（会按仓库源码结构移植，而非直接改构建产物）。

[12362566]

+1 不过我叫ai写了个小插件解决这个问题 https://github.com/12362566/dsh-exit-bash

[Cfomodz]

Duplicate of #523

[ttbj2023]

+1，遇到完全相同的问题，补充我这边的复现和验证。

环境：WSL2 (Ubuntu) + 官方 web 组合，会话默认 workspace-write + ask，挂载持久 bash 工具。

现象：

• agent 跑过任意一条 bash 命令后，会话中途切 Full access 必定失败，报同样的 cannot change sandbox mode ... while persistent terminal sessions are open or being created；
• 任务全部结束后依然切不了——没有任何活跃任务也不行：持久 PTY 只是闲置存活，而用户侧没有任何手动关闭它的入口（"close them first" 实际上只对模型侧执行 exit 生效）；
• 半提交状态同样复现：approval/policy 的 ask↔never 能正常切换，sandbox/mode 被拦，权限选择器随后显示 Custom。

验证过的 workaround：让 agent 在 bash 工具里执行 exit（或等命令超时重置）后立刻切换，马上成功；之后下一次 bash 调用会按新模式重建 shell。说明"放宽"方向完全不需要硬失败——close-then-switch 即可。

修复建议（优先级排序）：

1. 切换时自动 close-then-switch：先关闭该 owner 的持久 shell，再提交 sandbox/mode；同时把 preset 事件的写入挪到两个 knob 都成功之后，消除 Custom 悬挂状态；
2. 或给 tool-bash-persistent 增加空闲回收（类似 idleReset），任务结束一段时间后自动关闭；
3. 或至少给用户侧一个「关闭会话终端」的入口或命令。

另外这个帖子和 #523 看起来不是同一个问题（#523 是 minimal preset 在 Windows 越权写入的安全问题），建议重新归类，避免这个 UX/状态一致性 bug 被重复标记埋掉。

[usernameisnotavaliablee]

same in #6429

[zhangys11]

补充复现：0.1.5-rc.1 上仍然存在，且失败在 Web UI 层完全静默

环境：dsh 0.1.5-rc.1，macOS arm64 / node v24.16.0；默认 agent preset 为自定义组合（挂载 dsh-terminal-bash + dsh-tool-bash-persistent 持久 shell）；Web UI（dsh-client-ui-conversation）。

排除前端因素，直接调 host 的 commands/execute（与 composer 同一条路径）：

/permission                    → success: "current preset workspace-write (available: read-only, workspace-write, danger-full-access)"
/permission danger-full-access → gateway/internal: cannot change sandbox mode from "workspace-write" to "danger-full-access" while persistent terminal sessions are open or being created ...
/permission                    → success: "current preset workspace-write"   (仍旧值)

session 日志证据链与楼主一致：

command/run       { name: "permission", args: " danger-full-access" }
permission/preset { preset: "danger-full-access" }     # 半提交
command/done      { kind: "error", text: "cannot change sandbox mode ..." }

两点补充：

1. 半提交的派生结果取决于 preset 表。在 base 组合（read-only / workspace-write / danger-full-access）下，半提交后 derive() 会回退到 workspace-write 而不是 custom，但日志里确实留下了一条没有配套 sandbox/mode 的 permission/preset 事件（0.1.5-rc.1 仍未修复）。无论派生显示哪个，根因相同：先写 preset、再写 knob，knob 失败不回滚。
2. 失败在 UI 层没有任何提示。dsh-client-ui-conversation 的 PermissionSelect.submit 只做 .catch(() => false).then(() => setPick(null))，既不检查 ok / value.matched，也不弹 notice。除非去翻 session 日志，否则看不到 "persistent terminal" 这条错误。建议在选项阶段预检之外，至少把 command() 的失败结果 surface 出来。

workaround 这边也确认：让 agent 在 bash 里执行 exit（或等命令超时触发 reset）后立刻切换即可成功，下一次 bash 调用会按新模式重建 shell——与前面 ttbj2023 的结论一致，也支持"放宽方向 close-then-switch 即可，不必硬失败"的修复建议。

同族：#6429（read-only → workspace-write 方向同样被这条 fence 拦下）。