›_ Codex Issues
Codex Issues / #28069

Codex Desktop 26.609.41114 won't launch on macOS 27: AMFI rejects better_sqlite3.node (library load denied) after Sparkle auto-update

Open 💬 0 comments Opened Jun 13, 2026 by FairladyZ625

Summary

After a Sparkle in-app auto-update to 26.609.41114 on macOS 27, the Codex desktop app fails to launch. The system (AMFI) refuses to load the bundled native module better_sqlite3.node, which the app surfaces as a misleading "SQLite database is accessible" error. The database is not corrupted — the failure is at the code-signing / provenance layer, so the app's own "Back Up and Rebuild" button does not help.

Environment

  • Codex desktop app: 26.609.41114 (CFBundleVersion 3888)
  • macOS: 27.0 (Build 26A5353q), Apple Silicon (arm64)
  • Update channel: Sparkle in-app auto-update (app was updated today, 2026-06-13)

Error

The app cannot finish launching until its SQLite database is accessible.
Database path: ~/.codex/sqlite/codex-dev.db

Error: dlopen(/Applications/Codex.app/Contents/Resources/app.asar.unpacked/node_modules/better-sqlite3/build/Release/better_sqlite3.node, 0x0001):
  code signature in <CA8A20DA-…> '…/better_sqlite3.node' not valid for use in process: library load denied by system policy

The dialog offers Retry and Back Up and Rebuild — neither helps, since the root cause is not the database.

Root cause (analysis)

  • better_sqlite3.node is independently valid: codesign --verify --strict passes; signed by Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2); timestamped today.
  • Codex.app itself is also validly signed (same Team ID), with Hardened Runtime + App Sandbox enabled.
  • The bundle is covered in com.apple.provenance extended attributes, and the app was modified today by Sparkle (both the bundle mtime and the .node signature timestamp are today).
  • Hypothesis: the Sparkle update replaced / re-signed only parts of the bundle, breaking provenance consistency between the main executable and the app.asar.unpacked native modules. At launch, AMFI validates the native library's provenance/signature against the main app, finds a mismatch, and rejects it → better_sqlite3.node fails to dlopen → the sqlite driver never loads → the app stalls behind the misleading DB dialog.

This fits the pattern of other macOS signing/policy issues already filed (#20283 spctl failures, #16767 syspolicyd/trustd spikes).

Workaround

Ad-hoc re-sign the entire bundle and every native module under app.asar.unpacked. A plain codesign --force --deep on the .app is not enough — it skips the unpacked .node files (the Electron packaging gotcha here), leaving the main app ad-hoc but the native modules still carrying the original Developer ID signature, which re-triggers library validation:

# requires App Management permission for the terminal
sudo pkill -9 -f "/Applications/Codex.app"
find /Applications/Codex.app/Contents/Resources/app.asar.unpacked \( -name "*.node" -o -name "*.dylib" \) -type f \
  -exec sudo codesign --force --sign - {} \;
sudo codesign --force --deep --sign - /Applications/Codex.app
open /Applications/Codex.app

Caveat: this drops the OpenAI Developer ID signature (becomes ad-hoc), so it disables Sparkle auto-updates afterward and may require the user to allow the app in System Settings → Privacy & Security.

Expected

Sparkle's update flow should preserve signature/provenance consistency for app.asar.unpacked native modules on macOS 27, so the app continues to launch after an auto-update without manual re-signing.

View original on GitHub ↗