Windows desktop: first tool call in a new session (or after ~1 min idle) takes 20–30 s — tool runtime cold start

[lkfd246]

Windows desktop: first tool call in a new session (or after ~1 min idle) takes 20–30 s — tool runtime cold start

摘要（中文）

在 Windows 桌面版 DSH（nightly 0.2.2-rc.1）上，每个新会话的第一次工具调用（或空闲约 1 分钟后的第一次调用）固定要 20–30 秒；同一会话内后续调用只要 0.2–1 秒。已排除：插件（禁用全部第三方插件后仍 27.6s）、Agent 预设（标准/PTC/极简都慢）、权限/沙箱模式、DSH 版本差异（DS Bot 用同一个 dsh-base@0.2.2-rc.1 只要 0.12s）、沙箱 runner 本身（手动跑 0.23–0.39s）、Electron 子进程启动（0.17s）、精简 profile 启动（2.97s）。慢的既不是插件执行（protein_show 热态 0.03–0.06s），也不是 SSH/服务器连接。看起来是 Windows 桌面版工具执行运行时的冷启动成本，希望获得定位建议或预热/保活配置。

Environment

• OS: Windows (x64), DSH Desktop installed at C:\Users\HF\AppData\Local\Programs\DeepSeek Harness
• App version: @deepseek-ai/dsh-desktop@0.2.2-rc.1 (nightly channel, resources/app-update.yml)
• Core packages inside app.asar: @deepseek-ai/dsh-base@0.2.2-rc.1, dsh-web-app@0.2.2-rc.1
• Workspace: C:\Users\HF\Documents\deepseek-harness\default-workspace
• Session log: ~/.dsh/sessions/.../session.v4.jsonl.zstd (audited via tool/call → tool/result timestamps)
• Comparison app on the same machine: DS Bot (dsbot@0.3.2, also bundles @deepseek-ai/dsh-base@0.2.2-rc.1, but dependencies unpacked under resources/node_modules)

Reproduction

1. Start DSH desktop (or make sure no tool has run for > ~2 minutes).
2. Create a new task (Standard mode) and send any prompt that triggers one tool call, e.g.
   show the structure of C:\Users\HF\Desktop\SCCK-ATP_model.cif
3. Observe the delay between tool/call and tool/result in the session log (or the turn duration in the UI).
4. Then ask a second question in the same session (within ~1 min) — the tool call is fast.

Expected: first tool call < 1 s.
Actual: 20–30 s (turn total 33–44 s), every new session.

Measurements

1. First tool call in a brand-new session (cold)

Preset / config	First tool	tool/call → tool/result
standard	protein_show	27.55 s
standard (all third-party bundles disabled)	protein_show	27.61 s
minimal	pwsh	29.20 s
various earlier sessions	protein_show ×6	19.3 / 23.5 / 24.2 / 25.2 / 25.5 / 26.0 s
various earlier sessions	glob, skill, run_code ×2, windows_desktop, bash	25.9 / 22.9 / 27.9 / 24.8 / 28.4 / 21.6 s
first session after app restart	bash	21.60 s

2. Same session, subsequent tool calls (warm)

protein_show 0.03–0.06 s; bash 0.58 / 1.16 / 0.61 / 0.52 / 0.49 s; pwsh 0.23 s; glob 0.01–0.4 s; read 0.00 s.

3. Cold again after idle

Same session: 15:32:24 bash 0.61 s → idle ~85 s → 15:33:49 bash 27.76 s → 15:34:20 bash 0.52 s.

4. Only pure in-memory host-service tools are fast on first call

ssh_hosts 0.01 s, list_agents 0.12 s (no cold start).

5. Subagent sessions (same app) are fast

First tool in origin=subagent sessions: 0.00–0.60 s (e.g. read 0.00 s, bash 0.60 s), across 50+ sessions.

6. Control: DS Bot on the same machine

protein_show 0.00 s, read 0.12 s, pwsh 1.02 s, plugin_manager 4.63 s.

What we ruled out

Hypothesis	Evidence
The third-party plugin (dsh-protein-view)	Its execute is 0.03–0.06 s warm; slow tools include built-in glob/bash/skill/run_code; disabling all third-party bundles still 27.6 s
Agent preset (PTC vs standard vs minimal)	standard 27.55 s, minimal 29.20 s; PTC sessions 19–28 s
Permission preset / sandbox mode	workspace-write and danger-full-access both slow
Plugin count	Minimal preset mounts only 4 plugin groups — still 29.2 s
Sandbox runner	Manual ELECTRON_RUN_AS_NODE=1 "DeepSeek Harness.exe" <asar>/dsh/node_modules/@deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js --workspace <ws> --temp <tmp> --mode workspace-write -- cmd /c echo hi = 0.23–0.39 s
Electron child startup	ELECTRON_RUN_AS_NODE=1 "DeepSeek Harness.exe" -e "0" ≈ 0.17 s
DSH host boot	dsh web --port 61002 --no-open with a lean profile = 2.97 s to print its URL
SSH / server-connect plugin	Cold tool is local pwsh/protein_show; ssh_hosts itself is 0.01 s; disabling SSH tooling does not change it
DSH version	DS Bot embeds the same dsh-base@0.2.2-rc.1 and is fast

Suspect / questions

The delay sits between the tool/call and tool/result session events with no intermediate events (no approval event, no ptc-dispatch event). It affects every executing tool but not in-memory host-service tools, and it is paid per session (or per idle-reaped runtime), on Windows only in this install.

1. Is this the expected cold start of a tool-execution runtime process (e.g. a child that reloads the plugin tree from the 213 MB app.asar)? Is there a phase-level log/env flag we can turn on to see where the 20–30 s goes (dsh-subprocess-local / dsh-tool-executor-native / dsh-sandbox-local)?
2. Is there a supported way to prewarm or keep the tool runtime alive (configurable idle TTL / keep-alive), so the first tool call of a session is not 20–30 s?
3. Why is the bundled-dependency (app.asar) layout so much slower than DS Bot's unpacked resources/node_modules layout on Windows — could asar module loading be optimized or the runtime pre-warmed at app boot?

Notes

• Full session logs (zstd) can be provided if useful; timings above were extracted as tool/result.time - tool/call.time.
• No credentials or tokens are included in this report.

[PerryLink]

The 20-30 s is likely the pre-execute workspace snapshot.

The tool runtime is not the slow part. workspace-changes is mounted in the web-app composition (packages/bundle/web-app/cordis.patch.yml:389-390). Before a tool runs it waits for the turn snapshot: packages/deliverables/workspace-changes/src/index.ts:184 (await recorder.settled()), and the default timeout is 30 s (:52). The git work behind it uses the same bound (src/git.ts:56-57, with add --all and write-tree around :154-172).

That matches your shape: the first call in a session (or after the tree changed while idle) pays one snapshot; later calls reuse the settled result. DS Bot being fast is consistent if its composition does not mount workspace-changes.

A/B it: disable workspace-changes in the profile and repeat the same first call. If the gap disappears, that is the component. If it stays, the next suspect is the sandbox confine step, not the tool itself.

I read the source only; no Windows reproduction here.

You can hand this to an AI assistant to run the A/B and compare the two timings.

[lkfd246]

Confirmed — thank you, that was exactly it.

A/B result (Windows desktop, same machine, same prompt)

Setup: added - id: workspace-changes / disabled: true to the profile's
~/.dsh/profiles/desktop/cordis.patch.yml, restarted DSH, then created a fresh
Standard-mode session and measured tool/call → tool/result in the session log
(~/.dsh/sessions/*/session.v4.jsonl.zstd).

	first tool call in a new session	whole turn
workspace-changes enabled (before)	protein_show 27.55 s, 27.61 s; pwsh 29.20 s	33–40 s
workspace-changes disabled (after)	protein_show 0.04 s	7.71 s
same-session 2nd+ tool calls (before)	0.03–0.70 s (already fast)	—

So: one snapshot per fresh session (or after the tree changed while idle), then
everything is reused — your reading of the shape was exactly right.

Extra data on the cost side

The workspace is inside a git repo rooted at C:\Users\HF\Documents
(28,399 files / 472 MB in the session workspace). Measured directly:

• git status --porcelain 0.04 s
• git add --all (empty temp index) 2.06 s
• git write-tree 0.04 s

So git plumbing alone is only ~2 s; the remaining ~25 s looks like the
recorder's tree hashing / change manifest and the settled() wait. Also note
the first slow tool here was a read-only tool (protein_show) — it still
waited for the snapshot.

Questions

1. Is there a supported way to keep workspace-changes but make the
   pre-execute snapshot cheap — e.g. scope the snapshot to the session
   workspace instead of the enclosing repo, ignore globs / large directories,
   or a configurable snapshot budget above/below the 30 s bound?
2. Would it make sense to take the snapshot lazily (only before mutating
   tools, or in the background) instead of gating every tool call? A read-only
   tool call arguably does not need to wait for settled().
3. If we wanted to verify the size-dependence, would re-enabling it on a
   small standalone repo be the right test?

DS Bot being fast is consistent with your explanation (its composition does not
mount workspace-changes). Happy to provide the raw session logs or run any
further A/B you suggest.