Locally-regenerated ClaudeCode.app is missing _CodeSignature/Resources, causing Gatekeeper to block execution ("is damaged")

Environment:

• macOS 26.5.2 (Build 25F84), arm64
• Claude Code CLI 2.1.227 (auto-updated same day from 2.1.226)
• Install path: ~/.local/share/claude/

Summary:
Claude Code's daemon reconstructs a ClaudeCode.app wrapper at ~/.local/share/claude/ClaudeCode.app around the versioned CLI binary each time it spawns background workers (bg-spare, bg-pty-host, etc.). The reconstructed bundle contains only Contents/MacOS/claude and Contents/Info.plist — it's missing Contents/_CodeSignature and Contents/Resources, even though the embedded code signature (signed by Anthropic PBC, Team ID Q6L2SF6YDW) declares those must be present. This mismatch causes macOS Gatekeeper to reject the bundle, and it surfaces to the user as Finder's "'ClaudeCode.app' is damaged and can't be opened. You should move it to the Trash" dialog.

Evidence:

$ codesign --verify --deep --strict --verbose=4 ~/.local/share/claude/ClaudeCode.app
~/.local/share/claude/ClaudeCode.app: code has no resources but signature indicates they must be present

Unified log at the time of a background-worker spawn:

kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: <pid>, .../ClaudeCode.app/Contents/MacOS/claude
syspolicyd: Unable to convert .../ClaudeCode.app/Contents/_CodeSignature to its filesystem mount [statfs failed]: No such file or directory

Repro steps:

1. Run Claude Code CLI normally, letting it auto-update and spawn background workers.
2. Delete ~/.local/share/claude/ClaudeCode.app.
3. Trigger a new background worker spawn (e.g. any backgrounded tool call).
4. The app bundle is regenerated at the same path, again missing Contents/_CodeSignature and Contents/Resources.
5. macOS eventually surfaces the "is damaged" dialog for that path.

Impact: Some background-worker spawn attempts are silently blocked by Gatekeeper and appear to be retried (denied PIDs don't show up in ps aux, while later spawns with the identical command line succeed), plus a recurring, confusing Finder dialog that has no real fix from the user side (xattr -cr doesn't help since no quarantine flag is set, and deleting the file just triggers a rebuild in the same broken state).

Expected: The locally-regenerated bundle should either include a matching _CodeSignature/Resources, or be built/signed in a way that satisfies its own embedded signature — or the daemon should invoke the versioned binary directly rather than through a manufactured .app wrapper.