Sustained explorer.exe working-set growth with TortoiseGit recursive status cache enabled

Browsing a large Git working tree in File Explorer with TortoiseGit overlay icons enabled can produce sustained growth in the Windows shell process private working set. The documented failure condition points to the shell extension's recursive status cache rather than Git itself, particularly when the cache tracks a broad set of paths under default monitoring behavior.

The controlling setting is the Status cache mode under Icon Overlays, which can be set to None, Default, or Shell. Default moves the cache to the external TGitCache process, while Shell keeps it inside explorer.exe. An unresolved decision is when a cached status becomes stale after a file-system change, an index update, or a branch switch. Trusting the cache too long leaves incorrect overlays; invalidating too eagerly forces repeated scans that may amplify memory retention.

Version sensitivity adds uncertainty because overlay handler registration and TGitCache behavior have changed across releases, so behavior observed on one TortoiseGit and Git for Windows pair may not transfer to another. Narrowing Include and Exclude paths reduces the tracked path count, but the invalidation strategy remains the core variable.

What invalidation triggers should the recursive status cache use after a file-system change, an index update, or a branch switch to avoid stale overlays without forcing re-scans? How does the choice between Default and Shell cache placement change the memory-accounting tradeoff in a large working tree? Which version-specific behaviors need confirmation before comparing cache growth across different TortoiseGit releases?