›_ Codex Issues
Codex Issues / #24931

re-authing in pane1 causes infinite loop when pane2 tries to remotely compact

Resolved 💬 2 comments Opened May 28, 2026 by relh Closed Jun 29, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.133.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.5

What platform is your computer?

Linux 6.8.0-41-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

tmux

Codex doctor report

What issue are you seeing?

While re-authing on a machine with a codex device token, I had an ongoing chat. At some point the ongoing chat said my access token had expired (sensibly because I had re-logged in again). However this happened as it was trying to remotely compact my conversation. It spun overnight, attempting over and over again to recompact the conversation. It ballooned the codex chat log into 350Gb+ and charged me ~50% of my weekly usage. I would like this addressed and my usage returned to me ideally.

What steps can reproduce the bug?

1) login to an account in pane 1
2) do some work in pane 1
3) get to a point where pane 1 might be about to compact
4) in pane 2 logout and login again
5) pane 1 will fail remote compaction
6) pane 1 will now proceed to fail over and over again creating a 350Gb codex log that bricks the computer and consumes ~50% of weekly usage over 15 hours or so.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

selaquik · 3 months ago

I’ve already been without Codex for a week. I’ve lost a lot because of this. It just dies during context compression and can’t compress the context anymore.

etraut-openai contributor · 1 month ago

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.