Component
Codex desktop app
What happened?
When a Codex conversation runs for a long time, the local rollout/history JSONL file can grow to hundreds of MB. I have several sessions that are around 500 MB or larger.
When I continue working with those long-running sessions in the Codex desktop app, the app can freeze for a noticeable amount of time, especially when sending a new prompt.
I suspect the hot path may be doing too much work over the full session history file, or otherwise synchronously processing more of the rollout/history than is needed for the current UI action.
Expected behavior
Continuing a long-running session should remain responsive even if the persisted history file is very large.
Sending a new prompt should not require the app UI to block on reading/parsing/processing the entire history file.
Steps / observed workflow
- Use the same Codex conversation for a long-running development workflow across many turns.
- Let the local rollout/history JSONL file grow very large. In my case I have multiple session files around 500 MB or larger.
- Open or continue that existing conversation in the Codex desktop app.
- Send a new prompt.
- Observe that the app can become temporarily unresponsive before it continues.
Possible direction
I built a local helper/web prototype that works around this while keeping Codex's original files untouched:
- index session summaries and recent user/assistant messages into local SQLite;
- serve the session list from SQLite instead of parsing large rollout files in the request path;
- for active sessions, read only a bounded head/tail window;
- lazy-load heavy technical records such as tool output, command output, and event records only when opened;
- keep the original JSONL files unchanged so CLI/app compatibility is preserved.
This made the remote UI stay responsive even with very large session files.
I think Codex could either change the long-term session storage model, or, if JSONL needs to remain for compatibility/legacy/architecture reasons, keep the current format but add an indexed/cache-backed read path for summaries, recent messages, and lazy technical output.
Environment
- Primarily observed with Codex desktop app on Windows.
- Related investigation also done from macOS.
- Exact Codex app version / OS build / hardware details can be provided if useful.
Related discussion
#22987
Component
Codex desktop app
What happened?
When a Codex conversation runs for a long time, the local rollout/history JSONL file can grow to hundreds of MB. I have several sessions that are around 500 MB or larger.
When I continue working with those long-running sessions in the Codex desktop app, the app can freeze for a noticeable amount of time, especially when sending a new prompt.
I suspect the hot path may be doing too much work over the full session history file, or otherwise synchronously processing more of the rollout/history than is needed for the current UI action.
Expected behavior
Continuing a long-running session should remain responsive even if the persisted history file is very large.
Sending a new prompt should not require the app UI to block on reading/parsing/processing the entire history file.
Steps / observed workflow
Possible direction
I built a local helper/web prototype that works around this while keeping Codex's original files untouched:
This made the remote UI stay responsive even with very large session files.
I think Codex could either change the long-term session storage model, or, if JSONL needs to remain for compatibility/legacy/architecture reasons, keep the current format but add an indexed/cache-backed read path for summaries, recent messages, and lazy technical output.
Environment
Related discussion
#22987