Session prune gives no visible progress, leading to repeated invocations #5432

Describe the bug

/session prune can appear to do nothing while it is actually deleting sessions for several minutes. There was no obvious acknowledgement or progress feedback indicating that cleanup had started and was still running.

I ran the command a few times because I thought it had failed. Only checking the local session directories independently revealed that deletion was progressing.

This report concerns missing user feedback during pruning and the confusing behavior of repeated invocations, not a claim that pruning failed overall.

Affected version

GitHub Copilot CLI 1.0.109

Steps to reproduce the behavior

1. Use the CLI on Windows with a substantial existing session history. In this case, 224 local session directories had workspace.yaml activity timestamps older than one month.

2. Run:

   /session prune --older-than 31 --include-named
   

3. Observe that it appears nothing happened: there is no obvious indication that cleanup is in progress.

4. Run the same command again, believing the first invocation failed. I submitted it several times.

5. Independently inspect the local session directories. The count of old sessions keeps decreasing:

   Observation (UTC)	Old session directories remaining
   Before the command	224
   08:48:44	199
   08:49:24	158
   08:50:57	13

These observations were made on 2026-11-12. The counts measure directories with old activity timestamps, not the command's own reported candidate or deletion counts.

Expected behavior

• Immediately acknowledge that pruning has started, ideally with the number of eligible sessions.
• Show progress or at least an ongoing busy indicator while cleanup runs.
• Finish with a clear summary of deleted, skipped/in-use, and failed sessions.
• If another prune is already running, explicitly say so, or serialize/coalesce repeated requests rather than leaving the user unsure whether each invocation did anything.

Additional context

• Windows 11 Pro, version 10.0.22631.

• The practical impact is that a destructive operation looks like a no-op, encouraging users to repeat it.

• The process log also contained repeated warnings with the following shape:

  Failed to delete session workspace directory
  {"error":"Workspace not found: <session-id>"}
  

  Some IDs appeared more than once. It is not established whether these warnings came from overlapping invocations, stale records, or another cause.

• No raw session history or process logs are attached.