So far, the most likely main cause of the "crash" is not the Codex itself, but the abnormal expansion of chat history persistence in NeverWrite.
Key evidence:
- lianaichat: The transcript.jsonl files of the last 3 Codex sessions are abnormally large:
- 246 MB, with 28,571 actual lines, but session-meta.json only indexes 94 messages.
- 152 MB, with 27,437 actual lines, only indexing 169 messages.
- 48 MB, with 5,457 actual lines, only indexing 75 messages.
- The largest file only has 94 unique message IDs, but there are 28,477 lines with duplicate IDs; some tool:call_* were repeatedly written thousands of times.
- There is a RADAR_PRE_LEAK_64 for NeverWrite.exe in the Windows event log, which is usually a warning of memory leak or memory pressure, and it is highly consistent with hundreds of MB of chat history being repeatedly loaded and saved.
- In the code, save_session_history appends to transcript.jsonl, and old version messages are not compressed or cleaned up, as seen in /C:/Users/ziwenchen/AppData/Local/Temp/neverwrite-src/crates/ai/src/persistence.rs:673. If tool messages are continuously updated, it is easy to repeatedly append old versions of the same message. to...
There are also two independent questions:
- 3221225506 is 0xC0000022, and the Windows semantic is usually STATUS_ACCESS_DENIED. However, I checked the Application/CodeIntegrity/Defender logs and found no record of backend or codex-acp.exe being explicitly blocked by the system; this issue has not been consistently reproducible yet.
- There are currently 11 orphaned codex-acp.exe processes on this machine, with their parent processes no longer existing. This indicates that NeverWrite did not properly terminate the Codex child processes when it exited. This will increase resource usage, but it may not be the initial cause of the crash.
It is suggested that low-risk verification be conducted first in the next step.
- Exit NeverWrite.
- Terminate the orphaned Codex process: Stop-Process -Name codex-acp -Force
- Back up and remove the sessions folder at C:\dev\myproject\lianaichat.neverwrite\sessions, or just remove the three extremely large session directories.
- Restart NeverWrite and start a new Codex conversation to see if it still crashes.
If it doesn't crash under such circumstances, it can be basically confirmed that the main cause is the expansion of historical transcripts. The real fix point in the future should be the historical preservation logic of NeverWrite: perform deduplication/compression on messages with the same ID, or rewrite the compact file when the append-type transcript reaches the threshold.
I asked Codex, and he summarized the issues.
So far, the most likely main cause of the "crash" is not the Codex itself, but the abnormal expansion of chat history persistence in NeverWrite.
Key evidence:
There are also two independent questions:
It is suggested that low-risk verification be conducted first in the next step.
If it doesn't crash under such circumstances, it can be basically confirmed that the main cause is the expansion of historical transcripts. The real fix point in the future should be the historical preservation logic of NeverWrite: perform deduplication/compression on messages with the same ID, or rewrite the compact file when the append-type transcript reaches the threshold.
I asked Codex, and he summarized the issues.