[P0 Performance] workspace-changes git snapshot blocks the first tool of every turn for 27–29 s in large repositories (tested on all 4 releases, including 0.2.2-alpha.3)

[liguanglab]

Summary

When a session's working directory resolves inside a git repository, @deepseek-ai/dsh-workspace-changes takes a full
working-tree snapshot at turn/start (git add --all --ignore-errors into a scratch index + git write-tree).
On a large repository this takes far longer than the plugin's 30 s timeoutMs, so the first top-level tool call of
every turn waits 27–29 s before it is dispatched. Later tools in the same turn are normal (0.0–0.2 s).

Not a network, model, MCP or bridge issue — the stalled time is spent inside git.exe children.

Environment

item	value
DSH	0.2.1-rc.2 (production), 0.2.2-rc.1, 0.2.2-rc.3, 0.2.2-alpha.3 (all reproduced)
Node	v24.11.0
git	2.56.0.windows.3
OS	Windows 11, 16 logical cores, SSD
repository	~6.8 GB working tree, ~86k files
session cwd	a subdirectory inside that repository
plugin timeout	timeoutMs = 30_000 (default)

Measured data

One real production session, 992 turns with tool calls:

metric	value
first-tool latency, median	27.3 s
first-tool latency, mean	47.5 s
turns with first-tool > 20 s	810 / 992 (81.7 %)
second and later tools in the same turn	0.0–0.2 s
model first token	median 2.4 s

Tool kind is irrelevant — it is always "the first tool of the turn":

tool	first-call span
read (native)	27.1 / 27.3 / 27.4 / 27.6 / 27.7 / 28.2 / 28.3 s
pwsh (native)	28.0 s
a third-party MCP tool	29.5 s
another MCP tool	27.1 / 27.2 s

Same numbers on every tested release (three runs each, plus an outside-repository control at 0.0 s):

version	first tool inside large repo	control outside any repo
0.2.1-rc.2	27.1–28.3 s	0.0 s
0.2.2-rc.1	28.8 / 28.8 / 28.9 s	0.0 s
0.2.2-rc.3	28.7 / 29.2 / 29.0 s	0.0 s
0.2.2-alpha.3	28.8 / 29.1 / 29.2 s	0.0 s

It is the repository, not the directory

Every row is a fresh blank session, same preset, same tool (a read of a small file), only cwd changed:

session cwd	files	size	inside git repo	first-tool span
plain directory	2	~0 MB	no	0.0 s
20,000 one-byte files	20,000	~0 MB	no	0.0 s
1 GB of markdown	1,000	992 MB	no	0.0 s
3,000 nested directories	3,000	~0 MB	no	0.0 s
1 empty file inside the repo	1	~0 MB	yes	28.4 s
original session cwd (deep in repo)	68,017	5,296 MB	yes	29.4 s

One empty file inside the repository costs 28 s; 20,000 files or 1 GB outside costs 0 s.
File count, text volume, nesting depth and ACLs were each ruled out as the cause.

Snapshot cost itself

git add -A executed exactly the way the plugin does it (empty GIT_INDEX_FILE):

command	warm	cold
whole working tree	36.7 s	136.2 s
excluding runtime data directories	4.1 s	—

The default timeoutMs = 30_000 is exactly why the observed stall lands at 27–29 s: the git child is killed at 30 s
and the turn proceeds without a snapshot.

Reproduction (~2 minutes)

Requires only a DSH instance and its API (session/create, sessions.prompt, session log). No bridge, no MCP, no QQ.

1. Pick any git repository whose `git add -A` (empty temp index) takes longer than 30 s.
2. Create a session whose cwd is inside it (a brand-new empty subdirectory is enough):
      session/create { "cwd": "<repo>/new/empty/dir", "agentPreset": "<any>" }
3. Ask it to call one cheap tool:
      "Call read once on <repo>/README.md (offset 1 limit 2), then reply OK."
4. In the session log, compute tool/result.time − tool/call.time:
      <DSH_HOME>/sessions/<session-id>/session.v4.jsonl.zstd
   Expected when fixed: < 1 s. Observed on all four versions: 27–29 s.

Independent confirmation: during the stall the DSH server has git.exe children running
add --all --ignore-errors, while the Node process itself shows no CPU and no file I/O.

Suggested fixes (by benefit / effort)

1. Move the snapshot off the critical path — take it after the turn's first tool dispatch, or in the background.
   A UI summary should not gate tools/execute.
2. Bail out fast on large trees — probe first (git status --porcelain -uno, or track file count/size) and skip the
   snapshot past a configurable budget (e.g. 2,000 files / 50 MB). maxFiles today bounds only the summary.
3. Reuse a persistent scratch index per session instead of a fresh empty one each turn, so unchanged files are not
   re-hashed.
4. Add an explicit opt-out (enabled: false, or a per-cwd exemption). Note that
   dsh-client-ui-deliverables currently requires the workspaceChanges service, so it must become tolerant of its
   absence (ctx.get('workspaceChanges') guard), otherwise disabling the plugin breaks that UI.
5. Adaptive timeout — if the first snapshot exceeds ~2 s, record it and skip snapshots for that cwd for the rest of
   the session (with one warning), instead of paying the cost every turn.

Notes

• Operator-side mitigation we applied (no code change): add runtime data dirs to .gitignore and
  git rm -r --cached them so they leave the index; tracked files 2,537 → 492. After that, the same session's first
  tool went from 27–28 s to 0.0 / 0.0 / 0.0 s (three consecutive runs).
• A DSH-side --inspect breakpoint inside snapshotTree was not completed, so the exact await site inside
  TurnRecorder.start() is inferred from the code path rather than directly observed. The blocking relationship itself
  is established by construction and by the observed git.exe children.

---

中文摘要

会话的工作目录落在一个大型 git 仓库内时，workspace-changes 插件在每轮 turn/start 用临时索引跑
git add --all --ignore-errors 做工作树快照。仓库大时这条命令要 36.7 s（热）/ 136.2 s（冷），远超插件默认
timeoutMs = 30 s，于是每轮第一个工具调用都被挡 27–29 秒（992 轮里 81.7% 首调超过 20 s，中位 27.3 s）。
与工具类型、模型、MCP、桥接无关；卡顿期间 DSH 进程零 CPU、零 IO，工作都在 git.exe 子进程里。

最小复现：仓库内放一个空文件的新目录 → 28.4 s；仓库外放 20,000 个文件或 1 GB 文本 → 0.0 s。
0.2.1-rc.2 / 0.2.2-rc.1 / 0.2.2-rc.3 / 0.2.2-alpha.3 四个版本全部复现，对照均为 0.0 s。

我们愿意配合官方进一步定位此问题，并可提供大体积仓库的极端测试环境。如有测试额度或合作意向，欢迎随时联系
（GitHub: @liguanglab）。