[Bug 报告] minimal 预设：沙箱模式下持久 PTY shell 无法启动（PTY shell exited during startup / Cannot launch conpty）

[Rex-V233]

Summary

在 Windows 上，minimal（极简模式）预设挂载的是持久 PTY shell
（dsh-tool-pwsh-persistent + dsh-terminal-bash，shellDialect: pwsh）。

当权限预设的沙箱不是 danger-full-access（即 workspace-write / read-only）时，
任何 shell 调用都会立即失败：

Error: PTY shell exited during startup

同一台机器、同样带沙箱的情况下，standard（标准模式）预设的 pwsh 工具完全正常——
因为它用的是 dsh-tool-pwsh（一次性子进程），不经过 ConPTY。

影响：用户只要选择「极简模式 + 任意带沙箱的权限预设」，命令行能力就完全不可用，
而且错误信息不指向真正的原因（看起来像 shell 坏了，实际是 PTY 建不起来），
排查成本很高——我自己追查这个问题花了很久，中途还被"会话档案损坏"等无关线索带偏。

---

Reproduction

前置条件

Windows，且未安装 PowerShell 7（C:\Program Files\PowerShell\7\pwsh.exe 不存在）——
此时 resolvePwshPath() 按设计兜底到 %SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe（5.1）。
该 shell 本身完全可用（标准模式下正常工作）。

最小复现（经 DSH）

1. 新建会话，代理模式选 minimal（极简模式）
2. 权限预设选 workspace-write（或任何 sandbox !== danger-full-access 的预设）
3. 让模型调用 pwsh 工具执行任意命令（例如 echo test）
4. 立即返回 Error: PTY shell exited during startup，重试无效

对照实验（三次，均在同一台机器上）

#	代理模式	权限预设	沙箱	结果
1	minimal	workspace-write	workspace-write	❌ 失败
2	minimal	danger-full-access	danger-full-access	✅ 成功
3	standard	auto-approve	workspace-write	✅ 成功

第 2 行与第 1 行只差沙箱模式 → 沙箱是判别条件。
第 3 行证明：带沙箱 + 标准模式没问题 → 问题只在「持久 PTY × 沙箱」这个组合。

更底层的最小复现（绕开 DSH，直接用 node-pty）

在 DSH 沙箱（workspace-write）下用一次性 pwsh 工具执行：

// node v24.x + node-pty 1.2.0-beta.15（DSH 自带的那份）
const pty = require('<dsh>/node_modules/node-pty');
pty.spawn(
  'C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe',
  ['-NoLogo', '-NoProfile'],
  { cols: 80, rows: 24, cwd: process.cwd(), env: process.env }
);
// → 抛: Cannot launch conpty

附带说明：ConPTY 的 agent 文件存在
（node-pty/prebuilds/win32-x64/conpty/conpty.dll、OpenConsole.exe，约 110 KB / 1.0 MB），
所以不是文件缺失，而是创建伪控制台这一步被拒绝。

---

Current behavior

报错位置

dsh-terminal-bash/lib/index.js:440：

if (result.waitReason === "session_exit") throw new Error("PTY shell exited during startup");

即 waitReason === "session_exit"（顶层 shell 已退出），而非启动超时。

主机日志没有记录真正的失败

%APPDATA%\DSH Desktop\logs\host\ 下只有良性警告，没有 PTY spawn 失败的记录：

[W] [local-subprocess-runtime] subprocess-local is using weaker process-tree containment
    because Windows ConPTY remains outside Job containment; ...

这使得用户/维护者无法从日志定位问题。

统计证据

对一份 46 轮的完整会话日志，按调用时生效的沙箱模式分组统计 pwsh 工具结果：

沙箱模式	pwsh 结果
danger-full-access	成功 40 次，失败 0 次
workspace-write	失败 33 次（仅最早 5 次成功，发生在服务重启之前）

与第三方插件无关

排查中一度怀疑是第三方审批插件，已排除：上面的对照组第 3 行就是
workspace-write 沙箱 + 该审批插件同时启用，工作正常。

---

Expected behavior

按优先级，以下任一即可：

1. 极简模式在 workspace-write 下 pwsh 能正常工作（首选）；
2. 若 ConPTY 在受限环境下确实无法创建，在启动阶段给出可诊断的错误——
   明确指出"当前沙箱模式与 PTY 后端不兼容"，而不是笼统的 shell exited during startup；
3. 提供后端回退：沙箱启用时自动降级到非 PTY 的一次性 shell
   （dsh-tool-pwsh 已经证明该路径在沙箱下可用）。

---

Environment

项	值
DSH 版本	0.1.5-rc.2
桌面客户端	dsh-plugin-desktop 2.0.13
OS	Windows (win32)
Node	v24.18.1（宿主）/ v24.21.0
PowerShell 7	未安装 → 兜底到 Windows PowerShell 5.1（resolvePwshPath() 设计行为）
node-pty	1.2.0-beta.15（随 DSH 分发），win32-x64 prebuild，仅含 conpty，无 winpty 回退
相关包	dsh-terminal-bash / dsh-pwsh-local / dsh-tool-pwsh-persistent / dsh-tool-pwsh / dsh-agent-presets，均为 0.1.5-rc.2

预设差异（关键）

dsh-agent-presets/presets/minimal/agent.cordis.yml：

# 第 30 / 50 / 57 行
- id: terminal-pwsh
  name: '@deepseek-ai/dsh-terminal-bash'
  disabled: !!js process.platform !== 'win32'
  config:
    shellDialect: pwsh
    timeoutMs: 300000

- id: persistent-pwsh
  name: '@deepseek-ai/dsh-tool-pwsh-persistent'
  disabled: !!js process.platform !== 'win32'

dsh-agent-presets/presets/standard/agent.cordis.yml：

# 第 49-51 行
- id: tool-pwsh
  name: '@deepseek-ai/dsh-tool-pwsh'
  disabled: !!js process.platform !== 'win32'

PTY shell exited during startup 这句错误只出自 dsh-terminal-bash，
而只有 minimal 会加载它。

一点未经证实的推测（仅供定位参考，请勿当作结论）

猜测方向：Windows 沙箱可能使用受限令牌（restricting SID）+ Job 对象，
导致 ConPTY 的助手进程（OpenConsole.exe）无法创建。
我没有直接证实这一点——我能证实的是"沙箱模式是判别条件"

---

附：可用的规避方式

1. 用户侧：改用 standard（标准模式）——命令行可用，同时保留沙箱；
2. 用户侧：自定义一个 preset，把 minimal 的 shell 行换成 dsh-tool-pwsh（与 standard 相同），
   放在 <DSH_HOME>/.agent-presets/<id>/ 下即可，无需改动安装目录、升级不会被覆盖；
3. 上游：若采纳上面的 Expected behavior 第 2 或第 3 条，则用户无需任何变通。

[argszero]

Thanks for the three-arm control — the fact that minimal × danger-full-access succeeds while minimal × workspace-write fails, and that standard succeeds under the same sandbox, is what makes this diagnosable rather than guessable. Your priority-2 item ("if ConPTY genuinely cannot be created under confinement, say so at startup instead of a bare shell exit") is now available as a plugin, without a core change.

@argszero/cordis-plugin-sandbox-grant-advisor@0.2.0 — https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor · source: https://github.com/argszero/cordis-plugin-sandbox-grant-advisor

npm install @argszero/cordis-plugin-sandbox-grant-advisor

Mount it as a patch row (- insert: [{ id: sandbox-grant-advisor, name: '@argszero/cordis-plugin-sandbox-grant-advisor' }]) and no configuration is needed.

What it does. One listener on the public tools/post-execute waterfall. When a tool result settles as an error whose message is PTY shell exited during startup (matched on a whole line — a line that merely contains the sentence is something quoting it), it resolves the sandbox mode the failing call actually ran under, through ctx.sandboxPolicy.resolve({ session }) — the same resolver terminal-bash calls before spawning — and, only when that mode confines, attaches one durable user-role advisory per agent beside the failure:

Persistent shell failed to start — command execution is unavailable in this session, and retrying cannot fix it.
… pwsh is a PERSISTENT PTY session …, and this session's sandbox mode is workspace-write — not danger-full-access. A confining mode spawns the shell through the sandbox, and there the terminal backend cannot create the pseudo-console at all, so the child exits before its first prompt.
Do NOT retry, and do not look for a command that fixes it: every attempt will fail identically, and there is no shell to run a command in. Use your file read/write tools instead, and hand the choice below to the user.

1. switch the agent preset to standard, whose shell tool is a one-shot subprocess (no PTY) …; 2. override the preset-minimal row in your profile patch, replacing its persistent-shell group with @deepseek-ai/dsh-tool-pwsh; 3. run with danger-full-access (prefer 1 or 2).

So the model stops spending turns on a retry that cannot succeed, and the user gets your arm-3 remedy (the non-PTY one-shot path) without the model having to invent it.

Three decisions worth stating, because each one is a way this could have been wrong:

1. The mode gate is not optional. The diagnosis is the mode, so under danger-full-access the plugin says nothing — the same failure there is a broken or missing shell, and your row 2 shows the mode is the discriminator. When the mode is not confining, or cannot be resolved at all (no sandboxPolicy mounted, no session on the agent, a resolver that throws), the failure is left byte-identical and a warn line on the host log records that the diagnosis was withheld — otherwise "not the sandbox's doing" and "could not tell" look the same from outside.
2. It never hands the model a command or a fallback tool name. There is no shell to run a command in, and minimal mounts exactly one platform-selected persistent shell with no one-shot fallback, so naming @deepseek-ai/dsh-tool-pwsh as a tool to call would be advice to call something the failing composition does not mount. That is why the two remedies above are addressed to the user (a preset/patch change), while the model's instruction is to stop.
3. The blocking half does not apply to this family (it is ACL-only by construction). The other signature this plugin handles — the Windows SetNamedSecurityInfoW failed (Win32 5): grantWrite(<dir>) ACL failure from [BUG REPORT] Windows 沙箱无法在用户自建目录上 provision 工作区 ACE → 该目录下所有 shell 命令失败 #7538/[Bug] Windows: `windows-acl` rung is auto-selected without a probe, but its host-side write grant always fails without SeSecurityPrivilege #7622/[Bug] Windows: after upgrading to 0.1.7-rc.1 every shell command fails at the ACL grant with `SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)` / 升级到 0.1.7 后所有 shell 命令在沙箱授权阶段立即失败（粘性，需手工修 ACL） #7646 — is repairable while the session continues, so a bounded fail-fast is safe there. Here the remedy is a change made between sessions, so refusing calls could only pad a session that is already unable to do the thing being refused.

Honest limits. The core-side asks remain open: ideal is still (1) minimal working under confinement, and (3) a backend fallback to a non-PTY shell when the sandbox is on. This plugin only makes the failure legible in the meantime; it changes no preset, no mode, and no backend. It was built and tested on macOS, so the Windows path itself is not witnessed here — what is tested is the decision layer (classification, the mode gate and its fail-closed paths, once-per-agent delivery, the wiring to a real cordis context and the real ToolRuntime) against fixtures carrying the producers' exact text. Your environment is inside the declared range: the suite is probed against the newest build of each admitted line (0.1.2-rc.1, 0.1.3-alpha.2, 0.1.5-rc.3, 0.1.6-alpha.2, 0.1.7-rc.1 — the 0.1.5 line covers your 0.1.5-rc.2), which is why the range is stated in full rather than as ">= 0.1.2".

One thing this does not fix, which your report is right to flag: the backend still logs nothing about the PTY spawn failure, so Cannot launch conpty never reaches the host log. The plugin adds the mode and the failing combination to that log from the tool-result side, but the spawn-time record belongs where the spawn happens.

[Rex-V233]

Follow-up with the Windows witness: remedy 2 is verified working on Windows.

I replaced the persistent-shell group at the preset level — a user preset under <DSH_HOME>/.agent-presets/ rather than a profile patch, so nothing in the installed tree is touched and an upgrade cannot clobber it — and ran it in a fresh session on the same machine that produced the report, with the sandbox at workspace-write.

The shell tool executed normally. No PTY shell exited during startup.

So the Windows matrix is now:

preset × sandbox	shell
minimal × workspace-write	❌ persistent PTY fails to start
minimal × danger-full-access	✅
standard × workspace-write	✅
minimal with the persistent-shell group replaced by @deepseek-ai/dsh-tool-pwsh × workspace-write	✅

That makes remedy 2 a verified workaround on Windows rather than a plausible one, and it is the same non-PTY row standard mounts — i.e. the path the advisory points users at does work under confinement.

The whole preset is minimal's persona plus this, with preset.yml carrying only name / description / order:

- id: tool-bash
  name: '@deepseek-ai/dsh-tool-bash'
  disabled: !!js process.platform === 'win32'

- id: tool-pwsh
  name: '@deepseek-ai/dsh-tool-pwsh'
  disabled: !!js process.platform !== 'win32'

DSH's own preset scanner accepts it as a healthy user preset alongside the shipped ones, so this needs no core change and survives upgrades.

One caveat worth stating, because it is a real behavior change rather than a drop-in: the replacement is a one-shot shell, so there is no state across calls — cd and variables do not persist. That matches standard, but it means this preset is "minimal's prompt, standard's shell", not "minimal with a working persistent shell". A genuine fix still needs the persistent PTY to work under confinement, or a backend-level fallback to a non-PTY shell — the two core asks from the original report that remain open.

[Rex-V233]

Thanks for reading it that closely, and for building this — the mode gate and the fail-closed paths are the right shape for this failure, and the point about the spawn-time record belonging where the spawn happens is exactly the gap.

Being straight with you: I'm probably not going to install it, and the reason is that the failure no longer reproduces on my machine. Both remedies I applied are on Windows:

1. standard — the one-line remedy, and it works. That's what I'm running right now.
2. Your remedy 2, but at the preset level instead of a profile patch: a user preset at <DSH_HOME>/.agent-presets/minimal-pwsh/ that keeps minimal's persona and nothing else, but mounts @deepseek-ai/dsh-tool-pwsh instead of the persistent-shell group. Nothing in the installed tree is touched, so an upgrade can't clobber it, and DSH's own preset scanner accepts it as a healthy preset alongside the shipped ones.

So I can't give you the Windows witness your plugin needs — that's the honest reason, not a verdict on the plugin. Testing the decision layer against fixtures carrying the producers' exact text is the right thing to have tested; it's specifically the Windows path that you can't witness from your side.

Two things from your reply I think are worth keeping visible in this thread:

• The spawn-time record. Agreed that anything reconstructed from the tool-result side is a workaround for a missing log line, not a substitute for it. Cannot launch conpty never reaching the host log is part of why this took so long to narrow down — the first stretch of my own debugging went into looking for evidence that was never being written. The host log only had the benign ConPTY remains outside Job containment warnings, which point away from the actual failure.

• The core asks stay open: minimal working under confinement, and a non-PTY backend fallback when the sandbox is on. Until one of those lands, every Windows user who picks minimal plus a confining mode walks into the same wall, and what stands between them and a long dead end is either a preset edit or your advisory.

If I hit it again on another machine I'll come back with the result. Thanks again for taking the report seriously.