Repository navigation
[Bug][macOS] Bundled 2.68.0 ocx cannot load @napi-rs/keyring #6139
Description
Activity
Confirmed as a packaging defect rather than an OS Keychain permission denial. The source dependency and Darwin native packages are declared, but the 2.68 desktop app’s Bun-bundled
ocxsidecar cannot resolve@napi-rs/keyringwhen launched from an unrelated working directory. The fix needs to ship and resolve the platform native addon from the application bundle and add a packaged-app smoke test launched outside the bundle tree (for example/private/tmp), without writing credentials. Keeping this open while I prepare the packaging fix.Reacted by DevHeroFix is now in draft PR #6161. It stages the target native addon outside Bun’s virtual filesystem, packages both Darwin architectures into the universal app, resolves only deterministic executable-relative paths, and adds a packaged-app keychain probe from an unrelated working directory. Focused tests/typecheck/structure checks are green locally under the resource cap; hosted macOS bundle CI and maintainer review are in progress.
Reacted by DevHeroCorrection/update for #6161: the packaged-app verifier now uses a bounded load-only keyring probe. It verifies that the signed sidecar can load the external native binding and expose both constructors from an unrelated cwd, but deliberately does not read or write an OS credential (avoiding Keychain consent-dialog dependence in CI). The universal macOS release job separately requires both arm64 and x64 addon resources before running that verifier.
Update: #6161 exact head 4475196 now has all hosted checks green across Linux/macOS/Windows packaging, keyring, desktop-shell and functional jobs. The implementation uses a load-only packaged binding proof and does not touch OS credentials. The PR remains draft pending @lidge-jun final maintainer review; this issue stays open until merge and packaged release verification.
Fixed on dev by #6161: standalone and desktop builds now stage the platform keyring native addon outside Bun's virtual filesystem, and the packaged sidecar loads it from an unrelated working directory (CI
macos widget + bundleanddesktop shellprobes on the merged head). Evidence limit: the packaged probe is load-only; an OS credential operation through the packaged app was not exercised in CI (separate keyring smoke jobs cover it from source). Ships in the next release; please reopen if the packaged app still cannot read the keyring.
Client or integration
Other — OpenCodex desktop app's bundled
ocxsidecarArea
Installation or packaging
Summary
The
ocxbinary bundled in OpenCodex.app 2.68.0 reports that the OS keychain is unavailable because it cannot load@napi-rs/keyring. On an interactive macOS session, the bundled CLI should be able to load its declared keyring dependency and report Keychain availability (or a genuine OS credential-store error). This prevents the documentedocx provider keychain <name> storepath from being used through the app's bundled runtime.Reproduction
Install OpenCodex.app 2.68.0 in
/Applicationson macOS arm64.Run from an unrelated working directory, with no globally installed
ocx:cd /private/tmp /Applications/OpenCodex.app/Contents/MacOS/ocx --version /Applications/OpenCodex.app/Contents/MacOS/ocx provider keychain openai statusThe same output occurs from other working directories. This probe does not create or store a credential; the
openairow is used only to inspect keychain availability.Version
OpenCodex.app and bundled
ocx: 2.68.0Operating system
macOS 26.7, arm64
Provider and model
Not provider-specific; no model request is involved.
Logs or error output
The app bundle contains
Contents/MacOS/ocxandopencodex-desktop; no@napi-rs/keyringor native keyring artifact was found underContentsby filename. The module-resolution error is the direct evidence; a missing build artifact is a likely packaging cause, not yet proven.Checks