disk-hygiene: cloud-sync placeholders are unprotected, unhinted, and counted as reclaimable bytes — deleting one destroys the org's cloud copy

[kyle-sexton]

Filed by an agent session after a live /disk-hygiene:clean run on Windows 11. Every measurement below was taken on the audit host; the reproduction script is included.

Summary

The engine's only structural defense against cloud-sync content is is_linkish() (skills/clean/scripts/hygiene.py:116-124), which treats a Windows reparse point as protected. Measured on this host, the dominant OneDrive dehydrated-placeholder class carries no reparse bit when read through the interpreter the engine actually runs, so the whole subtree is walked, every placeholder is recorded as an ordinary file with protected_reasons: [], and its logical_size is the full remote byte count while local occupancy is roughly zero.

Combined with name protection being exact-match, that makes a tenant OneDrive tree the single most attractive target in a home audit while reclaiming nothing — and deleting a placeholder propagates the delete to the organisation's cloud copy.

Measured

Measured	Value
Tenant sync root	C:\Users\<user>\OneDrive - <Org>
Root is_linkish()	False — subtree is walked
Files walked	1101
Dehydrated placeholders	872
Their logical_size total	13,770,936,008 bytes
Of those, is_linkish() == True	0 of 872

Byte totals reconcile exactly: 13,770,936,008 dehydrated plus 236,643,717 hydrated equals 14,007,579,725.

Read this part before judging — the attribute depends on the reader

This is the detail that will otherwise make the report look wrong.

• Through CPython os.lstat, and through raw GetFileAttributesW via ctypes: st_file_attributes = 0x400020 — FILE_ATTRIBUTE_ARCHIVE (0x20) plus FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS (0x400000). FILE_ATTRIBUTE_REPARSE_POINT (0x400) is clear.
• Through .NET — both Get-ChildItem enumeration and System.IO.File::GetAttributes — the same files by path report 0x401620, with the reparse bit set.
• The 227 hydrated files split the same way: 0x20 versus 0x420.

So if you verify this in PowerShell you will see the reparse bit set and conclude is_linkish() already protects the tree. It does not, through the reader the engine uses. Please verify with os.lstat on the engine's own interpreter, not through a shell.

We are deliberately not claiming the reader is the discriminator — it could equally be a per-process cloud-files awareness difference. We have not proven a general API rule and do not want to assert one.

Reproduction, run against any OneDrive tenant folder:

import os, ctypes
root = r"C:\Users\<user>\OneDrive - <Org>"
RECALL = 0x400000
for dirpath, dirnames, filenames in os.walk(root):
    for name in filenames:
        p = os.path.join(dirpath, name)
        st = os.lstat(p)
        attrs = getattr(st, "st_file_attributes", 0)
        win = ctypes.windll.kernel32.GetFileAttributesW(ctypes.c_wchar_p(p))
        if attrs & RECALL:
            print(hex(attrs), hex(win), st.st_size, p)

Name protection reaches no cloud root but one literal

has_protected_name() (hygiene.py:201-205) is casefolded exact equality, and the baseline protects the literal name OneDrive only. Verified by script:

• OneDrive — PROTECTED
• OneDrive - Melodic Software — NOT PROTECTED
• OneDrive - Contoso — NOT PROTECTED
• iCloudDrive — NOT PROTECTED
• Dropbox — NOT PROTECTED

Microsoft documents the OneDrive for Business sync root as C:\users\<username>\OneDrive - <organization name> and states the tenant display name portion cannot supportedly be changed, so this is the standard shape, not an edge case.

Why the byte accounting makes it worse

preview sums logical_size into logical_bytes (hygiene.py:1419-1423) and an apply report would claim those bytes as logical_bytes_removed (hygiene.py:1848-1852). A report can therefore honestly claim ~13.8 GB removed while the observed free-space delta is ~0 — and the skill's own summary caveat about "concurrent disk activity, sparse files, hard links, compression" explains that away instead of surfacing it.

Meanwhile SKILL.md step 2's positional-triage rule points straight at the directory: it instructs treating "any loose root-level entry that is not in protected_exact_names and does not belong to a recognizable app/config convention" as suspicious. OneDrive - <Tenant> is exactly that entry.

The only remaining defense is model judgment — step 2's "could this be a shell/cloud-sync folder? If uncertain, keep it." That is a process control standing in for a deterministic one that is available one line from code already reading the attribute.

Suggested fix, root cause first

1. Treat RECALL_ON_DATA_ACCESS | RECALL_ON_OPEN | OFFLINE as a hard protection in hard_protection(), contributing a cloud-placeholder reason. Closes OneDrive, iCloud eviction, and Dropbox online-only in one predicate, using an attribute is_linkish() already reads.

   Validation warning: in the Python-visible attributes for these files, OFFLINE (0x1000) and SPARSE (0x200) are not present — only the RECALL bit is. If you validate the OFFLINE clause against a OneDrive placeholder it will never trip, and dropping it would silently lose the iCloud and Dropbox eviction states it exists for. Validate through os.lstat.

2. Emit a per-entry size_qualifiers list so a placeholder's logical_size can never be read as reclaimable local bytes.

3. Secondary, not a substitute: add cloud-sync roots to the baseline as name globs (OneDrive - *, iCloudDrive, Dropbox, Box, Google Drive). Note consumers cannot self-remediate this today: protected_exact_names is not overlay-extensible, and an overlay may only add additional_protected_path_globs (hygiene.py:416-455), which are matched relative to the scan target — so a standing ~/.claude/disk-hygiene.json protects these only when the target happens to be home. The baseline has to ship it.

Scope of verification

Single host, Windows 11, one tenant. iCloudDrive and Dropbox were shown unprotected by name; their attributes were not measured. macOS untested.

[kyle-sexton]

Verified — reproduced on the same host, with one correction to the suggested fix

Every measured claim in this report reproduces. Ran through os.lstat on the engine's own interpreter as instructed, not through a shell.

Reproduction of the report's measurements

Target C:\Users\<user>\OneDrive - <Org>:

Measured	Reported	Reproduced
Root is_linkish()	False	False
Files walked	1101	1101
Dehydrated placeholders	872	872
Their logical_size total	13,770,936,008	13,770,936,008
Of those, is_linkish() == True	0 of 872	0 of 872
Hydrated bytes	236,643,717	236,643,717

Attribute histogram through os.lstat: {0x20: 227, 0x400020: 872, 0x180026: 2}. The placeholder value is 0x400020 — ARCHIVE | RECALL_ON_DATA_ACCESS — with REPARSE_POINT (0x400), OFFLINE (0x1000), and SPARSE (0x200) all clear, exactly as the report warns. GetFileAttributesW via ctypes agrees with lstat on every sampled file. The only delta from the report is hydrated file count: 229 rather than 227, because two files read 0x180026 (PINNED | UNPINNED plus HIDDEN | SYSTEM | ARCHIVE) rather than plain 0x20. Byte totals reconcile exactly: 13,770,936,008 + 236,643,717 = 14,007,579,725.

Name protection confirmed as described: protected_exact_names ships the literal OneDrive only, has_protected_name() is casefolded exact equality, and OneDrive - <Org> matches nothing. In a depth-1 scan of the user home the entry's protected_reasons is [] while its siblings OneDrive and Documents both carry baseline-protected-name.

No cloud-sync placeholder was deleted or hydrated at any point; every probe used os.walk / lstat only.

One correction: RECALL_ON_OPEN must NOT be in the predicate

Suggested fix 1 proposes RECALL_ON_DATA_ACCESS | RECALL_ON_OPEN | OFFLINE. Including RECALL_ON_OPEN is a false-positive source and the fix as merged omits it.

FILE_ATTRIBUTE_RECALL_ON_OPEN is 0x00040000 — the same number as FILE_ATTRIBUTE_EA — and Microsoft documents RECALL_ON_OPEN as appearing "only in directory enumeration classes (FILE_DIRECTORY_INFORMATION, FILE_BOTH_DIR_INFORMATION, etc.)", while every attribute read in the engine comes from lstat (File Attribute Constants). Read through lstat the bit therefore means "has extended attributes".

Measured negative control, 412,270 entries across three non-cloud trees:

Tree	Entries	Flagged with RECALL_ON_OPEN included	Flagged without it
A repo checkout	3,323	0	0
AppData\Local\Temp	272,238	1,536	0
~\.claude	136,709	16	0

The flagged entries are fully-local .NET build output (bin/Debug/**/*.dll) and temporary .node files. Including the bit would protect precisely the artifacts this engine exists to reclaim. With it excluded the control is zero false positives, and the tenant tree still flags correctly.

One finding the report did not have: the directories carry no cloud attribute at all

This changes the shape of the fix. Probing directories under the same sync root:

• the sync root itself: 0x31 — no reparse bit, no recall bit
• all 99 subdirectories: 0x10 (plain DIRECTORY) — zero carrying any recall or offline bit

So an attribute predicate protects placeholder files only. A fully hydrated tenant folder would have no protected descendant at all and would stay deletable — and deleting it still destroys the organisation's cloud copy. That promotes suggested fix 3 (name coverage) from "secondary" to non-optional, and it is the reason the fix ships both halves rather than the attribute predicate alone. The report's point that consumers cannot self-remediate checks out in code: additional_protected_path_globs are matched against a path relative to the scan target (hygiene.py:714, :1392), so a standing overlay protects such a root only when the target happens to be its parent.

Fix, and what it measures after

PR incoming. Three parts, matching the three suggestions with the correction above:

1. hard_protection() contributes a cloud-placeholder reason from OFFLINE | RECALL_ON_DATA_ACCESS, derived from the same single lstat per ancestor that is_linkish already takes, so the walk's stat load is unchanged and the protection reaches scan, preview, handoff-verify, and apply's pre-removal recheck at once.
2. Every entry records file_attributes and a size_qualifiers list, so a placeholder's remote logical_size can never be read as reclaimable local bytes. Additive per-entry trace only — no aggregate's definition changes here, since disk-hygiene: hint matching is misanchored and case-sensitive, byte accounting cannot express "unknown", and five smaller findings from a live audit #1806 asks for the reclaimable-bytes figure specifically.
3. The baseline gains protected_name_globs holding OneDrive - *, matched casefolded via fnmatchcase so the verdict does not depend on the host's case rules, plus Box, Dropbox, Google Drive, and iCloudDrive as exact names.

Same tenant tree, before and after the fix:

	Before	After
Files with protected_reasons: []	1,071 (13,893,811,832 bytes)	229 (236,643,717 bytes — the genuinely local, hydrated files)
Entries carrying cloud-placeholder	0	842 (13,657,168,115 bytes)

(842 rather than 872 because 30 placeholders sit under two Music subtrees an existing name protection already truncates.)

Depth-1 home scan, the scenario in the report: OneDrive - <Org> moves from protected_reasons: [] to baseline-protected-name. Pointing the engine directly at the tenant root now returns invalid-or-blocked — "protected shell-folder and profile-hive roots are not valid audit targets" — instead of scanning it.

SKILL.md step 2's positional-triage rule is also corrected: it named protected_exact_names as its filter, which would have walked straight past this entry even after the fix, so it now reads the entry's own protected_reasons.

Scope of what was verified here

Single Windows 11 host, one tenant, same host class as the report. The four non-OneDrive sync roots were confirmed unprotected by name, but their file attributes were never sampled — they are protected on name alone and their placeholder behaviour remains unverified. macOS untested.

[kyle-sexton]

Correction to the name list in my previous comment

Two of the four exact names from suggested fix 3 are not shipping, after checking them rather than taking them forward:

• Box — rejected. A protected name applies at every depth, and a protected directory is never traversed and reports logical_size: 0, which is byte-identical to a genuinely empty directory. Box is a common enough directory name in source trees that protecting it would make ordinary directories untraversable and silently zero-sized — a new instance of exactly the blind spot disk-hygiene: hint matching is misanchored and case-sensitive, byte accounting cannot express "unknown", and five smaller findings from a live audit #1806 finding 2 raises, introduced into the same plugin.
• Google Drive — rejected as a legacy name. Current Google Drive for desktop streams to a virtual drive letter (G: by default on Windows, Drive for desktop settings), not to a folder under the user profile. That name belongs to the retired Backup and Sync client.
• Dropbox — kept, and widened. Dropbox documents the folder as Dropbox (Personal) or Dropbox (<business name>) as well as the bare name (Locate your Dropbox folder), so the exact name alone would have missed the documented shapes. A Dropbox (*) glob ships alongside it.
• iCloudDrive — kept, marked unverified. Its exact default folder name could not be confirmed from an official Apple page in two attempts, so it is protected on name alone and recorded as unverified rather than asserted.

Shipping list: globs OneDrive - * and Dropbox (*); exact names Dropbox and iCloudDrive. Only the OneDrive class was measured on the audit host.

[kyle-sexton]

Three review corrections landed on PR #1818

• A scan target that itself carries a recall/offline bit no longer blanket-marks its tree. hard_protection's ancestor walk runs up to and including the target, so such a target marked every entry cloud-placeholder — and scan_tree truncates any directory with protections, collapsing the whole walk with no diagnostic. Same failure the mount-point branch already guards against, so it takes the same exemption: ancestors below the target still contribute, and the target's own entry still reports the reason, so the condition stays visible rather than being swallowed. Pinned by a test asserting both halves.

• SKILL.md §3 now names size_qualifiers. It described byte reporting without it, so an agent could still total a qualified entry's logical_size as reclaimable — the exact misreading the field exists to prevent. It now states that logical_size is reclaimable local bytes only when size_qualifiers is empty, and that qualified bytes are reported separately with their reasons.

• iCloudDrive corrected to iCloud Drive. Apple documents the Windows path as C:\Users\[username]\iCloud Drive, with a space. The name I shipped would have matched nothing.

The Dropbox (*) glob was already in the PR — Dropbox documents both Dropbox (Personal) and Dropbox (<business name>) — alongside OneDrive - *. Google Drive stays out: the current client streams to a virtual drive letter rather than a profile folder, so a folder-name protection is the wrong instrument for it.

Suite: 233 tests, 0 failures. Skill-quality gate PASS, markdownlint clean.

The two cheap extras from the review (parameterizing the forged-snapshot test, exposing cache_clear for baseline_protected_name_globs) are not done — the drain was cancelled and I am winding down. Neither affects correctness: the forged-snapshot glob case is already covered by its own dedicated test, and nothing at runtime mutates the bundled baseline the cache reads.