Desktop should bound and compact logs_2.sqlite before it becomes recovery pressure

Summary

Codex Desktop needs a bounded local log DB lifecycle before large logs_2.sqlite files become app-server/renderer recovery pressure. The immediate renderer freeze I investigated had a local ~/.codex/logs_2.sqlite around 952 MB.

There are already several issues about TRACE rows and SQLite growth. This issue is specifically about the recovery/user-impact invariant: a large local diagnostic DB should not make the Desktop UI repeatedly freeze or require users to manually delete SQLite files to recover.

Local evidence

On the affected macOS profile:

~/.codex/logs_2.sqlite  ~952 MB
~/.codex/state_5.sqlite ~6.4 MB

The Desktop app-server and bridge/helper processes were still alive while the renderer was the problematic process. That suggests two interacting pressures:

1. the renderer receives too many live events during active streaming/tool turns;
2. persisted local log/state databases remain large across restarts, so quitting/reopening does not necessarily remove the pressure.

Raw log rows are intentionally not included because local logs can contain private paths and session content.

Problem

Even if retention/checkpointing exists, the current behavior still allows a normal Desktop profile to reach a very large local log DB. Once that happens, the failure mode is sticky:

• relaunching the app can reuse the same large local DB;
• app-server startup/recovery may contend on or scan local SQLite state;
• renderer recovery or diagnostics can be affected by the same persisted state;
• users do not get a clear safe-mode or repair path.

Suggested fix

Add an explicit bounded log lifecycle for Desktop profiles:

• do not persist TRACE logs by default unless an explicit debug flag is enabled;
• enforce a byte and row cap for logs_2.sqlite, not just age-based retention;
• checkpoint/truncate WAL under normal multi-process Desktop usage;
• run maintenance before hot startup/resume paths that can affect renderer responsiveness;
• if the DB exceeds a safety threshold, show a repair/safe-mode path instead of letting the renderer freeze;
• separate renderer-critical state from diagnostic logs so the UI does not depend on reading or reconciling an oversized log store;
• expose a supported command such as codex logs compact or automatic profile maintenance.

Expected behavior

A Desktop profile should recover cleanly even if its log DB is large. Users should not need to discover and manually delete ~/.codex/logs_2.sqlite* to restore responsiveness.

Related issues

This overlaps with, but does not fully replace:

• #30322
• #24275
• #27741
• #29532
• #30162
• #30405
• #25779