Crash on every launch in 0.48.0 (112): "could not load resource bundle" (CodexBar_CodexBarCore.bundle)
clawsweeper:fix-shape-clearissue-rating: 🦞 diamond lobsterclawsweeper:source-reproimpact:crash-loopclawsweeper:queueable-fixno-staleP0impact:ux-release-blocker
## Summary
CodexBar 0.48.0 (build 112) crashes immediately on every launch — no error dialog, no window, nothing visible. The app just silently dies right after starting.
## Environment
- CodexBar: 0.48.0 (112)
- macOS: 26.6.1 (25G76)
- Arch: arm64 (Apple Silicon)
- Install method: auto-update (Sparkle)
## Steps to reproduce
1. Launch CodexBar.app normally (Dock, Spotlight, or `open -a CodexBar`)
2. App exits within ~1s with no visible UI and no error dialog
3. A `.ips` crash report is generated each time (5 identical crashes observed in a row)
## Root cause (confirmed)
Running the executable directly from Terminal surfaces the actual Swift fatal error:
```
CodexBarCore/resource_bundle_accessor.swift:12: Fatal error: could not load resource bundle:
from /Applications/CodexBar.app/CodexBar_CodexBarCore.bundle
or /Users/steipete/Projects/CodexBar/.claude/worktrees/codexbar-plugin-architecture-3f1e54/.build/arm64-apple-macosx/release/CodexBar_CodexBarCore.bundle
```
Note the fallback path references a local dev worktree (`.claude/worktrees/codexbar-plugin-architecture-3f1e54`), which suggests this specific 0.48.0 build was packaged from a feature-branch build environment rather than the normal release pipeline.
The resource bundle is actually present in the app bundle, just not where `resource_bundle_accessor.swift` looks for it:
```
$ find /Applications/CodexBar.app -iname "*CodexBarCore*"
/Applications/CodexBar.app/Contents/Resources/CodexBar_CodexBarCore.bundle
/Applications/CodexBar.app/Contents/PlugIns/CodexBarWidget.appex/Contents/Resources/CodexBar_CodexBarCore.bundle
```
The generated SPM resource accessor is checking `Bundle.main.bundleURL` (the `.app` root) instead of `Bundle.main.resourceURL` (`Contents/Resources/`), which is where Xcode/SPM actually places bundle resources in a standard `.app` — likely a copy-bundle-resources build phase / target membership misconfiguration for this specific release.
## Workaround
Symlinking the bundle to the location the accessor expects fixes it:
```
ln -s "Contents/Resources/CodexBar_CodexBarCore.bundle" "/Applications/CodexBar.app/CodexBar_CodexBarCore.bundle"
```
After this, the app launches and runs normally. (Workaround is lost on the next update, obviously.)
## Note
This looks like a repeat of the same failure class as #900, #894, #891, #351, #239, #230 (`Bundle.module`/`NSBundle.module` assertion failures on launch) — might be worth a regression test in the release pipeline that actually launches the packaged `.app` before publishing.
4 条评论