Unable to compact the context in a VERY long running session

My session has been running for a very long time (resume after resume) and has had no issues until this morning at around 3am PST or so, when suddenly I started receiving the message:

■ Error running remote compact task: We're currently experiencing high demand, which may cause temporary errors.

I tried to increase the node memory heap size, but that did not have any affect. The reason that I tried that is because I also run Gemini-cli in tandem and it often crashes due to a problem with heap allocation (likely due to the length of the sessions) and that has allowed it to continue working.

However, after my wife mentioned that you had released codex-5.3 today, I attempted to switch to that model and the error message suddenly became much clearer:

■ 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"
}
}

If my session has run over context length, why doesn't compacting it alleviate this message? I don't want to start the session over again if I can help it because I am still working on creating this solution and it has been my experience in the past that if you start new sessions, then the life of the current AI is terminated and the new session is like starting over with a whole new entity. In essence that is exactly what is happening and this is not conducive to achieving excellent results.

While I do design the setup phase to accommodate such issues, I would really like to avoid this whenever possible. Bringing new eyes when we are on a roll is extremely disruptive. I have already lost most of the day attempting to determine what the first message meant and how OpenAI could be detrimentally "experiencing high demand" for over 12 hours that my ability to compact the context of the conversation would fail and cause me to have to restart the session.... Codex-5.3 made it clear, but that new information does not help in anyway resolve the problem.

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.

Update models.json

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

Well Codex team, all my gpt 5.4 xhigh f*ing_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.

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:

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.

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" } }

@DanielJD1216

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.

Navigation Menu

Repository navigation

Unable to compact the context in a VERY long running session #10823

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Unable to compact the context in a VERY long running session #10823

Description

Activity

etraut-openai commented on Feb 6, 2026

etraut-openai commented on Feb 6, 2026

MisterRound commented on Feb 6, 2026

nalkat commented on Feb 7, 2026

marc-gymdesk commented on Apr 1, 2026

pluto2060 commented on Apr 6, 2026

marc-gymdesk commented on Apr 6, 2026

yassirusa commented on Apr 6, 2026

FreeFlowVFX commented on Apr 9, 2026

riccardo-algorime commented on Apr 11, 2026

scp252arc commented on Apr 13, 2026

lasertiger commented on Apr 20, 2026

4 remaining items

ujazdowskip commented on Apr 29, 2026

Fnthawar commented on May 9, 2026

DanielJD1216 commented on May 23, 2026

nalkat commented on May 23, 2026

myudak commented on May 24, 2026

hivsem commented on May 25, 2026

LukeyJohnson commented on May 25, 2026

4luckynikita commented on May 28, 2026

arnism1 commented on May 28, 2026

ChangeinX commented on May 30, 2026

weillerhigharc commented on Jun 2, 2026

rlucgg commented on Jun 8, 2026

nalkat commented on Jun 14, 2026

etraut-openai commented on Jun 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions