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

[manuelniehues]

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.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 7, 2026, 7:49 PM ET / 23:49 UTC.

Summary
Keep open as a P0 release regression: withdrawing v0.48.0 from the update feed limits further installs, but existing v0.48.0 installations still crash before Sparkle can update them and current packaging retains the implicated bundle layout.

Reproducibility: yes. —source-reproducible with high confidence: current packaging still copies SwiftPM bundles into Contents/Resources, matching the reported generated-accessor failure and the independently confirmed symlink workaround.

Next step
A focused packaging repair is warranted: current main withdrew the bad appcast entry but retains the source layout that produced the release crash.

Review details

Best possible solution:

Ship a corrected replacement build with the Core bundle resolvable at launch, publish a direct recovery download for affected v0.48.0 users, and retain a packaged-app launch smoke check for future releases.

Do we have a high-confidence way to reproduce the issue?

Yes—source-reproducible with high confidence: current packaging still copies SwiftPM bundles into Contents/Resources, matching the reported generated-accessor failure and the independently confirmed symlink workaround.

Is this the best way to solve the issue?

Yes—the narrow repair is to make the packaged Core resource location match its accessor and prove a freshly packaged app launches; appcast withdrawal alone is only a distribution mitigation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Existing v0.48.0 installations terminate before the updater can apply the appcast withdrawal, leaving non-technical users without an in-product recovery path.
• The current packaging script still places all SwiftPM bundles in Contents/Resources, so a new release needs packaged-app launch proof before distribution.

Codex review notes: model internal, reasoning high; reviewed against 89dcbd0a08cc.

Label changes

Label justifications:

• P0: v0.48.0 exits on every launch before any UI is available, affecting released installations.
• impact:crash-loop: The reported fatal resource lookup terminates the application repeatedly at startup.
• impact:ux-release-blocker: Affected non-technical users have no in-app recovery and the known workaround requires a Terminal command inside the app bundle.

Evidence reviewed

Acceptance criteria:

• make test
• make check
• Package a release-mode app and verify the Core bundle exists at the accessor-resolvable location.
• Launch the freshly packaged app on macOS without performing live provider probes or Keychain reads; capture a redacted launch result.

What I checked:

• Current packaging layout: The current package script copies every SwiftPM resource bundle, including CodexBarCore’s bundle, into Contents/Resources; this matches the failing v0.48.0 layout described in the report. (Scripts/package_app.sh:555, 89dcbd0a08cc)
• Mitigation is appcast-only: The current-main commit explicitly withdraws v0.48.0 after this crash, but its tree changes only appcast.xml, not the packaging logic; this prevents further Sparkle distribution rather than repairing installed copies or a future package. (appcast.xml:1, 89dcbd0a08cc)
• History and release state: Blame ties the unchanged resource-copy loop to the v0.48.0 release commit, while 89dcbd0 is five commits after tag v0.48.0 and is not contained by a release tag; no fixed release is evidenced. (Scripts/package_app.sh:562, 5bd587850611)
• Independent affected-user confirmation: Two commenters independently confirm the same immediate crash and that the reported bundle symlink workaround restores launch behavior.
• Vision fit: VISION.md lists bounded bug fixes as merge-by-default work; this is a narrow packaging regression rather than new product surface. (VISION.md:6, 89dcbd0a08cc)

Likely related people:

• Peter Steinberger: Authored both the v0.48.0 release commit blamed for the current resource-copy loop and the current appcast withdrawal mitigation. (role: recent packaging and release contributor; confidence: high; commits: 5bd587850611, 89dcbd0a08cc; files: Scripts/package_app.sh, appcast.xml)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[natesilva]

I’m having the same problem, and the temporary workaround given by @manuelniehues fixed it.

[marcvig]

I am confirming same bug on my Macbook M5 Pro. instant crash no dialog. silent fail

[steipete]

Root cause confirmed, fix landed, hotfix shipping now. Thank you for the exceptional report — the direct-run trace and the find output made this a 20-minute diagnosis.

What happened: the 0.48.0 provider-plugin runtime loads its bundled scripts through SwiftPM's autogenerated Bundle.module accessor, which only probes (a) the app root and (b) the compile-time build directory baked in at build time. The packaged app ships CodexBar_CodexBarCore.bundle in Contents/Resources, so the accessor traps at launch on every machine — except the release build machine itself, where path (b) exists. That's exactly why it survived pre-release launch testing, and yes, your read is right that this is the same failure class as #900/#894/#891: the repo already had a safe-accessor pattern for it (used for KeyboardShortcuts localization), which the new plugin code bypassed.

Fixes, all on main:

• 9c5658372 routes every CodexBarCore resource load through a safe resolver (Contents/Resources first, app root, then Bundle.module only outside app contexts), plus a fake-.app-layout regression test and a source-level gate test that fails if raw Bundle.module reappears in CodexBarCore.
• The appcast entry for 0.48.0 was pulled immediately so Sparkle stops delivering the crashing build.
• 0.48.1 (113) is releasing right now; your suggested launch-the-packaged-app-without-the-build-dir check is being run as part of its verification, and adding it permanently to the release pipeline is queued.

Affected installs recover via the 0.48.1 update (your symlink workaround also holds until then). Closing when 0.48.1 is live and verified.