Q: The "Edited N files" card counts every workspace change during the turn, not only this session's edits

[cinast]

What the card shows vs. what it means

The “Edited 11 files / +381 −479” card after a turn reads as “files this session edited”. In a git workspace it is actually every file whose content changed in the workspace during that turn, regardless of who changed it.

Observed case (Desktop 0.2.0-rc.2, Windows 11, web profile): session 507f3e73… worked on unrelated files, and its turn-end card listed docs/env/comfyui-sd.md, docs/INDEX.md, docs/exp/shoucang/*, wsccripts/… — files being written by a different session running concurrently in the same workspace. Nothing was corrupted; the card just attributed the other session's edits to this turn.

Why it behaves that way — @deepseek-ai/dsh-workspace-changes (dsh/node_modules/@deepseek-ai/dsh-workspace-changes/lib/types/recorder.js):

• start(turn) takes a git tree snapshot of the workspace at turn start (snapshotTree);
• at turn end it takes another snapshot and runs diffTrees(baseline, end);
• whole-file captures (capture.js) exist only for paths a file tool is about to mutate, to serve per-file diffs;
• its own header comment: “Per-Session turn recorder: snapshots, captures around file-tool edits, the turn-end diff…”; and: “A working directory outside any repository… gets no snapshot; its summary lists the files the file tools changed.”

So the summary is workspace-scoped, while the UI label is session-scoped. Two sessions (or a session plus a background script, or the user editing in an editor) share one workspace, and each turn's diff picks up everyone's writes.

Impact

• A session can be credited with edits it never made (this report), or miss its own edits if they are overwritten/reverted later in the same turn.
• With concurrent agents this is the normal case, not an edge case: any long turn spans the other agent's commits.
• The same repo can also be listed differently depending on whether the turn ran inside a git repository (diff vs. file-tool list), which is another thing users cannot see.

Suggestion (either is fine, both are cheap)

1. Filter the summary to paths mutated by this session's own tool calls (the recorder already captures exactly those paths); optionally show a second line “+N files changed by other sessions/processes”.
2. Or keep the diff but relabel the card as “Workspace changes during this turn”, with a hint that concurrent sessions share the workspace.

Documenting the git-repo vs non-repo behavior difference would also close the surprise in the second bullet of “Impact”.

Not filing this as a bug: the diff itself is correct, the attribution is what reads wrong.

[IlyaKhalafi]

Separate Git worktrees provide a workaround for the current snapshot behavior. Ordinary subdirectories don't isolate it, because locateGitWorkspace resolves each session's directory to the repository root.

From the repository, create a worktree for each task and open each session in its corresponding directory.

git worktree add -b task-a ../project-task-a HEAD
git worktree add -b task-b ../project-task-b HEAD

These start from committed HEAD. Existing uncommitted changes are not copied into them.

One caveat with filtering to captured paths is that captures cover filesystem-tool mutations, not arbitrary shell writes. That filter would lose shell-only edits. It also wouldn't establish ownership when another process changes a path this session captured.

So I'd favor your workspace-scoped label for the existing metric. Worktrees reduce interference between concurrent sessions without presenting the diff as proof of which session made each edit. Another process writing into the same worktree would still appear.

I checked the current snapshot helpers with real Git on Linux. A write in another subdirectory appeared in the first session's delta; a write in another worktree didn't. These were helper-level checks, not a Windows Desktop test.

[cinast]

Worktrees being separate git roots explains it — thanks, that is a usable workaround today.

Two notes from our side: (1) for us the practical damage was the label, not the diff — a turn that only touched docs/ showed "10 files" because two other sessions were writing in the same working tree, so readers concluded the agent had edited files it never opened; (2) we would still vote for the cheap half of the fix (filter by this session's tool-call paths, or relabel the card), since "use a worktree" is a repo-layout change that most users will not make. We recorded the mechanism and the workaround in our local notes.

[cinast]

Thanks — the worktree caveat and the shell-only-writes point both land, and they change my preference.

You are right that filtering to captured paths is not a safe fix: it drops shell edits and still cannot attribute a path another process wrote into a captured file. Dropping that suggestion; keeping the metric with a workspace-scoped label (your option 2: "changes in this workspace during the turn", with the concurrency caveat).

On worktrees: agreed they reduce interference without pretending to be attribution. Recording it as the recommended isolation workaround for concurrent sessions, with your two caveats — (a) they start from committed HEAD and uncommitted work is not carried over; (b) a writer inside the same worktree still shows up in that session's delta.

Also noting your test scope so nobody over-reads it: helper-level checks with real Git on Linux, not a Windows Desktop run. I am on Windows Desktop; if I reproduce the subdirectory case there I will add it here.

No action requested — recording the outcome is enough. I will update the issue body to "label change, not data fix".