Desktop launch can fail when logs_2.sqlite grows large: app-server SQLite pool times out during startup

Summary

Codex Desktop on Windows can fail to launch when the local diagnostic log SQLite database (logs_2.sqlite) grows large enough that app-server startup cannot initialize the SQLite runtime within the Desktop handshake timeout.

This is related to the existing logs_2.sqlite growth/WAL reports, but the user-visible failure mode is different: Desktop shows a blocking "Codex cannot access its local database" dialog even though state_5.sqlite is healthy. Moving only logs_2.sqlite* aside lets app-server recreate the logs DB and launch normally without touching threads, goals, memories, sessions, or config.

Environment

• Product: Codex Desktop for Windows
• Windows Store package observed in logs: OpenAI.Codex_26.609.3341.0_x64
• Bundled WSL CLI observed: codex-cli 0.140.0-alpha.2
• Mode: Desktop app-server running in WSL
• Config shape:
• runCodexInWindowsSubsystemForLinux = true
• integratedTerminalShell = "wsl"
• sqlite_home = "/mnt/c/Users/<WindowsUser>/.codex"
• SQLite home is on the Windows-backed /mnt/c filesystem.

User-visible failure

On launch, Desktop showed:

Codex cannot access its local database.

Database path: Path unavailable in app-server startup error

Error: (code=1, signal=null).
Most recent error: Error: failed to initialize sqlite state runtime under
/mnt/c/Users/<WindowsUser>/.codex: failed to initialize state runtime at
/mnt/c/Users/<WindowsUser>/.codex: pool timed out while waiting for an open connection

Desktop never finished launching until the logs DB was moved aside.

Log evidence

Sanitized Desktop log sequence:

Launching app ... package OpenAI.Codex_26.609.3341.0_x64
[wsl] eligible distro list ... Ubuntu Running 2
stdio_transport_spawned executablePath=C:\Users\<WindowsUser>\.codex\bin\wsl\<hash>\codex spawnCommand=wsl.exe
Initialize handshake still pending durationMs=10020
app_server_connection.closed code=1 reason="Error: failed to initialize sqlite state runtime under /mnt/c/Users/<WindowsUser>/.codex: failed to initialize state runtime at /mnt/c/Users/<WindowsUser>/.codex: pool timed out while waiting for an open connection"
initialize_handshake_result durationMs=33522 outcome=failure

Retrying spawned a second app-server process and failed the same way after about 33 seconds.

Local DB evidence

Before recovery:

state_5.sqlite          ~35.6 MB
logs_2.sqlite           ~4.5 GB
logs_2.sqlite-wal       ~1.08 GB
logs_2.sqlite-shm       ~1.47 MB
goals_1.sqlite          small
memories_1.sqlite       small

Read-only checks:

state_5.sqlite quick_check: ok
goals_1.sqlite quick_check: ok
memories_1.sqlite quick_check: ok

logs_2.sqlite was the outlier:

• A simple metadata query against logs_2.sqlite took about 45 seconds.
• select count(*) from logs took about 38 seconds and returned about 862,750 rows.
• min(id), max(id) showed heavy churn: max row id was above 100M.
• WAL-aware pragma quick_check did not finish within 120 seconds.
• An immutable read-only check reported freelist / pointer-map errors, but because immutable mode ignores WAL frames this should be treated as corruption-suspicious rather than definitive corruption.

Recovery experiment

The following was tested without touching thread/session state:

1. Stop Codex Desktop / app-server.
2. Move only these files out of the active .codex directory into a backup folder:

``text
logs_2.sqlite
logs_2.sqlite-wal
logs_2.sqlite-shm
``

1. Leave all of these in place:

``text
state_5.sqlite
goals_1.sqlite*
memories_1.sqlite*
sessions/**
archived_sessions/**
session_index.jsonl
config.toml
auth files
plugin/cache/config files
``

1. Start the same app-server binary against the same real Codex home.

Result:

• app-server startup succeeded.
• A fresh logs_2.sqlite was recreated at about 48 KB.
• Fresh logs_2.sqlite passed quick_check.
• Existing state_5.sqlite still passed quick_check.
• Thread/session files were not moved or edited.

This strongly indicates the launch blocker was the diagnostic logs DB path, not the actual thread/state DB.

Likely root cause

From the public source shape, StateRuntime::init opens/migrates state, logs, goals, and memories DBs as part of app-server startup. It also runs log startup maintenance:

delete logs older than retention window
PRAGMA wal_checkpoint(PASSIVE)

When logs_2.sqlite and/or its WAL are multi-GB and slow on /mnt/c, this work can exceed the startup/connection pool/handshake timeout. The resulting error bubbles up as a generic SQLite state runtime failure, which makes it look like the main thread database is inaccessible even when state_5.sqlite is healthy.

Expected behavior

• A large, slow, or damaged diagnostic log DB should not prevent Desktop from launching.
• Startup should not synchronously block on log retention/checkpoint work that can take tens of seconds or minutes.
• If the logs DB is unhealthy or too slow, Codex should rotate/regenerate it automatically or offer a safe "clear diagnostic logs" recovery path.
• The error dialog should identify the specific DB that failed (logs_2.sqlite vs state_5.sqlite) and explain whether conversation history is at risk.
• Log maintenance should be bounded, backgrounded, and non-fatal where possible.

Suggested fixes

• Treat log DB initialization/maintenance as non-critical for app launch when state DB opens successfully.
• Add a bounded timeout around log startup maintenance, and defer heavy DELETE / checkpoint work until after Desktop is usable.
• Add automatic rotation of logs_N.sqlite* when the file or WAL exceeds a threshold.
• Configure WAL limits/checkpointing/retention so the diagnostic DB cannot grow to multi-GB under normal Desktop/goal/app-server usage.
• Surface a safe recovery button/action: "Move diagnostic logs aside and relaunch".
• Improve diagnostics so the dialog reports the actual failing DB path and classifies state vs logs vs goals vs memories.

Related issues

• #26374 - app-server feedback log SQLite grows unbounded
• #24275 - Desktop rapidly grows logs_2.sqlite / WAL during normal active use
• #17320 - excessive SQLite WAL writes during streaming / TRACE logging
• #22444 - stale Codex processes keep huge deleted logs_2.sqlite-wal allocated
• #21134 - Desktop becomes unusable on long active threads with TRACE log churn
• #27395 - Desktop turn/start times out while app-server sidecar stalls
• #25715 - Windows Desktop with WSL mode suffers severe performance issues on Windows-backed .codex

This issue is intended to capture the specific launch-blocking failure and recovery path, not to duplicate the broader log-growth reports.