ITADN

Crash on every launch in 0.48.0 (112): "could not load resource bundle" (CodexBar_CodexBarCore.bundle)

#2738Openmanuelniehues 创建于 14 天前
clawsweeper:fix-shape-clearissue-rating: 🦞 diamond lobsterclawsweeper:source-reproimpact:crash-loopclawsweeper:queueable-fixno-staleP0impact:ux-release-blocker
M
manuelniehuescommented
## 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 条评论