copilot-cli sessions trigger save right on startup

[jrieken]

• configure "chat.restoreLastPanelSession": true,
• have a copilot-cli session with changes to files in your workspace
• have a local session without any changes (e.g plan mode, simple question)
• reload window
• 🐛 you get a bunch of save-participant notifications which is because the copilot-cli integration "restores/finds" the worktree and triggers save on each file

Screen.Recording.2026-03-24.at.13.08.50.mov

AI Investigation

---

Root Cause (from log analysis)

A stale copilotcli chat session is restored at window startup. The restore/close cycle
triggers a file save in a Copilot git worktree, which runs save participants (e.g., ESLint).

Timeline from logs (20260324T111939/window1)

11:19:43.140  ext host starts
              GitHub.copilot-chat activated via "onChatSession:copilotcli"
11:19:47.213  [MainThreadChatSessions] untitled-style sessionResource detected
              copilotcli:/untitled-973a2487-f022-4304-bbf6-95a7420ed5fb
11:19:47.338  [CopilotCLI] Workspace initialized: 9329111c... (checkpoints: 0)
11:19:47.936  [CopilotCLI] Closing session 9329111c...
11:19:48.435  copilotcli session resource detected AGAIN
~11:19:48.4   ← FILE SAVE TRIGGERED (back-calculated: 54.079s − 5.625s)
11:19:51.118  ESLint library loaded from worktree node_modules/
11:19:54.079  ESLint "Computing fixes during save" warning (5625ms)

Key observations

1. Only copilotcli sessions affected — windows 2–5 activated via onChatSession:claude-code and showed no save activity.
2. Saved file was in a Copilot git worktree: vscode.worktrees/copilot-steep-weasel/src/vs/editor/contrib/quickAccess/browser/gotoSymbolQuickAccess.ts
3. No editor was open — ESLint loaded from worktree first (11:19:51), main repo ESLint not until 11:36:02.
4. Session initialized and closed in ~600ms with checkpoints: 0 — stale session restored and immediately torn down.
5. ESLint ran as save participant taking 5625ms — causing visible progress/notification.

Expected Behavior

Restoring/closing a stale copilotcli session at startup should not trigger file saves or save participants.

VS Code Version

VS Code Insiders 1.113.0, Copilot Chat 0.41.2026032301

[lszomoru]

@jrieken, you say that the copilot-cli session is against the workspace, but then you say:

copilot-cli integration "restores/finds" the worktree and triggers save on each file

did you mean worktree or workspace? How is a worktree involved here? Am I missing something?

[jrieken]

Sorrt, worktree is what I mean. So, while I am on "normal mail" I get save events for files from a past worktree. The long tail is that vscode.TextDocument instances get created, which triggers TS and other extensions doing things.

[lszomoru]

Adding @DonJayamanne as well since he might know which code path created vscode.TextDocument instances.

[jrieken]

Also make sure to check the AI Investigation in the description of the issue. I went through all the logs and analysed the issue

[jrieken]

This seems to happen via loadRemoteSession which replays and re-accepts changes for each and every file in a session. That will eventually trigger _doAccept which forces save participants. The save-participants make sense for local session but not when restoring, not when something is remove

[jasonperry1231hou-lang]

Thanks for digging into this and analyzing the logs. That explanation about loadRemoteSession and _doAccept makes a lot of sense — especially how it unnecessarily triggers save participants during restore.

…

On Tue, Apr 7, 2026, 8:07 AM Johannes Rieken ***@***.***> wrote: *jrieken* left a comment (microsoft/vscode#304443) <#304443 (comment)> This seems to happen via loadRemoteSession which replays and re-accepts changes for each and every file in a session. That will eventually trigger _doAccept <https://github.com/microsoft/vscode/blob/d4282d8c84c8b4479f5f7f70a0d86efac5b98525/src/vs/workbench/contrib/chat/browser/chatEditing/chatEditingModifiedDocumentEntry.ts#L265> which forces save participants. The save-participants make sense for local session but *not* when restoring, not when something is remove — Reply to this email directly, view it on GitHub <#304443 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7VP3SO23KSTW4HDBADGZOL4UT4PXAVCNFSM6AAAAACW5L4YYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOJZGE3DSMZVGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>