CLI contexts can still trap on the missing CodexBarCore resource bundle (JS-plugin providers)

[steipete]

Summary

Follow-up to #2738: the packaged app is fixed (9c5658372), but CLI contexts still have the same latent trap. Neither the app's Contents/Helpers/CodexBarCLI directory nor the standalone CodexBarCLI-v0.48.1-macos-*.tar.gz artifacts ship CodexBar_CodexBarCore.bundle — verified against the released 0.48.1 assets. CodexBarCoreResources.resolve falls through to raw Bundle.module outside an .app context, whose accessor probes only executable-adjacent and the compile-time build path, then traps.

Since 0.48.0 defaults six providers (Crof, Venice, OpenRouter, ClawRouter, Deepgram, sub2api) to bundled JS plugins on macOS, any CLI invocation that constructs a plugin runtime for those providers on a user machine should hit the fatal — masked on dev machines by the baked-in build path, exactly like #2738 was.

Fix sketch (agreed direction)

1. CodexBarCoreResources grows a non-trapping resolution for executable contexts: probe app Resources, then executable-adjacent CodexBar_CodexBarCore.bundle, then SwiftPM build-dir candidates via explicit FileManager existence checks; only touch Bundle.module when one of its candidate paths exists; otherwise return nil and let plugin call sites throw ProviderPluginError.load (a clean provider error, not a process trap).
2. Ship the bundle: package_app.sh places it next to Contents/Helpers/CodexBarCLI; the CLI tarball packaging adds it alongside the binary.
3. Extend build: packaged-app launch smoke check so the 0.48.0 crash class cannot ship again #2755's resource smoke probe to cover the CLI binary in both artifact shapes.

Refs #2738, #2755.

[clawsweeper]

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

Summary
Keep open: current main still sends every non-app context, including the CLI, directly to SwiftPM’s trapping resource accessor, while current packaging does not place the core bundle beside either CLI shape. The repository owner’s open PR #2757 explicitly owns the bounded repair and provides artifact-level proof, so this issue should remain open until that PR lands.

Reproducibility: yes. —source establishes a current-main path: a non-app CLI always enters the raw SwiftPM accessor, while current helper and tarball packaging omit the executable-adjacent bundle it needs.

Next step
An open owner-authored PR already owns the exact repair, so a competing repair lane would duplicate active work.

Review details

Best possible solution:

Merge the linked repair after normal PR review so every supported CLI artifact carries the bundle, resolves it without a trap, and verifies both success and missing-bundle failure modes.

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

Yes—source establishes a current-main path: a non-app CLI always enters the raw SwiftPM accessor, while current helper and tarball packaging omit the executable-adjacent bundle it needs.

Is this the best way to solve the issue?

Yes—the linked PR’s optional resolver plus adjacent bundle delivery and artifact smoke checks is the narrowest solution, preserving normal provider-error handling when installation is incomplete.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Until the linked PR merges, invoking a bundled JavaScript provider from an installed CLI can terminate the process instead of returning a recoverable provider-load error.

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

Label changes

Label changes:

• add clawsweeper:linked-pr-open: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.

Label justifications:

• P1: Installed CLI use of default bundled JavaScript providers can currently terminate instead of reporting a provider error.
• impact:crash-loop: The non-app resource path reaches SwiftPM’s fatal resource-bundle accessor when the bundle is absent.

Evidence reviewed

What I checked:

• Current CLI resolver remains trapping: Current main returns the generated SwiftPM resource bundle accessor whenever the main bundle is not an app; this is the CLI path and can trap when neither its executable-adjacent nor compiled-in candidate exists. (Sources/CodexBarCore/CodexBarCoreResources.swift:16, cee0fd074073)
• Current artifact packaging omits the adjacent core bundle: App packaging installs the helper CLI, then copies SwiftPM bundles only into the app Resources directory; release-CLI packaging archives only the binary, symlink, and version file. (.github/workflows/release-cli.yml:382, cee0fd074073)
• Feature provenance: Blame attributes the current non-app Bundle.module fallback to the packaged-app resolver introduced by the earlier app-only fix; its commit message expressly limits that fallback to CLI and development contexts. (Sources/CodexBarCore/CodexBarCoreResources.swift:17, 9c5658372716)
• Open canonical repair: The open owner-authored PR Fix CLI resource bundle resolution and packaging #2757 uses closing syntax for this issue and covers optional non-trapping resolution, helper and tarball bundle delivery, and CLI smoke checks with recorded after-fix output. (b616455fed92)
• Maturity label check unavailable: The required shortlist helper could not locate qa/maturity-scores.yaml in this checkout, so no maturity label is proposed.

Likely related people:

• steipete: Peter Steinberger introduced the current resolver in the app-bundle fix and the subsequent packaged-app smoke gate; the same repository owner authored the open CLI repair. (role: introduced and recently maintained the resource-packaging behavior; confidence: high; commits: 9c5658372716, 6a39b558de3d; files: Sources/CodexBarCore/CodexBarCoreResources.swift, Scripts/package_app.sh, Scripts/verify_packaged_app_launch.sh)

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.