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

[knottttt]

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.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}

[Ingwannu]

Confirmed: the current diagnostic path can collapse non-converged history outcomes into the DB-lock message, so this is a real reporting bug rather than proof that state_5.sqlite is actually locked. Draft PR #1202 now tracks the fix and separates busy, permission, unsafe-path, coordinator, worker-error, death, and timeout outcomes, including Windows path identity handling. Leaving the issue open until exact-head CI finishes and the draft receives maintainer review and merges into dev.

[lidge-jun]

Fixed on dev by #1202 (merge a81f9423a).

Two separate defects were behind this: every history failure was being reported with the DB-lock wording regardless of cause, and the Windows path identity check rejected a valid path when canonicalisation differed in case. Both are addressed — failures now report their actual cause, and Windows comparison is case-insensitive.

Thanks for the detailed report.

main does not carry this yet — it ships in the next release.