fix: the codesign detritus was never iCloud — correcting my own attribution - #444
Merged
Conversation
…bution PR #440 added a retry around the top-level codesign and explained the failure as iCloud: "~/Documents is a Desktop & Documents container, the file provider re-stamps com.apple.FinderInfo between the strip and the sign." That is wrong. I asserted it from `brctl status` showing an active container, without checking whether this repo was in it — and against `check_no_duplicate_sources.sh`, which had already investigated the same theory and written "long assumed to be iCloud; that is unproven and probably wrong". I contradicted an existing finding without reading it. Verified since: * Desktop & Documents sync is OFF — no Desktop/ or Documents/ under ~/Library/Mobile Documents/com~apple~CloudDocs * ~/Documents is a plain directory, not a symlink into a container * SOURCE files carry no com.apple.fileprovider at all, only macl and provenance. Only BUILD OUTPUT had it. * `brctl status` reporting one idle CloudDocs container says nothing about whether this path is managed by it The real cause was already documented in this file, twenty lines above the code I added: signing a nested bundle regenerates _CodeSignature/CodeResources on its parent, and the parent picks up provenance + FinderInfo from the macOS file-creation path. My change is the top-level instance of that, and citing that very comment while attributing it to iCloud was the error. The retry itself is unaffected and still correct — it mitigates the race whatever creates it. What changes is the diagnosis someone would act on: the old failure message told them to pause iCloud or move the build out of ~/Documents, which would have wasted their time. It now tells them to check WHICH xattr is present, and notes that provenance is tolerated by codesign and is never the culprit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
JasonYeYuhe
added a commit
that referenced
this pull request
Aug 18, 2026
…4 of ~10 dirs (#445) A QA build failed today with the exact error this guard exists to prevent: 'LocalSessionServer 2.swift' — invalid redeclaration of 'LocalSessionServer' The guard DID catch that one (HelperSwift/Sources was on its hardcoded list) — but the list had gone stale, and six more duplicates were sitting unseen in HelperSwift/Tests. Enumerating every Package.swift shows the four literal paths covered 4 of ~10 compiled directories; HelperSwift/Tests, SensorProbe/Tests, both MachineRootHelper dirs and CLI Pulse Bar/codexbar were all unscanned. SwiftPM compiles Tests/ exactly as it compiles Sources/. A hardcoded allowlist of build inputs is the same trap as the QA bundle-id allowlist and the UserDefaults migration prefixes: adding a package silently drops it out of coverage and nothing says so. The list is now discovered from Package.swift locations, so a new package is covered the day it lands. An empty discovery result now FAILS rather than silently passing, since "scanned nothing" and "found nothing" would otherwise be the same green tick. before: 1 of 7 duplicates reported after: 7 of 7 FORENSICS ON THE SPECIMEN, since the origin has been "unknown" for weeks * `LocalSessionServer 2.swift` birth AND mtime 2026-07-23; the original was recreated 2026-08-03. The duplicate is the OLDER file. * NOT byte-identical: 58,580 vs 59,716 bytes. * `diff` is one-directional — 20 lines exist only in the original, ZERO exist only in the duplicate. It carries no unique work, so deleting loses nothing. (Checked before removing, as the guard's own message instructs.) * No xattrs at all — no com.apple.fileprovider, no provenance. Combined with the correction in #444 (Desktop & Documents sync is OFF, ~/Documents is a plain directory), iCloud remains unsupported as the cause. * Absent from all four .claude/worktrees, so a parallel worktree is not the source either. Origin still unidentified. Two theories are now positively excluded rather than merely doubted, which is progress the next investigation does not have to redo. All 7 quarantined to a backup before deletion. HelperSwift: 719 tests, 0 failures afterwards. The QA build that started this now succeeds. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What I got wrong
#440 added a retry around the top-level codesign and explained the failure as iCloud: "
~/Documentsis a Desktop & Documents container, the file provider re-stampscom.apple.FinderInfobetween the strip and the sign."That is wrong. I asserted it from
brctl statusshowing an active container without checking whether this repo was in it — and againstcheck_no_duplicate_sources.sh, which had already investigated the same theory and written:I contradicted an existing finding without reading it.
Verified since
Desktop/orDocuments/undercom~apple~CloudDocs~/Documentscom.apple.fileprovideron source filesmacl+provenance. Only build output had itbrctl statusThe real cause was already in this file
Twenty lines above the code I added:
My change is the top-level instance of exactly that. Citing that comment while attributing the cause to iCloud was the error.
What changes, and what doesn't
The retry is unaffected and still correct — it mitigates the race whatever creates it, and the three-way stub verification from #440 stands.
What changes is the diagnosis someone would act on. The old failure message told them to pause iCloud or move the build out of
~/Documents— which would have wasted their time and not worked. It now tells them to check which xattr is actually present:and states that
com.apple.provenanceis tolerated by codesign and is never the culprit — the distinction that actually matters, and the one I nearly buried under a wrong story.🤖 Generated with Claude Code