[Bug] OpenCodex 2.10.2 falsely reports Codex resume history DB locked on Windows / Codex 0.146.0 #1191

Client or integration

Codex CLI

Area

Platform (Windows / macOS / Linux)

Summary

After upgrading OpenCodex from 2.10.0 to 2.10.2 on Windows with Codex CLI 0.146.0, ocx start, ocx sync, ocx stop, and ocx restore consistently report that the Codex resume history database is locked.

I expected OpenCodex to migrate/restore resume history successfully when the database is not actually locked, or to report the underlying SQLite error instead of saying the Codex app/IDE is holding the DB.

This appears to be a regression in the resume-history migration/restore logic introduced between 2.10.0 and 2.10.2. Downgrading to 2.10.0 immediately removes the warning on the same machine and Codex installation.

Reproduction

1. Install OpenCodex 2.10.2:

npm install -g @bitkyc08/opencodex@2.10.2

2. Confirm versions:

ocx --version
codex --version

Observed:

opencodex 2.10.2
codex 0.146.0

3. Close Codex and IDEs, then run:

ocx start

Observed:

⚠️ Codex resume history migration deferred: the history DB is locked (Codex app/IDE open?). It is retried automatically (while the proxy runs and on every 'ocx start'); to force it now, close the Codex app and run 'ocx sync'.

4. ocx sync reports the same warning.

5. Run:

ocx stop

Observed:

↩️ Codex config restored from opencodex journal. ⚠️ Codex resume history could NOT be restored — the Codex app appears to be holding the history database. Close Codex and run `ocx restore` again.

6. After fully stopping the OpenCodex proxy and confirming port 10100 is no longer listening, run:

ocx restore

Observed:

✅ opencodex not present in Codex config. ⚠️ Codex resume history could NOT be restored — the Codex app appears to be holding the history database. Close Codex and run `ocx restore` again.

Plain `codex` now runs natively (no proxy). Switch back with: ocx restore back

7. Verified there was no obvious real file lock:

• Closed Codex / IDE.
• Stopped the OpenCodex service manager.
• Terminated the remaining bun.exe proxy listening on 127.0.0.1:10100 and its respawning parent cmd.exe.
• Confirmed nothing was listening on port 10100.
• Windows Resource Monitor showed no handle for state_5.sqlite or logs_2.sqlite.
• Tested all relevant SQLite files with an exclusive FileShare.None open; every file reported FREE:

.opencodex-native-main.claim.sqlite   FREE
.opencodex-native-main.owner.sqlite   FREE
.opencodex-native-profile.lock.sqlite FREE
goals_1.sqlite                        FREE
goals_1.sqlite-shm                    FREE
goals_1.sqlite-wal                    FREE
logs_2.sqlite                         FREE
logs_2.sqlite-shm                     FREE
logs_2.sqlite-wal                     FREE
memories_1.sqlite                     FREE
memories_1.sqlite-shm                 FREE
memories_1.sqlite-wal                 FREE
state_5.sqlite                        FREE
state_5.sqlite-shm                    FREE
state_5.sqlite-wal                    FREE

8. Backed up and removed these OpenCodex coordination files while all relevant files were FREE:

.opencodex-native-main.claim.sqlite
.opencodex-native-main.owner.sqlite
.opencodex-native-profile.lock.sqlite

ocx restore on 2.10.2 still reported the same DB-lock error.

9. A/B test by downgrading to 2.10.0:

npm uninstall -g @bitkyc08/opencodex
npm install -g @bitkyc08/opencodex@2.10.0

Then:

ocx restore

works cleanly:

✅ opencodex not present in Codex config.
Plain `codex` now runs natively (no proxy). Switch back with: ocx restore back

And ocx start on 2.10.0 reports:

🚀 opencodex proxy running on http://localhost:10100
[opencodex] Codex runtime: C:\Users\[USER]\AppData\Roaming\npm\codex.cmd (version=0.146.0, source=configured)
- 7 models appended to Codex catalog
Pointed Codex's built-in openai provider at the opencodex proxy (openai_base_url).
Codex resume history: untouched (threads keep their native openai tag).
All models now route through opencodex proxy (like OpenRouter).

Native codex itself works normally throughout the test.

Version

Affected: 2.10.2
Working comparison: 2.10.0

Operating system

Windows, PowerShell environment.

Provider and model

Not provider-specific. Codex CLI 0.146.0 using OpenCodex routing.

Logs or error output

⚠️ Codex resume history migration deferred: the history DB is locked (Codex app/IDE open?).

⚠️ Codex resume history could NOT be restored — the Codex app appears to be holding the history database. Close Codex and run `ocx restore` again.

Screenshots and supporting files

The reproduction and exclusive-file-access results are included above. No secrets or credentials are included.

Redacted configuration

{
  "proxy": "127.0.0.1:10100",
  "codex_version": "0.146.0",
  "affected_opencodex_version": "2.10.2",
  "working_opencodex_version": "2.10.0"
}

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.