Context Compaction Hanging

[RiddleMeThis3]

What version of the IDE extension are you using?

latest

What subscription do you have?

Pro

Which IDE are you using?

VS Code

What platform is your computer?

Darwin 25.2.0 arm64 arm

What issue are you seeing?

On 5.4, Extra High, the context window is filling up with one semi-large request. Then, whenever it goes to automatically compact, it hangs indefinitely.

What steps can reproduce the bug?

Create a chat on a relatively large codebase, make a request on a medium scale with Extra High Reasoning.

What is the expected behavior?

The context window will fill up before the request is handled, and fail to compact, simply hanging on "Automatically compacting context window"

Additional information

No response

[github-actions]

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

• Compacting is getting stuck #14342
• codex just compacts repeatedly for hours at a time before it is able to make a change #14120
• Repeated 'Error running remote compact task: timeout waiting for child process to exit' #14321
• Error running remote compact task: timeout waiting for child process to exit #14292
• Codex IDE extension fails on long-lived thread with Error running remote compact task: 413 Payload Too Large #12874

Powered by Codex Action

[geokal]

same issue

[Pimpmuckl]

This does not appear to be extension-specific. I’ve now seen it in both the app and the TUI, so I dug into it locally after hitting it a few times over the last several hours.

My hunch now is that there's two different issues at play:

1. A mid-turn auto-compaction sequencing bug
   When a tool result is appended near the compaction threshold, Codex only checked auto-compaction after successful model responses using the previous usage snapshot. If the function_call_output itself pushed the next follow-up request over the limit, that follow-up could fail with context_length_exceeded before compaction ran. That path then stopped instead of compacting and retrying, which leaves the agent looking stuck.

   I tested a local patch for this in my fork:

   • treat “tool finished, follow-up still pending” as its own compaction checkpoint
   • preflight compact before the next follow-up request if needed
   • if the server still returns context_length_exceeded, compact and resume instead of bailing out

   Commit: Pimpmuckl@e8bd465

   Then I tested this and it still happened. I think it's still a useful fix for this edge case, so I'll keep it in my fork for now. But obviously there's another problem.

2. Silent Compaction that hangs
   Even with the above patch already compiled in, I still hit the “Working...” stall again. In that later case, the thread sat there for some time, I CTRL-C'd out of it, restarted the TUI, egged it on again and nothing happened while my agent was collecting diagnostics and suddenly, about 15 minutes and then suddenly resumed with a Context compacted message and continued normally.

   That makes me think the more common issue here is a separate slow/silent compaction path, not just the post-tool context_length_exceeded bug above.

Observed example:

• Thread ID: 019cde72-5132-7a40-81e9-31dc0a19b4dd
• behavior: appeared stuck on Working...
• then, after roughly 15 minutes, it resumed on its own and started with a compaction message

So conclusion is:

• there is a rare edge case bug with mid-turn compaction
• but the main issue behind this report seems to be a different bug where compaction can hang silently for a long time and only later complete, Took a first stab at fixing this but testing locally for now

[aemotyka]

Same issue. Have only encountered this on GPT5.4, but it happens regardless of the reasoning effort.

[rahenderson]

same issue, it's basically unusable like this. linux fedora silverblue 42.xx, pro account, 5.4 various levels

[etraut-openai]

If you're seeing this, could you please use /feedback to upload your logs and session details, then post the thread ID here? That will help us investigate. Thanks!

[mhemmings]

@etraut-openai Here's one example 019cde75-630c-78d0-9302-63aa9ca632de (This chat is a bit messy, I had to stop, quit, reopen, switch models, and anything I could to get it into a responsive state)

[aemotyka]

@etraut-openai

019cde5f-c559-7440-add6-6a4513296fd6

Note that I did change models during the conversation. Maybe that has something to do with it?

Thank you!

[rahenderson]

seems like the issue either improved throughout the day or it is/was mostly confined to VScode. 2 sessions have been running more or less constantly for the last few hours 🚀