Repository navigation
[Bug][macOS] Bundled 2.68.0 ocx cannot load @napi-rs/keyring #6139
Description
Client or integration
Other — OpenCodex desktop app's bundled ocx sidecar
Area
Installation or packaging
Summary
The ocx binary 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 documented ocx provider keychain <name> store path 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 status -
The 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.0
Operating system
macOS 26.7, arm64
Provider and model
Not provider-specific; no model request is involved.
Logs or error output
opencodex 2.68.0
name: openai
store: none
keychainAvailable: false
keychainUnavailableReason: Cannot find module '@napi-rs/keyring'
Require stack:
- /$bunfs/root/ocx
The app bundle contains Contents/MacOS/ocx and opencodex-desktop; no @napi-rs/keyring or native keyring artifact was found under Contents by filename. The module-resolution error is the direct evidence; a missing build artifact is a likely packaging cause, not yet proven.
Checks
- I searched existing issues and documentation. The completed feature request Store third-party provider API keys in the OS keychain (currently plaintext in config.json) #1221 describes adding Keychain support, not this bundled-app loading failure.
- I removed secrets, tokens, account details, request credentials, and personal data.
Activity
Ingwannu commentedon Sep 28, 2026
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.Ingwannu commentedon Sep 28, 2026
Fix 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.
Ingwannu commentedon Sep 28, 2026
Correction/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.
Ingwannu commentedon Sep 28, 2026
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.
lidge-jun commentedon Sep 29, 2026
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.