What problem are you trying to solve?
On Windows, the Copilot App stores everything under %USERPROFILE%\.copilot on
the OS drive (typically NTFS C:). That directory holds the most I/O-intensive
assets in the product:
repos\ — every cloned repositorycopilot-worktrees\ — a git worktree per sessionsession-state\, chats\, workspaces\, pkg\, media-cache\data.db (hundreds of MB) + rolling data.db.pre-update-backup-* copies,
session-store.db, and WAL files
If the machine has a Dev Drive (ReFS volume), install/first-run never
detects it and never offers it. Users end up running the heaviest part of the
product on the slower, often-fuller OS drive, and manually clone side repos onto
the Dev Drive to compensate — which the App then doesn't manage as its own data.
This is especially relevant for Copilot specifically, because a large share of
what it does is small-file I/O: grep/glob searches, reading many files to
build context, dependency installs, and builds. On Windows those are exactly the
operations most slowed by Defender real-time scanning — and Dev Drive
(ReFS + performance-mode antimalware + block cloning) is Microsoft's
recommended fix for that workload.
Measured gains for these workloads (Microsoft + independent benchmarks):
~14–28% faster .NET builds (copy-on-write / block clone), ~20–30% faster
git clone and package restore.
Refs: Engineering@Microsoft,
Visual Studio blog.
Proposed solution
During install and/or first-run on Windows:
- Detect Dev Drive volumes — e.g.
fsutil devdrv query <drive>, or
enumerate ReFS volumes and check the Dev Drive trust flag.
- If one exists, offer it as the storage/data root for App data (repos,
worktrees, caches, DBs), presented as "recommended for performance on
Windows," with the OS-drive default as the fallback.
- Persist the choice as a first-class configurable storage-root setting so
it isn't hard-coded to %USERPROFILE%.
- Provide a relocate/migrate action so existing installs can move their
data root onto a Dev Drive after the fact (DB, repos, and worktrees moved
safely).
Important trade-off to surface (not a blocker)
There is a known interaction with the local sandbox on Windows, documented
in github/copilot-cli#3712: the Windows Bind Filter (BFS) that enforces sandbox
policy does not work correctly on ReFS, so a working directory on a Dev
Drive plus the local sandbox currently fails with a backend_error. The
detection UX should be honest about this — if a user relies on the local
sandbox, warn that the sandbox and a Dev Drive data root are currently
incompatible and let them choose deliberately. For users who don't use the local
sandbox, the performance win is immediate and free.
Workflow impact
Affects any Windows developer with a Dev Drive (an increasingly common,
Microsoft-recommended setup). Today they either eat the OS-drive/NTFS penalty on
the App's heaviest workloads, or hand-roll workarounds the App doesn't track.
Smart detection + a recommended default would give them the documented
performance gains automatically, and keep the App's repos/worktrees/caches in the
right place without manual intervention.
This complements #208 (separate storage locations for repos vs worktrees): that
request is about manual path granularity; this one is about smart detection and
a recommended default. Both point at the same underlying need — first-class,
performance-aware storage configuration on Windows.
Installation context
Per-user Windows desktop install. Real setup this came from: Dev Drive at D:
(ReFS, ~250 GB) sitting idle while C:\Users\<user>\.copilot on NTFS C: was
down to ~60 GB free and holding all repos, worktrees, and multiple hundred-MB DB
backups.
Additional context
What problem are you trying to solve?
On Windows, the Copilot App stores everything under
%USERPROFILE%\.copilotonthe OS drive (typically NTFS
C:). That directory holds the most I/O-intensiveassets in the product:
repos\— every cloned repositorycopilot-worktrees\— a git worktree per sessionsession-state\,chats\,workspaces\,pkg\,media-cache\data.db(hundreds of MB) + rollingdata.db.pre-update-backup-*copies,session-store.db, and WAL filesIf the machine has a Dev Drive (ReFS volume), install/first-run never
detects it and never offers it. Users end up running the heaviest part of the
product on the slower, often-fuller OS drive, and manually clone side repos onto
the Dev Drive to compensate — which the App then doesn't manage as its own data.
This is especially relevant for Copilot specifically, because a large share of
what it does is small-file I/O: grep/glob searches, reading many files to
build context, dependency installs, and builds. On Windows those are exactly the
operations most slowed by Defender real-time scanning — and Dev Drive
(ReFS + performance-mode antimalware + block cloning) is Microsoft's
recommended fix for that workload.
Measured gains for these workloads (Microsoft + independent benchmarks):
~14–28% faster .NET builds (copy-on-write / block clone), ~20–30% faster
git cloneand package restore.Refs: Engineering@Microsoft,
Visual Studio blog.
Proposed solution
During install and/or first-run on Windows:
fsutil devdrv query <drive>, orenumerate
ReFSvolumes and check the Dev Drive trust flag.worktrees, caches, DBs), presented as "recommended for performance on
Windows," with the OS-drive default as the fallback.
it isn't hard-coded to
%USERPROFILE%.data root onto a Dev Drive after the fact (DB, repos, and worktrees moved
safely).
Important trade-off to surface (not a blocker)
There is a known interaction with the local sandbox on Windows, documented
in github/copilot-cli#3712: the Windows Bind Filter (BFS) that enforces sandbox
policy does not work correctly on ReFS, so a working directory on a Dev
Drive plus the local sandbox currently fails with a
backend_error. Thedetection UX should be honest about this — if a user relies on the local
sandbox, warn that the sandbox and a Dev Drive data root are currently
incompatible and let them choose deliberately. For users who don't use the local
sandbox, the performance win is immediate and free.
Workflow impact
Affects any Windows developer with a Dev Drive (an increasingly common,
Microsoft-recommended setup). Today they either eat the OS-drive/NTFS penalty on
the App's heaviest workloads, or hand-roll workarounds the App doesn't track.
Smart detection + a recommended default would give them the documented
performance gains automatically, and keep the App's repos/worktrees/caches in the
right place without manual intervention.
This complements #208 (separate storage locations for repos vs worktrees): that
request is about manual path granularity; this one is about smart detection and
a recommended default. Both point at the same underlying need — first-class,
performance-aware storage configuration on Windows.
Installation context
Per-user Windows desktop install. Real setup this came from: Dev Drive at
D:(ReFS, ~250 GB) sitting idle while
C:\Users\<user>\.copiloton NTFSC:wasdown to ~60 GB free and holding all repos, worktrees, and multiple hundred-MB DB
backups.
Additional context
limitation on Windows).
git/npm/NuGet cache guidance already steerdevelopers to place repos and package caches on a Dev Drive; the Copilot App
would benefit from the same defaults.