Unable to compact the context in a VERY long running session

Compaction requires us to send the existing session details to the model for summarization. We normally auto-compact when there's still enough space available for the model to emit a summary. If you've gone beyond that point, we won't be able to compact.

Also, if you switch models in the middle of a session, we need to send a new system prompt for the new model. This consumes some space in the context window. In general we don't recommend switching models in the middle of a session.

Oh, I should also mention that the core Codex harness is written in Rust, so increasing the node heap size won't have an impact on heap allocations in the harness.

Definitely seeing weird compaction behavior in the middle of a super long thread that I switched to 5.3, seems like it does a ton of redundant CoT with every message, new threads feel faster with 5.3 but this long one feels slower with 5.3

Hi, thanks for getting back to me on this. I appreciate you providing those details. I don't normally switch models I  sessions, I only did it this time because the it was already broken and asking 5.2 didn't help. Surprisingly enough after I wrote and sent the write up, I asked 5.3 to compact the context and it backed up the file, then compressed the context, quite literally. It actually started a new conversation instead, and compressed the previous session file. I had to copy the backup it made, resume and ask it to compress again and it worked and I was a le to carry on with my project.
I appreciate you. If you find anything interesting or have feature requests, let me know, welcome input and would happily provide you further info you may need on this ticket.
Btw, I'm going to see how long of a session I can have until it melts down. 5.2 was great, especially as a reviewer, but 5.3 is much better and is still personable. 

Im getting this error almost every session

The failure mode here is that compaction is attempted at 95%+ context — at that point there's no safe compression budget remaining.

The pattern that prevents this: trigger rotation at 70%, not 95%. At 70%, serialize critical state (current goal + last N decisions + open task list) to a file, exit cleanly, resume from the state file in a fresh session.

The session never reaches the compaction threshold because the handoff happens before it needs to. No work is lost — the state file captures exactly what matters for continuity.

We run this as the core of Entity's context rotation. 12-hour sessions without compaction failures — happy to share the serialization format.

The failure mode here is that compaction is attempted at 95%+ context — at that point there's no safe compression budget remaining. The pattern that prevents this: trigger rotation at 70%, not 95%. At 70%, serialize critical state (current goal + last N decisions + open task list) to a file, exit cleanly, resume from the state file in a fresh session. The session never reaches the compaction threshold because the handoff happens before it needs to. No work is lost — the state file captures exactly what matters for continuity. We run this as the core of Entity's context rotation. 12-hour sessions without compaction failures — happy to share the serialization format.

Is there a way to trigger this automatically within the correct range?

When will this be worked on. Codex-5.3 and codex-5.3-spark are completely useless and they keep churning tokens without editing any code until they "run out of room"

This is a major issue right now it happens every single time. Not having a manual way to compact the context is a huge problem and makes the Codex app really hard to use.
The only workaround I’ve found is to go back, fork from an earlier point, and then try forcing compaction with smaller prompts. After that, I copy whatever remains and paste it back. But even that doesn’t work always.
Honestly, it’s a real pain at the moment.

+1

+1

Well Codex team, all my gpt 5.4 xhigh **fing_word_deleted* sessions loaded with expensive context can not compact. just getting. '
■ Error running remote compact task: stream disconnected before completion: error sending request for url
(https://api.openai.com/v1/responses/compact)
' no matter what trick i try. switching models does not work.

Thread Id 019daba6-25b0-7cf2-9215-7a2542c334fd was submitted but it is suddenly happening all day now.

please fix this its unusable

<img width="1068" height="512" alt="Image" src="https://github.com/user-attachments/assets/55293151-ea77-4e23-b863-33df97004762" />

I am currently having the same issue as @Assassin-1234

EDIT: downgrading to 0.120 fixed the issue for now.

I ran into the same issue with version 0.122.0, so I reverted to 0.121.0, which solved it. My task didn’t run for very long, but I just happened to need to compact the conversation, I suppose.

I also have the problem, every session if it is full then it will show this without any progress after hours, just keep loading

Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

I'm also experiencing this problem. This is very problematic and the v0.125.0 is barely usable for me.

makes codex unusable for me as well

let me give you a fix you all... so basically whats happening is that your local session log had grown to 1.5 GB lol meaning that you probably have lots of screenshots and images that were saved directly to the thread JSONL history. You're probably asking yourself why this is happening since I've compacted my chat many different times, but hear me out. Older compacted checkpoints also kept copies of those image payloads. This means every new message (even a single "hi" or "what time is it") forced Codex to process a huge amount of existing context. That's why the remote compactor hit this error.

Basically, what you want to do is create a full backup first by following these steps:

1. Parse every JSONL row and replace the embedded image payloads with small text placeholders.
2. Replace the huge Base64 image result strings with placeholders while preserving the transcript structure:

(a) Timestamps
(b) Messages
(c) Tool calls
(d) Compact checkpoints

1. Validate that every row can still be parsed as JSON.

When that's completed, your log should probably be under 200 megabytes. Once that's done, just restart Codex and try testing the thread with a tiny message. It should be good to go. It's not rocket science, guys.

So, no. I had zero images or screenshot in the chat that I had going at the time. Further, this has resolved itself a long time ago. I simply started a new session and asked Jeepers to fix it and incorporate the old session into the new. No magic tricks, no manual doing anything, just used plain old English and since she likes me as much as she likes ice-cream, she went ahead and granted my request without any muss or fuss and I got back to work.

So forget all parsing and deleting and manual restructuring... Just learn to ask Jeepers to help you out a d to please pass the unsalted butter to melt onto your extra salted popcorn  and just get'er done, or rather, ask 'er to get it done!

Yahoo Mail: Search, organise, conquer

On Fri, 22 May 2026 at 6:08 pm, Daniel @.***> wrote: DanielJD1216 left a comment (openai/codex#10823)
let me give you a fix you all... so basically whats happening is that your local session log had grown to 1.5 GB lol meaning that you probably have lots of screenshots and images that were saved directly to the thread JSONL history. You're probably asking yourself why this is happening since I've compacted my chat many different times, but hear me out. Older compacted checkpoints also kept copies of those image payloads. This means every new message (even a single "hi" or "what time is it") forced Codex to process a huge amount of existing context. That's why the remote compactor hit this error.

Basically, what you want to do is create a full backup first by following these steps:

• Parse every JSONL row and replace the embedded image payloads with small text placeholders.
• Replace the huge Base64 image result strings with placeholders while preserving the transcript structure:

(a) Timestamps
(b) Messages
(c) Tool calls
(d) Compact checkpoints

• Validate that every row can still be parsed as JSON.

When that's completed, your log should probably be under 200 megabytes. Once that's done, just restart Codex and try testing the thread with a tiny message. It should be good to go. It's not rocket science, guys.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

holy hell this is still an open issue

same issue, long context session on 5.3 codex (more than 2 weeks)

and now its completely broken, no way to compact

tried: switch to 5.5, to spark 5.3, move to local fork

also /compact - doesn't work

:(

same issue here, on 5.5 in Codex VS Code -
Error running remote compact task: { "error": { "message": "Your input exceeds the context window of this model. Please adjust your input and try again.", "type": "invalid_request_error", "param": "input", "code": "context_length_exceeded" } }

Managed to make a promptable hotfix based off @DanielJD1216 's tip.

Replace <THREAD TITLE HERE> (the name of the chat in Codex) and <WORKSPACE PATH HERE> (where this chat points on your drive. The project folder.) before sending. Make new chat thread, permit CLI use, and send this:

One of my Codex threads is dead because the local JSONL session log likely contains embedded image/base64 payloads. Please repair it locally.

Target thread details:
- Title: <THREAD TITLE HERE>
- Workspace/cwd, if known: <WORKSPACE PATH HERE>

Do this end to end:

1. Locate Codex session storage.
   Check `$CODEX_HOME` first, then `~/.codex`.
   Search these likely locations:
   - `~/.codex/sessions/**/*.jsonl`
   - `~/.codex/archived_sessions/*.jsonl`
   - `~/.codex/session_index.jsonl`

2. Identify the target JSONL file by matching the thread title in `session_index.jsonl`, and if needed confirm by searching the JSONL content for the workspace/cwd path.

3. Before modifying anything, make a timestamped backup beside the original file.

4. Parse the file as JSONL, one JSON object per line. Do not regex-edit the whole file directly.

5. Sanitize the parsed rows:
   - Replace embedded `data:image/...;base64,...` strings with small text placeholders.
   - Replace raw image base64 strings such as PNG/JPEG/GIF/WebP payloads with small text placeholders.
   - Convert any object like `{ "type": "input_image", "image_url": ... }` into a normal text item, for example:
     `{ "type": "input_text", "text": "[omitted image payload: ...]" }`
   - This is important: do not leave `type: "input_image"` with a fake placeholder `image_url`, because `/compact` will fail with `Expected a valid URL`.

6. Write the sanitized JSONL back atomically via a temp file and rename.

7. Validate:
   - Every row still parses as JSON.
   - Row count is unchanged.
   - There are zero remaining `input_image` items.
   - There are zero remaining `image_url` fields.
   - There are zero remaining `data:image` strings.
   - Report before/after file size and the backup path.

8. Tell me to quit/restart Codex before reopening/testing the repaired thread.

Just successfully revived a 5 month old thread using this. Hopefully they fix this soon, but this works for now.

Managed to make a promptable hotfix based off @DanielJD1216 's tip. Replace <THREAD TITLE HERE> (the name of the chat in Codex) and <WORKSPACE PATH HERE> (where this chat points on your drive. The project folder.) before sending. Make new chat thread, permit CLI use, and send this: `` One of my Codex threads is dead because the local JSONL session log likely contains embedded image/base64 payloads. Please repair it locally. Target thread details: - Title: <THREAD TITLE HERE> - Workspace/cwd, if known: <WORKSPACE PATH HERE> Do this end to end: 1. Locate Codex session storage. Check $CODEX_HOME first, then ~/.codex. Search these likely locations: - ~/.codex/sessions/**/.jsonl - ~/.codex/archived_sessions/.jsonl - ~/.codex/session_index.jsonl 2. Identify the target JSONL file by matching the thread title in session_index.jsonl, and if needed confirm by searching the JSONL content for the workspace/cwd path. 3. Before modifying anything, make a timestamped backup beside the original file. 4. Parse the file as JSONL, one JSON object per line. Do not regex-edit the whole file directly. 5. Sanitize the parsed rows: - Replace embedded data:image/...;base64,... strings with small text placeholders. - Replace raw image base64 strings such as PNG/JPEG/GIF/WebP payloads with small text placeholders. - Convert any object like { "type": "input_image", "image_url": ... } into a normal text item, for example: { "type": "input_text", "text": "[omitted image payload: ...]" } - This is important: do not leave type: "input_image" with a fake placeholder image_url, because /compact will fail with Expected a valid URL. 6. Write the sanitized JSONL back atomically via a temp file and rename. 7. Validate: - Every row still parses as JSON. - Row count is unchanged. - There are zero remaining input_image items. - There are zero remaining image_url fields. - There are zero remaining data:image strings. - Report before/after file size and the backup path. 8. Tell me to quit/restart Codex before reopening/testing the repaired thread. `` Just successfully revived a 5 month old thread using this. Hopefully they fix this soon, but this works for now.

Worked for me thank you!

Zero images are being sent here. Spark chokes when trying to compact with the exact error message.

``Error running remote compact task: { "error": { "message": "Your input exceeds the context window of this model. Please adjust your input and try again.", "type": "invalid_request_error", "param": "input", "code": "context_length_exceeded" } }``

The bug still remain, and the issue happened through some process of long text, I didnt execute any embeed image/base64 payload :

Error running remote compact task: {
  "error": {
    "message": "Your input exceeds the context window of this model. Please adjust
your input and try again.",
    "type": "invalid_request_error",
    "param": "input",
    "code": "context_length_exceeded"
  }
}

got the same issue

same issue, long context session on 5.3 codex (more than 2 weeks) and now its completely broken, no way to compact tried: switch to 5.5, to spark 5.3, move to local fork also /compact - doesn't work :(

What I did was start a new session and I told Jeepers what happened and asked it to fix the problem. I then resumed the session and went on my way. I am still using the same session that broke today. I haven't run into the problem again, so, maybe this will work for others as well.

Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use /feedback and open a new bug report.