Problem
Always-On snapshot-copy workspace preparation can fail with:
workspace_prepare_failed: snapshot source size ... exceeds maxBytes ...
even when most of the size comes from directories that are supposed to be ignored, such as nested node_modules, dist, or .git directories.
In one local reproduction, the project root was about 1.5 GiB because it contained a nested PilotDeck/node_modules, while the meaningful source size after excluding ignored directories was only ~40 MiB. The run failed before workspace preparation with:
snapshot source size 1542602752 exceeds maxBytes 1073741824
Cause
SnapshotCopyProvider applies ignore rules inconsistently:
estimateSize() uses du -sk root, so the size cap check does not apply DEFAULT_IGNORES at all.
isIgnored() only checks the first relative path segment, so nested ignored directories like subproject/node_modules are not ignored during the fs.cp fallback path.
- After reflink/clonefile copy,
pruneIgnored() removes only top-level ignored directories and misses nested ignored directories.
Because the max-bytes check happens before copy/prune, the run can fail even though the actual snapshot should be small after ignores are applied.
Expected behavior
The same ignore policy should be used consistently for:
- snapshot size estimation,
fs.cp filtering,
- post-copy pruning after reflink/clonefile.
Ignored path names such as .git, node_modules, dist, .pilotdeck, and .pilotdeck-always-on should be skipped at any depth, not only at the project root.
Suggested fix
- Make
isIgnored() check all relative path segments, not only the first segment.
- Make
pruneIgnored() recursively remove ignored directories after reflink/clonefile copy.
- Replace the
du -sk root estimate with a directory walk that skips ignored directories, or invoke a platform-specific size estimator that applies the same ignore set.
Impact
This currently blocks Always-On execution for monorepo-like or nested-project layouts where a subdirectory contains its own node_modules, dist, or .git. The user sees a workspace preparation failure even though the ignored content should not be part of the isolated snapshot.
Problem
Always-On
snapshot-copyworkspace preparation can fail with:even when most of the size comes from directories that are supposed to be ignored, such as nested
node_modules,dist, or.gitdirectories.In one local reproduction, the project root was about 1.5 GiB because it contained a nested
PilotDeck/node_modules, while the meaningful source size after excluding ignored directories was only ~40 MiB. The run failed before workspace preparation with:Cause
SnapshotCopyProviderapplies ignore rules inconsistently:estimateSize()usesdu -sk root, so the size cap check does not applyDEFAULT_IGNORESat all.isIgnored()only checks the first relative path segment, so nested ignored directories likesubproject/node_modulesare not ignored during thefs.cpfallback path.pruneIgnored()removes only top-level ignored directories and misses nested ignored directories.Because the max-bytes check happens before copy/prune, the run can fail even though the actual snapshot should be small after ignores are applied.
Expected behavior
The same ignore policy should be used consistently for:
fs.cpfiltering,Ignored path names such as
.git,node_modules,dist,.pilotdeck, and.pilotdeck-always-onshould be skipped at any depth, not only at the project root.Suggested fix
isIgnored()check all relative path segments, not only the first segment.pruneIgnored()recursively remove ignored directories after reflink/clonefile copy.du -sk rootestimate with a directory walk that skips ignored directories, or invoke a platform-specific size estimator that applies the same ignore set.Impact
This currently blocks Always-On execution for monorepo-like or nested-project layouts where a subdirectory contains its own
node_modules,dist, or.git. The user sees a workspace preparation failure even though the ignored content should not be part of the isolated snapshot.