Desktop Codex cannot open older chat sessions after recent update

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

• #25430

Powered by Codex Action

I reviewed issue #25430.

My case appears different:

• My session files are relatively small (largest files are approximately 1–2 MB).
• New chats open normally.
• The problem started immediately after a recent update.
• Opening older chats results in:

"memory allocation of 2862678 bytes failed"

• session_index.jsonl is only 1974 bytes and contains 14 entries.
• The issue does not appear to be caused by unusually large session files.

This may be a separate regression affecting loading or migration of older sessions after an update.

I updated Codex Desktop to Version 26.601.21317, released June 3, 2026.

The issue is still present.

Older chat contents that were visible before the previous update still do not appear. New chats continue to work normally.

This does not seem to be fixed in 26.601.21317.

Important clarification:

The old chats are still present in the chat list.

The problem is not that the chats disappeared.

The problem is that chats created before the update no longer display their message contents.

Before the update, the contents of these chats were visible.

After the update:

• old chats appear in the list but their messages are not displayed;
• new chats created after the update work normally and display messages correctly.

This suggests a regression in loading or rendering chat history created by a previous version.

<img width="1919" height="1079" alt="Image" src="https://github.com/user-attachments/assets/0feb3df6-a853-48ea-a609-77735b640c9d" />
Additional observation:

While Codex was running normally, with Chrome open and no actions being performed, Codex became unresponsive and displayed:

"Codex (Not Responding)"

Then an internal crash dialog appeared with:

(code=3221226505, signal=null)

Most recent error:
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Chrome was closed at approximately the same time.

This occurred on Version 26.601.21317.

Additional information:

I verified that the old session files are not empty and do contain the conversation data.

The JSONL session files still contain messages and metadata from previous chats.

The problem is not data loss.

The issue is that chats created before the update no longer display their contents in the Codex Desktop UI.

Chats created after the update display normally.

This appears to be a session loading/rendering compatibility issue rather than missing or corrupted session files.

Additional findings after further investigation:

The old chat sessions do not appear to be lost.

I manually inspected the JSONL session files stored in ~/.codex/sessions and confirmed that they still contain conversation messages and metadata.

Behavior observed:

• Chats created before the update are still listed.
• Their contents are no longer displayed in the Codex Desktop UI.
• New chats created after the update display normally.
• The issue persists after updating to Version 26.601.21317 (June 3, 2026).

This suggests that the session data still exists, but Codex is failing to load or render conversations created by a previous version.

Additionally, Codex occasionally becomes unresponsive and crashes with:

(code=3221226505, signal=null)

while running on Version 26.601.21317.

Correction / additional data:

I rechecked the real session file sizes. Some old session files are large:

• one session is about 624 MB
• one session is about 51 MB
• several sessions are around 18–19 MB

So this may be related to loading large legacy session files.

However, new chats work normally, and the issue appeared only after the update.

Additional findings after further testing:

I moved the largest session file (~624 MB) out of the ~/.codex/sessions directory for testing.

After removing that session, Codex displayed 13 chats instead of 14, confirming that one session file corresponds to one chat.

However, the issue is still present.

Opening other legacy chats created before the update still causes severe memory usage spikes:

• RAM usage reaches nearly 100% (15.7 GB / 15.8 GB)
• Committed memory grows to approximately 29-46 GB
• Disk usage reaches 100%
• Codex becomes unresponsive and may crash

The issue is therefore not limited to the largest 624 MB session.

Several remaining legacy sessions are significantly smaller (approximately 51 MB, 19 MB, and 18.75 MB), but opening some of them can still reproduce the problem.

In one case, after opening a legacy chat, memory usage increased rapidly and Windows Explorer became unstable. The desktop turned black and Explorer had to be restarted manually.

Additional observations:

• New chats created after the update work normally.
• Legacy session files still contain valid conversation data.
• The chats are still listed, but older chats often fail to display their contents correctly.
• Removing the largest session did not resolve the issue.

This suggests the problem may be related to loading legacy sessions in general, rather than only extremely large session files.

Additional update:

After restarting Codex several times, I opened one of the most recent chats.

That chat also no longer displays messages that I had written earlier.

So the issue may not be limited only to older legacy chats. It can also affect recent chats after restarting Codex.

The session files appear to still exist on disk, but the Codex Desktop UI may fail to display the saved message contents after restart.

<img width="1919" height="1072" alt="Image" src="https://github.com/user-attachments/assets/bd0f7952-6a7a-4d34-ac4d-09c30bd9609f" />

Additional crash information:

I encountered another crash while testing.

This time the crash dialog reported:

(code=3221226505, signal=null)

Most recent error: write EPIPE

Previously I had also seen:

• memory allocation failed
• high memory usage (up to 99% RAM)
• committed memory growth to approximately 29-46 GB

The error message appears to vary, but the crashes continue to occur while interacting with legacy chats.

I reviewed #26157. It looks related because my local session files also still exist, but Codex Desktop does not display the saved conversation contents correctly.

However, my case also includes severe memory spikes and crashes when opening affected sessions:

• RAM usage reaches nearly 100%
• committed memory grows to around 29-46 GB
• disk usage reaches 100%
• crashes include memory allocation failed, write EPIPE, and (code=3221226505, signal=null)

So this may be related to the same session/sidebar history mapping issue, but with an additional crash/memory leak behavior on Windows.

Additional detail:

The latest crash happened after I clicked/opened older chats in Codex and then continued browsing in Chrome. Codex was not actively being used at the moment of the crash, but it had previously been asked to open legacy chats.

During the crash, all windows were minimized and Codex showed another memory allocation failed error.

Additional observations after updating to Version 26.602.30954 (Released Jun 4, 2026).

The issue is still reproducible.

Steps:

1. Start Codex normally.
2. Open one of the affected older chats.
3. Memory usage begins increasing rapidly.

Observed behavior:

• Codex memory usage grows to approximately 10 GB RAM.
• Windows total memory usage reaches 90–96%.
• Memory usage does not stabilize.
• After some time Codex crashes with:

memory allocation failed

I also observed a pattern where memory usage suddenly drops by several GB and then starts growing again, which looks like a reload/reindex/retry loop.

Example process snapshot:

Get-Process codex | Select Id,WS,CPU

showed a Codex process using approximately:

WS = 10,167,898,112 bytes (~9.5 GB RAM)

The problem is therefore still present in Version 26.602.30954.

Tested again on:

Version 26.602.40724
Released Jun 5, 2026

The issue is still reproducible.

Steps:

1. Open Codex.
2. Click the affected legacy chat ("VIAL LMS" in my case).
3. The chat content never appears.
4. The chat window stays blank.
5. Memory usage continuously increases.

Observed memory growth:

~9.8 GB
→ ~12.2 GB
→ ~15.0 GB
→ ~15.3 GB

Available system memory dropped below 1 GB.

The chat content never rendered during the test.

This reproduces consistently after updating to 26.602.40724.

It appears that opening the affected chat triggers an uncontrolled memory growth loop while the chat itself remains blank.

Additional update on Version 26.602.40724 (Released Jun 5, 2026):

The issue is still reproducible.

After opening the affected legacy chat:

• The chat content remains blank and does not render.
• Memory usage starts increasing continuously.
• System memory reached around 95–97%.
• Eventually Codex crashed again.

Crash dialog:

(code=3221226505, signal=null)

Most recent error:

memory allocation of 1472574 bytes failed

This confirms that the legacy chat loading / memory growth issue is still present in Version 26.602.40724.

New projects and new chats appear to work normally on 26.602.40724.

The memory leak only reproduces when opening specific legacy chats/projects.

Opening a new project keeps memory stable (~6–7 GB on my system).

Opening the affected legacy chat still causes memory growth until crash.

Additional finding:

I tried to recover the affected legacy chat by creating/forking it into a new chat.

Codex successfully found the old thread and started the operation:

Forking thread

However, the fork operation never completed.

During the fork attempt, memory usage increased continuously until the system reached 100% RAM usage.

Observed committed memory:

• around 50.1 / 51.0 GB
• then around 54.4 / 55.1 GB

Codex eventually crashed with:

(code=3221226505, signal=null)

Most recent error:

memory allocation of 2862678 bytes failed

The affected legacy chat cannot be opened directly, and it also cannot be forked into a new chat.

So the issue is triggered both when opening the affected legacy chat and when trying to fork/continue that legacy thread into a new chat.

Additional reproduction details:

The issue is now consistently reproducible for at least one affected legacy chat.

Steps:

1. Launch Codex normally.
2. Open any new chat or new project.
3. New chats work normally and memory usage stays relatively stable.
4. Open the affected legacy chat.
5. The chat content never appears and the chat area remains blank.
6. Memory usage immediately starts increasing.
7. RAM usage continues growing until Codex crashes.

Observed behavior:

• New chats/projects work normally.
• The affected legacy chat remains blank.
• Memory starts increasing before the chat content is rendered.
• Memory keeps increasing even if no message is being generated.
• After closing Codex, memory usage immediately drops back to normal.
• After pressing "Reload" in the crash dialog and opening the same legacy chat again, the same memory growth starts again.

I also tested recovering the affected legacy chat by forking/continuing it into a new chat.

Codex successfully found the thread and started:

Forking thread

However, the fork operation never completed.

During the fork attempt, memory usage increased continuously until the system reached 100% RAM usage.

Observed committed memory:

• around 50.1 / 51.0 GB
• then around 54.4 / 55.1 GB

Codex eventually crashed with:

(code=3221226505, signal=null)

Errors observed:

• memory allocation failed
• write EPIPE

So the issue is triggered both when opening the affected legacy chat directly and when trying to fork/continue that legacy thread into a new chat.

Additional note:

I also observed that Codex sometimes closes by itself while working in new chats. This behavior is less reproducible than the legacy chat issue, but it has occurred during normal use after the recent updates.

Update after testing Version 26.609.30741 (Released June 11, 2026)

The issue is improved compared to previous builds, but it is not fully resolved.

Environment:

• Codex Version: 26.609.30741
• Windows 11
• 32 GB RAM

Current behavior:

1. Small and recently created chats open normally.
2. Switching between small chats works correctly.
3. Codex no longer crashes immediately when opening the affected legacy chat.
4. The affected legacy chat can eventually be opened.

However, after every complete Codex restart, opening the same large legacy chat triggers extremely heavy memory usage again.

Reproducible scenario:

1. Fully close Codex.
2. Launch Codex again.
3. Open the same large legacy chat.
4. Observe memory and disk activity during loading.

Observed behavior during loading:

• Physical RAM gradually increases until reaching nearly 100% usage (31.8 GB / 32 GB).
• Commit size grows dramatically:

• ~62 GB
• ~83 GB
• ~95 GB
• ~101 GB
• ~107 GB

At the same time:

• CPU usage remains elevated (approximately 50–80%).
• SSD activity frequently reaches 100%.

After reaching peak memory usage, Codex suddenly releases a large amount of memory:

• RAM drops from ~32 GB to ~11 GB.
• Commit size drops from ~107 GB to ~35 GB.

After that, a second processing cycle begins:

• Memory usage increases again.
• Additional CPU and SSD activity occurs.

Finally, after the chat is fully loaded:

• RAM returns to approximately 5–6 GB.
• Commit size returns to approximately 13 GB.

Additional observation:

This behavior was reproduced multiple times after fresh application launches and follows nearly the same pattern every time.

Conclusion:

The problem does not currently appear to be a classic memory leak because memory is eventually released.

Instead, it looks like Codex performs one or more extremely memory-intensive reconstruction/indexing/loading passes when opening a very large legacy chat.

The chat eventually loads successfully, but the temporary resource consumption is excessive:

• RAM reaches 100% utilization.
• Commit size exceeds 100 GB.
• SSD activity reaches 100%.
• Loading may take approximately 8–10 minutes.

It may be useful to investigate the loading, indexing, reconstruction, search-index generation, attachment processing, or caching mechanisms used for very large legacy conversations after a fresh application start.

Additional observation in Version 26.623.42026 (Released June 27, 2026)

There is another long-standing issue that appears to be independent of the large legacy chat loading problem.

Codex sometimes closes unexpectedly without any warning.

Observed conditions:

• Version: 26.623.42026
• Windows 11
• 32 GB RAM

At the time of the unexpected shutdown:

• RAM usage was only about 10.4 GB out of 32 GB (approximately 33%).
• Commit size was about 15.4 GB.
• CPU usage was essentially idle.
• Disk activity was minimal.
• No heavy processing was taking place.
• The application simply closed by itself.

This has been occurring for a long time across multiple versions.

It does not appear to depend on memory pressure, active tasks, or large chat loading. The application may terminate even while it is idle or during normal use.

The attached Task Manager graph shows a sudden drop in memory usage exactly when the Codex process exited.

This seems to be a separate stability issue from the excessive memory consumption when loading large legacy chats.

Update after testing Version 26.623.61825 (Released June 29, 2026)

There are noticeable improvements compared to previous builds.

The large legacy chat now remains usable during normal work.

During execution of a long task, memory usage no longer grows uncontrollably to nearly all available RAM or extremely high commit sizes as observed in earlier versions.

Instead, memory now follows a repeating wave-like pattern:

• RAM gradually increases (approximately 11–15 GB on my system).
• Commit size remains around 18–22 GB.
• Memory is periodically released.
• The cycle then repeats while the task continues.

This behavior appears stable and may indicate that internal caching or garbage collection has improved.

However, one important issue still remains.

Codex can still unexpectedly close itself while executing a long-running task.

In my latest test:

• a task was actively running,
• available RAM was sufficient,
• there was no memory pressure,
• the application suddenly terminated by itself,
• the task was interrupted before completion,
• I had to restart Codex manually.

After updating to Version 26.623.61825 and reopening the same large chat, the application continued working correctly and successfully completed the task.

Based on these observations, it seems that memory management has improved significantly, but there is still an issue causing unexpected application termination during long-running workloads.

I have attached Task Manager screenshots showing the new wave-like memory behavior during normal operation.

Update after testing multiple recent builds

I tested several recent Codex releases, including:

26.609.30741
26.623.42026
26.623.61825
26.623.81905 (Released July 1, 2026)

There has been clear progress compared to the original issue.

Improvements

Memory management has improved significantly.

Previously, opening my largest legacy chat could consume nearly all available RAM and over 100 GB of committed memory before eventually recovering.

With the latest builds, the same chat is usable again.

During long-running work, memory now follows a repeating allocation/release pattern instead of continuously increasing.

Typical values on my system are approximately:

RAM: 11–15 GB
Commit: 18–22 GB

Memory periodically drops and then grows again while the task continues.

This looks much healthier than previous versions.

Remaining issues

Unfortunately, two major stability problems still remain.

1. Unexpected application termination

Codex still occasionally closes itself without any error message.

This happens:

during long-running tasks,
while simply working in chats,
and even when memory usage is completely normal.

When this happens, every running task is interrupted and I have to start Codex again manually.

This appears unrelated to memory exhaustion.

1. Internal task state becomes corrupted

On several occasions Codex stopped responding while processing a task.

After that:

the current task never completed;
new tasks could not be started;
attempting to submit another task returned:
Error creating task

no active turn to steer

Restarting Codex was the only way to recover.

This looks like an internal state-management issue rather than a memory problem.

Additional observations

I attached Task Manager screenshots showing the current memory behavior.

The wave-like memory allocation/release pattern itself does not appear to be the problem anymore.

The remaining concern is application stability: unexpected termination and loss of the current execution state.

Overall, recent releases have significantly improved memory handling for large legacy chats, but stability issues are still preventing reliable long-running work.

Thank you for continuing to improve this.

<img width="898" height="940" alt="Image" src="https://github.com/user-attachments/assets/922a6493-6a15-47c7-837e-89fc4ebd1258" />

Additional observation with Version 26.623.81905.

After one of the unexpected application exits, I started Codex again.

Shortly after opening one of my chats, Codex displayed the built-in crash dialog instead of silently closing.

The reported error was:

(code=3221226505, signal=null)

Most recent error:
memory allocation of 1824962 bytes failed

The allocation size is only about 1.8 MB.

At the time of the crash, my system still had plenty of available memory (roughly 17–20 GB free based on Task Manager observations), so this does not appear to be a simple out-of-memory condition.

Another observation:

Pressing the "Restart Codex" button did not appear to fully restart the application process. It immediately returned to the previously opened chat instead of performing what looked like a complete application restart.

This may indicate that the crash recovery or restart mechanism is not performing a full process restart.

I ran into a very similar issue on Windows and managed to recover my older chats.

My symptoms were close to this issue:

• Older chats/reviews would not load.
• New chats still worked.
• Codex left multiple processes running.
• I saw memory allocation errors like 3400070 bytes failed.
• Windows also logged a native Codex crash with 0xc0000409 / decimal 3221226505.

In my case, the root cause seemed to be local session data, not my project code.

What I found:

1. One session file under ~/.codex/sessions had grown to 11.6 GiB and was still referenced from ~/.codex/session_index.jsonl.
2. Some older session .jsonl files contained Codex directives such as ::git-stage{...} / ::git-commit{...} with Windows paths using backslashes, e.g. C:\Users\.... I found that clue in this other report: https://github.com/openai/codex/issues/22985

What fixed it for me:

1. Closed Codex completely.
2. Backed up the affected files.
3. Moved the huge session .jsonl out of ~/.codex/sessions into a quarantine/backup folder.
4. Removed that session’s entry from ~/.codex/session_index.jsonl.
5. Rewrote the affected directive paths in the remaining .jsonl files from Windows backslash paths to forward-slash paths inside the directive attributes, e.g. C:\Users\... -> C:/Users/....
6. Reopened Codex.

After that, older chats started loading again.

One important caveat: in your report you mention the largest session files are only around 1-2 MB, so the “giant session file” part may not apply to you. But the directive/path issue from #22985 may still be worth checking for in older session .jsonl files.

I would strongly recommend backing up ~/.codex/sessions and ~/.codex/session_index.jsonl before editing anything.