Codex Desktop becomes unusable on long active threads due to app-server/renderer memory and TRACE log churn

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #21007
• #20269
• #20867
• #20781

Powered by Codex Action

Someone investigated this in #21211 You can improve performance just by truncating titles to 120 chars in state_5.sqlite but the sidebar still loads the full first message just on launch so it's still problematic.

Adding another Windows Desktop data point that matches this issue.

Environment:

• Codex Desktop for Windows: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Codex home: %USERPROFILE%\.codex
• Main symptom: local UI jank rather than model/network latency. Sending a prompt can make the mouse/UI stutter, and switching conversations/clicking around the UI can freeze briefly.

Observed local DB state while the app was running:

• logs_2.sqlite: ~812.9 MB
• logs_2.sqlite-wal: grew to ~100 MB before checkpoint; after one successful checkpoint it dropped briefly, then grew back to ~75.7 MB during continued use
• logs rows: ~180,537
• state_5.sqlite: ~4.36 MB
• SQLite freelist in logs_2.sqlite: ~115,943 pages, about ~452.9 MB reclaimable/free pages

Top log targets by estimated bytes:

• codex_api::endpoint::responses_websocket: ~101 MB / ~23k rows
• codex_otel.log_only: ~33 MB / ~26k rows
• codex_otel.trace_safe: ~29 MB / ~24k rows
• codex_client::transport: ~24 MB

Experiment:

• Running PRAGMA wal_checkpoint(PASSIVE) followed by PRAGMA wal_checkpoint(TRUNCATE) on logs_2.sqlite while Codex Desktop was open immediately reduced the perceived UI jank.
• The main DB remained large/fragmented, so this is only a temporary mitigation; the WAL started growing again during normal use.

This makes the issue feel like normal Desktop interaction is being affected by log DB/WAL growth and SQLite churn, not just long model latency. A built-in safe action such as "Optimize local data" / "Clear local diagnostic logs", plus automatic log rotation/checkpointing or bounded TRACE logging, would likely help users recover without manually touching SQLite files.

same issue

Another data point from Codex Desktop 0.140-alpha on Windows 11:

• logs_2.sqlite reached 3.4 GB over 11 days (matches the ~10-day retention; rows pruned logically but no VACUUM, so disk stays allocated).
• Level split: TRACE 1.2 GB (target responses_websocket alone ~1 GB), INFO 354 MB, DEBUG 57 MB. Consistent with #17320 (SQLite sink ignoring RUST_LOG).
• A stale codex app-server process kept the WAL open after the GUI was closed (related: #22444). Killing the orphans was required before the file could be moved.
• Amplifier: the .codex/skills file watcher fired continuously on __pycache__ (.pyc temp files) and bundled-plugin cache churn — each event logged skills cache cleared + a skills/changed app-server event at TRACE, inflating the DB further.

Mitigations that restored the app: kill orphan app-servers, move the oversized logs_2.sqlite aside (app recreates an empty one), clear stray __pycache__. A config/env knob to cap or disable the SQLite TRACE sink would help a lot.

Adding a fresh macOS data point from a current Desktop build. This looks like the same class of issue, but with both renderer CPU and app-server TRACE/log/MCP churn visible at the same time.

Environment

• Codex Desktop: 26.616.81150 (CFBundleVersion 4306)
• Codex Framework / renderer helper: 149.0.7827.115
• Codex CLI bundled resource: codex-cli 0.142.0
• OS: macOS 27.0 (26A5368g) on arm64
• App-server command: /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled

Observed CPU

While the app was sluggish, repeated ps samples showed:

Codex main process                 ~20-23% CPU
codex app-server                   ~28-34% CPU
Codex Helper (Renderer)            ~105-138% CPU

Earlier samples in the same run showed the renderer around 80-151% CPU and app-server around 18-25% CPU.

The renderer was the largest CPU consumer, but the app-server was also continuously active.

logs_2.sqlite churn

Local log DB state:

~/.codex/logs_2.sqlite      2.8G
~/.codex/logs_2.sqlite-wal   10M
~/.codex/state_5.sqlite      92M
~/.codex/state_5.sqlite-wal 4.9M

Short interval sample:

logs_seq_before=195942787
logs_seq_after=195946598
logs_seq_delta=3811 over 10 seconds

That is about 381 log inserts/sec, while the app was still running normally from the user's perspective.

Recent log rows were dominated by TRACE/DEBUG/WARN entries like:

TRACE codex_mcp::connection_manager
TRACE codex_api::sse::responses
TRACE codex_rollout::recorder
TRACE codex_app_server::message_processor
TRACE codex_api::endpoint::responses_websocket
TRACE rmcp::service
TRACE tokio-tungstenite internals:
  Stream.poll_next
  WebSocketStream.with_context
  WouldBlock
  Opcode: Data(Text)
  Masked: false
DEBUG codex_config::loader::macos
DEBUG codex_config::loader::layer_io
WARN codex_features

Top recent rows by target/body included repeated session_loop{...}:submission_dispatch{...} entries under codex_mcp::connection_manager and codex_api::sse::responses.

MCP process multiplication

At the same time, the app-server had multiple repeated direct child process groups. Sanitized count:

10  node ./mcp/server.mjs
 5  npm exec xcodebuildmcp@latest mcp
 5  npm exec chrome-devtools-mcp@latest
 5  npm exec @upstash/context7-mcp --api-key <redacted>
 5  node ./mcp/server.mjs --stdio
 5  node ./mcp/server.cjs --stdio
 5  node ./mcp/server.bundle.mjs
 5  uv tool uvx mcp-server-tapd
 5  Pencil MCP server
 5  node_repl
 4  SkyComputerUseClient mcp

Most of these children were individually low CPU, but app-server was still spending CPU managing/logging the aggregate connection/event stream.

Samples

sample on the renderer for 5 seconds:

• Physical footprint: 329.9M
• Physical footprint peak: 726.0M
• Hot path was the Electron/V8 renderer main thread, with stack activity in V8/JS serialization/allocation paths.

sample on app-server for 5 seconds:

• Physical footprint: 267.7M
• Physical footprint peak: 278.2M
• Visible stack activity included:
• tokio worker threads
• sqlx-sqlite-worker-*
• sqlite3_step
• sqlite3_wal_checkpoint_v2
• tracing_core::event::Event::dispatch
• codex_state::log_db::MessageVisitor
• codex_protocol::dynamic_tools::normalize_dynamic_tool_specs
• tokio::fs::file::File::poll_read

Why this seems related

This looks like a combined feedback loop:

1. The Desktop app resumes/uses active threads and MCP servers.
2. Multiple MCP/tool processes are active or duplicated.
3. app-server emits high-volume TRACE/SSE/MCP/log DB rows.
4. SQLite workers and WAL/checkpoint work keep app-server busy.
5. The renderer is also hot, apparently processing/rendering the resulting thread/event state.

The external MCP children themselves were not the primary CPU source.

Expected behavior

Codex Desktop should not sustain 100%+ renderer CPU plus 30% app-server CPU while tool subprocesses are mostly idle. TRACE logging and MCP status/event streams should be bounded, filtered, batched, or deduplicated so that normal Desktop use does not continuously drive hundreds of SQLite log inserts per second.

Related

This also overlaps with the SQLite TRACE churn tracked in #28224 and related follow-ups, but the user-visible symptom here is Desktop CPU/UI pressure with renderer + app-server both hot on 26.616.81150.

I can reproduce what appears to be the same issue on Windows, and I isolated logs_2.sqlite as the trigger with a local A/B test.

Environment

• Codex Desktop package: OpenAI.Codex_26.707.3748.0_x64
• Codex CLI/app-server bundle: codex-cli 0.140.0
• OS: Windows 11 Enterprise 23H2, build 22631.5768, x64
• CPU: 12th Gen Intel Core i5-12600KF
• RAM: 31.8 GB

Symptoms

Creating a new task, switching tasks, or opening a history item that had not yet been opened would freeze the Codex UI for several seconds. During the worst reproductions, the stall also made the rest of the Windows desktop feel temporarily unresponsive. Restarting Codex or rebooting Windows did not resolve it.

I also tested disabling Browser/Chrome integrations, plugins/MCP servers, Figma, and node_repl, and tested with a clean Electron UI profile. Those changes did not resolve the stall. Moving most session history was also not the decisive factor.

Isolated result

The local diagnostic log database had grown to:

• logs_2.sqlite: 220.23 MB
• logs_2.sqlite-wal: approximately 5.63 MB at the captured point

After moving the 220 MB logs_2.sqlite out of CODEX_HOME and allowing Codex to create a fresh log database, the task/window switching stalls disappeared immediately. Restoring normal Codex features did not bring the stalls back.

This is notable because the problem occurred at roughly 220 MB, substantially below the ~813 MB database reported in the original issue. It suggests the trigger may depend on fragmentation, row count, checkpoint behavior, or local SQLite contention rather than file size alone.

Temporary workaround that worked locally

1. Fully quit Codex and its background processes.
2. Back up/move, rather than permanently delete, the logs_2.sqlite* files from CODEX_HOME (%USERPROFILE%\.codex by default).
3. Relaunch Codex and allow it to create a fresh diagnostic log database.

This did not remove conversation/session history in my test. I am not attaching the original SQLite database because diagnostic logs may contain private local paths, commands, or task data.

A built-in Clear/Rotate diagnostic logs or Optimize local data action, plus bounded retention and automatic WAL checkpoint/VACUUM behavior, would prevent users from needing to manipulate SQLite files manually.

I’m seeing a closely matching slowdown on Codex Desktop for macOS and collected read-only local diagnostics.

Environment:

• Codex Desktop: 26.707.91948 (build 5440)
• Embedded Codex CLI: 0.144.4
• macOS: 26.5.2 (Apple Silicon)
• Memory: 24 GB

Observed while the UI felt sluggish:

• Active renderer RSS: ~855 MB
• Renderer physical footprint during a 3-second sample: ~955 MB, with a recorded peak of ~3.3 GB
• Renderer main thread was in V8/JavaScript execution with substantial GC/finalizer activity
• codex app-server RSS: ~487 MB
• Overall system CPU was ~90% idle, memory pressure reported 56% free, and swap usage was zero

Local Codex state:

• ~/.codex/sessions: 7.3 GB / 829 files
• ~/.codex/archived_sessions: 3.7 GB / 449 files
• ~/.codex/logs_2.sqlite: 1.7 GB
• Largest individual rollout files: ~1.72 GB, ~1.68 GB, and ~608 MB
• Log DB aggregates: 267,433 TRACE rows (~257 MB estimated payload)
• Largest log targets by estimated payload:
• codex_mcp::connection_manager: ~102 MB
• codex_api::sse::responses: ~82 MB
• codex_core::stream_events_utils: ~51 MB

Important caveat: during a five-second idle sample, the SQLite DB/WAL did not grow and renderer CPU later settled around 1–2%. So I cannot confirm continuous write churn or a permanent CPU spin. The strongest local signal is accumulated hot thread/rendering state plus V8 GC pressure, with the large log DB potentially amplifying it.

The app had updated to this build earlier the same day, but I do not yet have an older-build control test. No local data was deleted or modified during diagnosis.

Follow-up after a full Codex Desktop restart: the UI remained very slow, so restart is not an effective workaround in this environment.

Fresh-process evidence roughly eight minutes after relaunch:

• Renderer RSS grew from ~580 MB to ~692 MB over the observation window.
• Renderer CPU repeatedly spiked, reaching ~25.5%.
• A new 3-second renderer sample again showed the main thread dominated by V8 execution and v8impl::Reference::InvokeFinalizerFromGC.
• Renderer physical footprint was ~446 MB at sample time, with an ~889 MB peak since the fresh launch.
• codex app-server briefly reached ~21% CPU and ~550 MB RSS, although a later sample mostly found its Tokio workers waiting rather than a continuously hot loop.
• One minute of the fresh session generated 1,097 SQLite log rows / ~2.81 MB estimated payload. About 2.37 MB came from rmcp::service; other leading sources were MCP connection management and app-server outgoing-message TRACE logs.
• SQLite WAL size remained stable during a short six-second sample, so this still does not prove continuous disk-write churn.

The desktop startup log also emitted repeated:

• ResizeObserver loop completed with undelivered notifications
• IAB_LIFECYCLE route window is not live
• IAB_LIFECYCLE browser use route window missing for cursor/active state

Those Browser Use warnings referenced many existing and client-new-thread conversation IDs during startup reconciliation. They appear related to the IAB route-management issue family (for example #20678), but I cannot prove they are the primary cause of the UI lag. My current read is that they may amplify the long-thread/state-replay problem described here.

System pressure remained low: zero swap and generally high CPU idle. This makes a persistent Desktop build/state-reconciliation issue more likely than machine-wide resource pressure.

Adding a fresh Windows Desktop reproduction from the current app build. This appears to match this issue and the symptoms reported in #19923 and #20544.

Environment

• OpenAI Codex Desktop: 26.707.12708.0
• Windows 11 Home Single Language, version 10.0.26200 (build 26200)
• 32 GB RAM
• AMD Ryzen 9 5900HX, 16 logical processors
• AMD Radeon Graphics driver 31.0.21925.1001 (2026-05-20)
• NVIDIA GeForce RTX 3070 Laptop GPU driver 32.0.16.1074 (2026-02-07)

Reproduction and symptoms

1. Start Codex Desktop and switch between local threads.
2. Opening certain tool-heavy or image/screenshot-heavy threads makes mouse-pointer movement and typing in Codex stutter for several seconds.
3. The UI then recovers without a formal application hang.
4. Some affected threads have only one to three visible user turns, so visible conversation length is not a useful predictor; the hidden tool/output history appears to matter much more.

Privacy-safe local measurements

During a 35-second sample while opening an affected thread:

• The main ChatGPT.exe process working set grew from about 356 MB to 1,784 MB.
• Its peak CPU was 9.77% of total system CPU across 16 logical processors.
• Other renderer/GPU/utility child processes were mostly idle during the spike.
• The main process later returned to about 364 MB working set after the UI recovered.
• Across all Codex/ChatGPT processes, combined working set rose from about 1.36 GB to 2.46 GB, with private memory peaking around 2.84 GB.

Examples of short but internally heavy local histories:

• A Blender/computer-use thread with one completed visible turn: 5.72 MB rollout, 289 JSONL records, 78 tool-output-related lines, and 14 image/screenshot-related lines.
• Another short Blender thread: 4.83 MB rollout, 282 JSONL records.
• No raw thread contents, paths, IDs, images, or unsanitized logs are included here.

Troubleshooting already performed

• Clean reboot.
• Updated the AMD display driver and verified both active display-driver versions.
• Forced the Codex executable to the high-performance GPU preference.
• Closed the separate ChatGPT Classic app.
• Cleared/moved seven temporary caches (HTTP, GPU, shader, Dawn, and Sentry queue) and restarted Codex.
• Checked Windows Application Error/Hang events; no new formal hang event was recorded during this reproduction.
• System RAM was not exhausted.

The behavior remained unchanged after all of the above. The transient growth and later release of the main-process working set make this look like expensive thread-state materialization/deserialization or GC on the UI-critical path rather than a GPU-driver or machine-capacity problem.

Expected behavior: old tool outputs and image/screenshot records should be lazily hydrated or virtualized so that switching threads does not block pointer and keyboard input.

I can provide sanitized per-process samples or collect a specific performance trace if maintainers indicate which artifact would be most useful.

Adding a sanitized current-build macOS reproduction. The app did not crash during the 12-minute live capture, so the numbers below distinguish measured resource pressure from the user-reported long-task crashes.

Environment

• ChatGPT Desktop 26.715.72359 (build 5718) with bundled codex-cli 0.145.0-alpha.30
• macOS 26.5.1 (25F80), Apple Silicon, 16 GB RAM

Live measurements

• 168 active rollout JSONL files totaling 13.97 GiB
• 59 rollout files over 100 MiB; 5 over 250 MiB
• Largest active rollout: 383.1 MiB / 33,219 JSONL records
• Largest-rollout byte breakdown:
• event_msg/mcp_tool_call_end: 166.6 MiB
• response_item/custom_tool_call_output: 96.0 MiB
• compacted/message: 85.8 MiB
• Summed RSS for the full app/process tree ranged from 4.56–7.37 GiB (shared pages may be double-counted)
• The bundled Codex app-server/worker peaked near 1.25 GiB RSS, then later fell to about 365 MiB. This was not a simple monotonic heap-growth pattern.
• logs_2.sqlite was about 366 MiB plus WAL, with about 254k rows. High-volume classes included:
• codex_api::sse::responses TRACE: 43,106 rows / estimated 44.9 MiB
• codex_core::stream_events_utils DEBUG: 21,125 rows / estimated 38.5 MiB
• codex_mcp::connection_manager TRACE: 32,182 rows / estimated 27.6 MiB
• rmcp::service TRACE: 595 rows / estimated 17.2 MiB

macOS resource diagnostics from the same machine

• A bundled codex disk-write diagnostic recorded 2.15 GB of file-backed writes in 269 seconds while footprint grew from 147.8 MB to 1.97 GB
• A later ChatGPT diagnostic recorded 8.59 GB of file-backed writes over 5,161 seconds while footprint grew from 322 MB to 1.62 GB (peak about 1.71 GB)
• Free disk reached about 2.60 GB during that event

Interpretation

This looks like episodic memory/I/O amplification when large histories are materialized or replayed, combined with high-volume TRACE/SSE/MCP persistence—not solely a conventional monotonic memory leak. The largest rollout is dominated by tool/MCP outputs and compacted history, which also corroborates #24948, while the user-visible impact matches this Desktop renderer/app-server issue.

Useful acceptance criteria would be:

1. Bound or deduplicate tool/MCP output persisted in rollout history.
2. Avoid re-embedding large prior histories in compaction records.
3. Paginate/lazily replay oversized histories instead of materializing them wholesale.
4. Rotate/bound SQLite TRACE logs and reduce idle MCP/SSE churn.
5. Reap per-thread helper processes after threads become inactive.
6. Add low-disk and high-memory guardrails before the Desktop app becomes unstable.

Adding a sanitized Windows reproduction from the current Desktop build. The behavior started after the recent update and the app now intermittently terminates/restarts.

Environment

• Codex Desktop package: OpenAI.Codex_26.721.4979.0_x64
• Windows x64
• Installed RAM: 16 GB (13.9 GB usable)
• Main affected process: codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled

Direct measurements

• The app-server private commit grew from approximately 17.7 GB to 20.9 GB in 10 seconds.
• A separate sample reached approximately 27.4 GB private commit.
• Physical working set fluctuated sharply as Windows compressed/paged memory; total system memory reached 95–96%.
• Disk activity reached roughly 140–220 MB/s during the incident, consistent with severe paging/I/O pressure.
• logs_2.sqlite: approximately 568 MB
• logs_2.sqlite-wal: approximately 305 MB
• Recent log targets included high-volume TRACE entries from codex_app_server::outgoing_message and codex_api::sse::responses.
• Electron renderer/GPU/utility processes were comparatively small; the native app-server was the dominant memory consumer.
• The application intermittently stops, making the Desktop workflow unreliable.

The local configuration uses supported settings and does not explain an app-server allocation of this magnitude. No personal paths, thread contents, or unsanitized logs are included here.

This is especially frustrating on a paid plan costing approximately EUR 220/month: the Windows Desktop application is currently not dependable enough for sustained work.

I can collect additional privacy-safe counters or a specific diagnostic trace if maintainers provide instructions.

I can reproduce substantial codex app-server memory growth on the same Windows build reported here.

Environment

• Codex MSIX: OpenAI.Codex_26.721.4979.0_x64
• App version: 26.721.41059
• Backend: 0.146.0-alpha.3.1
• Command:

codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled

Memory observations

During active use, app-server private memory increased from approximately 1.00 GiB to 1.87 GiB in about seven minutes and briefly reached approximately 1.92 GiB. It later fell to approximately 1.72 GiB, so this short sample does not prove strictly monotonic leakage, but app-server was clearly the dominant Codex process.

Historical Windows Resource Exhaustion events from an earlier 26.715 session show codex.exe reaching approximately 6.17–6.71 GiB after many hours, plus 1.43–1.63 GiB in the Electron process.

Logging observations

~/.codex/logs_2.sqlite currently contains approximately:

• 1.81 GB physical size
• 608k retained rows
• 937 MB estimated live log data
• 1,566 distinct thread partitions
• 929 MB attributed to thread-scoped partitions
• individual TRACE rows up to 3.57 MB

The largest contributors are HTTP transport, SSE responses, and stream-event logging. Roughly 89.6 MB of HTTP transport logs and 63 MB of SSE logs were added during the most recent 24-hour window.

The public log sink appears to use a queue bounded by entry count rather than bytes (512 entries, batches of 128). With multi-megabyte entries, this could temporarily retain hundreds of MiB or more, with additional copies created during formatting and SQLite insertion. Allocator high-water behavior could then keep app-server private memory elevated after the queue drains.

The database quota also appears to be approximately 10 MiB per thread rather than a comparable global limit, allowing aggregate storage and maintenance work to scale with the number of tasks.

Thread cleanup

The Desktop bundle does implement inactive-thread cleanup: one-hour TTL, no more than four inactive owner threads, followed by thread/unsubscribe. I found eight successful unsubscribe events in a long session, so this does not appear to be a simple case where no threads are ever released.

Overall, the evidence looks more like large-payload logging plus thread/history retention and transient duplication than one simple monotonic leak.

Would it make sense to:

1. bound the log queue by total bytes as well as entry count;
2. truncate large diagnostic payloads before they reach every sink;
3. introduce a global log database budget in addition to per-thread limits?

Fresh Windows reproduction on the current stable Microsoft Store build adds a fairly strong renderer-side A/B data point.

Environment

Codex Desktop package: OpenAI.Codex 26.721.4979.0
Chromium: 150.0.7871.128
OS: Windows 11 Pro 10.0.26200, x64
Logical CPUs: 32
Installed RAM: 128 GB

The public stable Windows update manifest also reported 26.721.4979.0, so no newer stable build was available during the test.

Symptom

Typing in the composer lagged behind keystrokes while one long-running remote/WSL task was actively streaming events. The rest of Windows remained responsive.

System-wide exhaustion was ruled out during the incident:

Free RAM: approximately 33.6 GB
Disk queue: approximately 0.11
Disk active time: approximately 3.5%
GPU status: healthy; low single-digit 3D utilization

The primary Electron renderer was the clear local hot process:

Private memory observed: approximately 2.3-3.5 GB
Working set observed: approximately 1.9-3.0 GB
CPU: commonly 60-90% of one core
30-second allocation sample: 3363 -> 3400 -> 3450 -> 3490 MB, followed by a GC drop to approximately 2742 MB

This looked like sustained allocation/GC churn rather than system RAM pressure or an OOM condition.

Renderer-state evidence

Sanitized counts from the current day's Desktop logs:

[electron-message-handler] errors: 4,302
Received ... for unknown conversation: 880
Conversation state not found: 916
Item not found in turn state: 2,073
ResizeObserver errors: 427
OOM / heap failure: 0

One representative hour contained:

log lines: 1,915
renderer/message-handler errors: 281
Item not found in turn state: 269
distinct conversation/thread IDs represented: 13

The event volume was dominated by the one active long-running task and its related work. Its local rollout was only about 45.5 MB, so this reproduced well below the several-hundred-megabyte histories reported in some related issues.

A previously diagnosed WSL repository-watcher loop was explicitly ruled out in the fresh logs:

Starting git repo watcher: 73
watcher errors: 0
EISDIR: 0
active \\wsl$ path events: 0

The active projects were already registered through the native remote WSL host with Linux paths, rather than Windows UNC paths.

Recovery A/B

I recycled only the overloaded primary renderer. The installed app's own render-process-gone handler reloaded the window after 500 ms; the Electron main process and the active remote task both remained alive.

After initial history/event replay, the replacement renderer settled at:

Private memory: approximately 303 MB
CPU over a 10-second sample: 3.1% of one core

Composer responsiveness recovered immediately. This strongly separates the UI lag from model/service latency, disk pressure, GPU load, and the remote task runtime itself. The backend task could keep running normally while a clean renderer remained responsive.

Suspected failure mode

A long-lived renderer appears to lose synchronization with live conversation/turn/item state. It then continues accepting and logging events for missing conversations or turn items. Processing/dropping those events creates sustained allocation and GC pressure on the same renderer responsible for the composer, causing delayed typing.

This seems closely related to #24263 and the state/ownership section of #25779, while #34450 captures the Windows input-lag symptom.

Requested behavior

• Missing/stale conversation or turn-item events should be discarded or reconciled without an allocation/log storm.
• Repeated identical state errors should be deduplicated or rate-limited.
• Background active tasks should not be able to monopolize the primary renderer event loop.
• Renderer state should be bounded and independently recoverable without requiring a full application restart.
• A performance diagnostic should identify the thread/event source responsible for renderer pressure.

Raw logs and local rollouts are not attached because they may contain private prompts and filesystem paths. Sanitized targeted diagnostics can be provided if maintainers specify the fields needed.

This is also blocking the main Pro workflow I want to use: keep several mature project chats alive, switch among them quickly, and delegate new tasks as priorities change. The $200/month plan is a great value in terms of capacity, but repeated thread hydration makes that capacity difficult to use—switching back to a long-running project can stall long enough that managing several in parallel becomes impractical.

Please treat fast multi-thread switching as a core workflow, not an edge case. Ideally, switching should load metadata plus a bounded recent tail immediately, lazy-load older UI history and heavy tool payloads, and keep compacted agent context ready without rehydrating the full rollout. One large or old project should never block the composer or make other project chats unresponsive.

Even when hydration must continue in the background, the text-entry field should remain independently responsive: it should keep accepting and preserving every keystroke while the rest of the thread loads or hangs. By the time I finish typing, hydration may already be complete—but currently hydration freezes the composer itself, sometimes triggering the Windows “program is not responding” dialog while I am typing and creating a risk of accidentally killing the app or losing the draft. Ideally the composer/draft state would be isolated from heavy thread rendering and loading, with only submission waiting when strictly necessary.

<details>
<summary>Sanitized local evidence from one occurrence (Windows Desktop 26.727.51351)</summary>

All times below are local; thread IDs, turn IDs, paths, workspace names, account data, and message contents are omitted.

09:58:45  Windows Error Reporting: AppHangTransient
09:59:12  Windows Error Reporting: AppHangTransient

These two events were post-restart, while typing and while startup restoration/hydration was still active. In the first 68 seconds after restart, the renderer requested skills/list 8 times and plugin/list 4 times. In the 150 seconds before restart, it requested thread/turns/list 13 times and skills/list 9 times.

The mature rollout involved in the switching investigation was 314,596,334 bytes (about 300 MiB) with 32,515 JSONL records. During the surrounding 15-minute app-server log window there were 504 rows, including 54 codex_core_skills::loader warnings, 38 codex_core_plugins::manifest warnings, and 4 codex_app_server::request_processors::thread_processor warnings. No disk or storage-controller errors were found in the same incident window.

A separate pre-restart symptom occurred in the same session: a turn/start request did not create an active/durable turn while Desktop and mobile displayed Thinking. That turn-lifecycle stall is not the mid-typing composer hang described above; it is included only as nearby state-desynchronization context.

</details>

Adding a fresh sanitized Windows reproduction from the current stable Desktop package.

Environment:

• Windows x64
• ChatGPT/Codex Desktop package: OpenAI.Codex_26.803.5235.0_x64
• Affected workflow: one long, tool-heavy active thread with several concurrent subagents
• Symptom: composer typing becomes visibly delayed while Windows itself remains responsive

Privacy-safe process snapshots from the installed observe-only watchdog:

• At 06:37Z, primary renderer private working set: 726.8 MiB; native codex.exe app-server: 307.7 MiB.
• At about 07:17Z, the same renderer PID was approximately 1,309 MiB private / 1,148 MiB working set; the same app-server PID was approximately 622 MiB private / 576 MiB working set.
• That is roughly +582 MiB renderer private and +315 MiB app-server private in about 40 minutes while continuing the same task.
• The app process tree remained otherwise bounded (7 renderer processes; inactive renderers were small). This is not a many-renderer explosion.

Local diagnostic DB, queried read-only while the app was running:

• logs_2.sqlite: 467,456,000 bytes
• retained rows: 156,756
• WAL: about 4.6 MB
• freelist: 44,518 pages, about 182 MB reclaimable inside the main DB
• most recent hour: 6,760 rows / 6,908,576 estimated bytes
• top recent targets:
• codex_api::sse::responses: 1,983 rows / 2.15 MB
• codex_core::stream_events_utils: 1,650 / 1.89 MB
• codex_app_server::outgoing_message: 913 / 0.16 MB
• feedback_tags: 809 / 1.24 MB

A bounded tail scan of 12 local diagnostic log files found 0 unknown conversation event matches in the scanned tails. The current day's sandbox log also had 0 new os-error-206 matches in its last 400 lines after switching away from the previously broken elevated helper path. Therefore this occurrence does not require an unknown-event storm or sandbox-helper failures; long-thread event materialization plus TRACE/SSE persistence remains sufficient to reproduce typing lag and sustained renderer/app-server growth.

The local watchdog is event-first, observe-only, and performed 0 process reclaims / 0 app restarts. It records sanitized memory/process evidence but cannot repair the packaged renderer/app-server. This fresh build still needs bounded/lazy thread hydration, byte-bounded TRACE logging, and renderer-state release without a full app restart.

No raw thread content, IDs, prompts, paths, command lines, credentials, or log bodies are included.