[BUG] macOS desktop app stamps custom folder icons (0-byte Icon\r files) on thousands of folders — breaks git fetch and Python venvs

Environment

• Claude Desktop (macOS): 1.40609.0, bundled Claude Code engine 2.1.247
• OS: macOS (Darwin 25.6.0), Apple Silicon-era Mac, single user account
• Heavy desktop-app usage: many concurrent Claude Code sessions/tabs with different working directories, plus launchd-scheduled headless sessions

Symptom

Since updating the desktop app (installed 2026-08-27), a background process of the app has been continuously stamping a custom folder icon on folders across the user's home directory:

• Creates a classic Icon\r file in each folder: 0-byte data fork, com.apple.FinderInfo (32 bytes) + com.apple.ResourceFork (163,057 bytes, identical size everywhere, containing an icns at offset 260)
• Sets the kHasCustomIcon flag (0x04 at byte 8) in the folder's com.apple.FinderInfo
• The stamped image is always the same: the stock macOS home-folder icon (blue folder with person silhouette) — as if NSWorkspace.icon(forFile: NSHomeDirectory()) were being written back via setIcon:forFile:options: onto every visited folder

Scale and cadence:

• ~20,000 Icon\r files in 3 days (2026-08-28 15:44 → 2026-08-31 09:35, still active when investigated), a slow continuous crawl day and night, folder by folder — including .git/objects/*, .git/refs/, Python .venv trees, and even .app bundles sitting in ~/Downloads
• Two earlier isolated occurrences with the same signature: 2026-05-11 (a repo root) and 2026-07-27 (a burst of 26 files in one subtree) — both in folders that Claude sessions were using on those dates

Attribution evidence

1. com.apple.provenance: every affected folder carries the same provenance value, e.g. 01 02 00 52 3B A0 18 62 9D 1B 4C. That 8-byte key is Claude Desktop's provenance key on this machine — files created in ~/Library/Application Support/Claude carry it, and a test file written by a Claude Code session running inside the desktop app receives the identical value. Other suspected apps on the machine (other AI browsers, a Stream Deck clone, Google Drive) have different keys or none.
2. Geography: only trees where Claude sessions work are affected (the main repo entirely, ~/Desktop, ~/Downloads, one knowledge-base subtree). ~/Documents, ~/Movies, ~/Music, ~/Pictures, ~/Library are untouched.
3. Timing: seeding bursts coincide to the second with background LocalSessions refresh entries in the app's own main.log (e.g. getPrChecks / tool-permission events at 09:35:44–49 ↔ Icon\r births at 09:35:45–48 on 2026-08-31). The mass seeding began the day after the desktop app updated.
4. The bundled native module claude-native-binding.node references the iconForFile: selector (icon read for UI); whatever performs the write was not identified from the outside.

Impact

• git broken: an Icon\r landed in .git/refs/ → every git fetch fails with fatal: bad object refs/Icon and worktree checkouts fail (rebindWorktree ... fatal: bad object refs/Icon). The desktop app's own main.log shows this error every ~10 minutes for over a day. 202 files total inside .git.
• Python venvs broken: 3,689 files landed inside venvs; one in docling_parse/pdf_resources/fonts/standard/ made all nightly PDF conversions fail for 3 nights with no FontName found ... /fonts//standard/Icon.
• Finder shows a bogus "home" icon on thousands of folders.

Reproduction

No user-triggerable repro found — it happens continuously in the background while the app is open, crawling the working directories of registered sessions/tabs and their surroundings. Nothing in the UI was used to set folder icons; the user never customized any folder icon.

Workaround

Daily cleanup script deleting 0-byte Icon\r files and clearing the kHasCustomIcon bit in affected folders' FinderInfo.

Notes

Happy to provide sanitized logs (main.log excerpts, provenance dumps, birth-time histograms) on request.