PTC 执行期限把人工等待当成程序执行时间：未作答的 ask_user_question 会被 120s 截止切断，模型继续自行执行

[sueccku]

PTC 执行期限把人工等待当成程序执行时间：未作答的 ask_user_question 会被 120s 截止切断，模型继续自行执行

提交渠道：GitHub Discussion → Q&A（该仓库 has_issues: false；现有分类为 Announcements / General / Ideas / Polls / Q&A / Show Your Plugins，没有 Bug Reports 分类）
已提交：#8368
产品：DeepSeek Harness Desktop 0.2.0-rc.2（Windows x64，打包安装版）
组件：@deepseek-ai/dsh-ptc-runtime-node（与 @deepseek-ai/dsh-tools 的 PTC 模式、@deepseek-ai/dsh-user-questions、@deepseek-ai/dsh-tool-ask-user 交互）
严重度：高（在用户未作答的情况下让 Agent 继续执行，等于把"超时"当成了许可）

---

摘要

PTC 模式下模型只能调用 run_code，它在程序里通过绑定调用 tools.ask_user_question(...)。该运行时的执行期限（默认 timeoutMs: 120000）会把这次人工等待计入程序执行时间：用户没在 120 秒内作答时，期限到期会

1. 先掐断嵌套的提问（UserQuestionError: ASK_ABORTED），
2. 再把 run_code 整体判为失败（code run failed (timeout): execution deadline reached (120000ms)），

而模型只看到一个 run_code 失败结果，看不到"问题仍然可回答、这是待答而非跳过"的信号，于是在未获得任何回答的情况下继续往下执行。

环境

项	值
DSH	0.2.0-rc.2（Electron 打包版，resources/app.asar）
平台	Windows x64
预设	ptc（PTC 模式）
相关默认值	dsh-ptc-runtime-node：timeoutMs: 120000，maxTimeoutMs: 600000
ask_user_question 模式	legacy（阻塞式、无自身的 deadline）

复现

在 PTC 预设的会话里，让模型把提问写进程序，例如：

const a = await tools.ask_user_question({
  questions: [{
    id: "variant",
    header: "选哪种插件",
    question: "你要装哪一种？",
    options: [
      { label: "本地插件（推荐）", description: "..." },
      { label: "云端插件", description: "..." },
    ],
  }],
});

然后什么都不点，等待 120 秒。

实际行为（会话日志原文）

来自本机会话日志（~/.dsh/sessions/<project>/<session>/session.v4.jsonl.zstd，zstd 多帧），已隐去会话 id：

seq 116  tool/call            run_code                     （提问写在程序里）
seq 117  tool/ptc-dispatch-start  ask_user_question        t=1790737406857
seq 119  tool/ptc-dispatch    ask_user_question  isError=true
         error: {"name":"UserQuestionError","code":"ASK_ABORTED"}
         content: "Error: ask_user_question was aborted before the user answered"
                                                            t=1790737526720  (Δ = 11986 ms ≈ 120 s)
seq 120  tool/result          callId=call_00_W9bhXFILBjZvnc2WAcJc6925
         "Error: code run failed (timeout): execution deadline reached (120000ms)"
         error: {"name":"CodeRunFailedError","code":"CODE_RUN_FAILED"}
seq 121  step/start           → 模型在新的一步里直接继续输出
seq 126  turn/end             reason={"kind":"aborted","reason":{"kind":"user"}}

同一模式在另一会话复现（seq 367-371）：同样是 ASK_ABORTED + execution deadline reached (120000ms)。

对照：同一台机器上 ask_user_question 作为顶层工具直接调用时（legacy 阻塞模式，schema 无 timeout 参数）等待时间没有上限——实测有 4.6 分钟后正常拿到回答的用例，不会自动继续。问题只出现在 PTC 嵌套调用里。

期望行为

人或审批的等待不应计入"程序执行时间"，或至少不应让模型在未作答时继续执行：

1. 首选：run_code 的执行期限遇到需要人工作答的绑定调用时暂停计时（或把这类绑定排除在期限之外）。人是不可压缩的延迟，"超时"在这里没有任何安全含义。
2. 次选：若保留期限，则到期时的 pending 语义必须显式冒泡到外层结果，让模型能够区分 {pending: true, callId}（问题仍可回答、不得视为许可）与真正的程序超时失败。当前 run_code 只返回 CODE_RUN_FAILED，模型只能猜。
3. 相关文档已经承认这块是未决设计：packages/.../ptc-runtime-node/README.md 的 Known Limitations 写明 "Execution is one-shot — no yield/wait API"，Dev Note 指向 architecture/2026-09-11-sandboxed-node-ptc-runtime.md#deferred-timeout-design，其中明确列出 "approval wait accounting" 为待定项。本 issue 提供该待定项的真实伤害证据。

为什么危险

• 期限到期即"放行"，模型接着执行未经用户批准的写操作/命令。本机另一次 PTC 会话里，被切断的问题正是"是否结束 317 个无窗口的自动化残留进程（约 35 GB）"——如果当时继续执行，代价不可逆。
• 与产品自身的语义冲突：dsh-tool-ask-user README 明确写 "A timeout is never approval"；但 PTC 路径下模型甚至拿不到"超时"这一事实，只拿到一个程序失败。
• 用户"想清楚再选"这一完全正当的行为，在 PTC 模式下会被自动降级为"沉默 → 继续执行"。

临时规避（用户侧）

• 在 profile 的 cordis.patch.yml 里给 ptc-runtime 行加配置，把预算提到上限：

  - id: ptc-runtime
    name: '@deepseek-ai/dsh-ptc-runtime-node'
    config:
      timeoutMs: 600000

  这只是把 2 分钟拉长到 10 分钟，仍是到点自动放行，不是修复。
• 或在 preset 的 tool-ask-user 行设 mode: timed 并让模型对"没有答案就不能继续"的提问传 timeout: -1（askTimed 走 ask()，不设 deadline）。这需要模型每次都判断正确。
• 或不把需要人工作答的调用写进 run_code（改用 standard 预设）。

复现所需材料

安装版 app.asar 无法用 shell 读取，以上全部证据取自本机会话日志（JSONL 中的 tool/call、tool/ptc-dispatch、tool/result 事件），字段与代码符号可直接在 0.2.0-rc.2 的构建产物里检索：

• @deepseek-ai/dsh-ptc-runtime-node/lib/index.js：controller.abort("execution deadline reached")、`execution deadline reached (${spec.timeoutMs}ms)`、timeoutMs: z.number().default(12e4)、maxTimeoutMs: z.number().default(6e5)
• @deepseek-ai/dsh-user-questions/lib/index.js：askTimed、ASK_TIMED_OUT → { pending: true, callId }
• @deepseek-ai/dsh-tool-ask-user/lib/index.js：pendingNotice（"No answer batch arrived before the timeout. This is pending, not a skipped answer. Continue useful independent work. … Do not treat this as permission."）

[argszero]

A plugin now covers this: @argszero/cordis-plugin-ptc-ask-timeout-advisor

I read the report's mechanism at the source and it holds end to end, so I built the missing half as a mountable plugin rather than waiting for a runtime change.

• npm: https://www.npmjs.com/package/@argszero/cordis-plugin-ptc-ask-timeout-advisor
• source: https://github.com/argszero/cordis-plugin-ptc-ask-timeout-advisor

The reading I built on

Three shipped literals carry the whole case:

Where	What
dsh-ptc-runtime-node	setTimeout(… controller.abort('execution deadline reached'), spec.timeoutMs); the run then reports { kind: 'timeout', message: 'execution deadline reached (<n>ms)' }
dsh-tools (ptc.ts)	that becomes CodeRunFailedError → CODE_RUN_FAILED, message code run failed (timeout): execution deadline reached (120000ms)
dsh-user-questions	the nested ask settles as ASK_ABORTED — abortedQuestion(): "ask_user_question was aborted before the user answered"

The model only ever reads the second. The first and third are what say why, and the ask tool's own contract sentence — "A timeout is never approval" — is exactly what the surviving text fails to convey. Your control measured this cleanly: the same question asked as a direct tool call is not on any program clock, so it waited over four minutes for a real answer.

What the plugin does

It wraps the public tools/execute waterfall — the one seam that also sees a program's nested sub-dispatches, because they go through the same registry pipeline — and keeps a ledger keyed by the call tree's rootCallId:

• a settled dispatch of ask_user_question that failed with ASK_ABORTED is recorded against its tree;
• a settled run_code that failed with CODE_RUN_FAILED and whose message matches execution deadline reached takes that record and calls exec.deferContext(…) with one user-role advisory: the question is ABORTED, not answered; a deadline is never approval, and is nobody's decision; do not perform the action it was gating; ask it again as a direct ask_user_question call outside the program, where no deadline is running; if the work cannot proceed, stop and hand it to the user.

Nothing else changes — no request is re-sent, no sandbox is widened, no session event is rewritten, and the transcript of the timed-out run stays exactly as the harness recorded it.

npm install @argszero/cordis-plugin-ptc-ask-timeout-advisor

- insert:
    - id: ptc-ask-timeout-advisor
      name: '@argszero/cordis-plugin-ptc-ask-timeout-advisor'
      config:
        mode: advisory   # or: warn (log only), off (register nothing)

What it deliberately refuses

Every gate narrows, because a false alarm here tells a model to re-ask a question the user already answered:

• a program that failed with its own exception (code run failed (exception): …) — its own diagnosis;
• a different timeout of the runtime's own, worded differently (e.g. compute budget exhausted) — only the run deadline is this plugin's business;
• a deadline with no aborted ask behind it;
• an ask the user answered inside the budget; and one that ended ASK_TIMED_OUT (a different outcome, whose answer channel stays open);
• a non-program call that fails with the same code and wording (bash, a composite tool) — the program-name gate;
• a second program in a tree that already spent its record — the record is taken, never read.

Evidence

test/seam.spec.mjs mounts the real dsh-tools registry, the real run_code transport and the real CodeRunFailedError, and drives a program backend that calls the very bindings ptc.ts built — so the plugin observes genuine scheduler.prepare → dispatch → finalize traffic and proves the reported sequence end to end, including that the nested settlement is visible before the program settles. Each refusal above has an arm of its own. 43 tests; npm run test:inject mutates the source and requires every mutation to be caught by a named arm (26 CAUGHT, 1 named EQUIVALENT, 0 SILENT, 0 skipped); npm run test:probe-lines installs one line per || segment of the peer range and runs the whole suite there (0.1.7-rc.2 and 0.2.0-rc.2, 43/43 on each).

Honest boundary

This is a stopgap and it settles nothing: it does not stop the deadline, restore the program, or answer the question. It removes one specific lie — that "a program failed" is the whole story. The preferred fix remains upstream, and there are two clean shapes for it: do not count a human wait against a program's execution budget, or surface the pending state in the program's own result, so the model learns it from the transport instead of from a plugin. If the runtime ever rewords execution deadline reached, this plugin stops matching and goes silent — the safe direction — rather than guessing that some other failure was a budget cut.