Activity

1. evarande

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Feb 8, 2026
2. evarande

   changed the title [-]Context compaction triggered after some tool calls in fresh session[/-] [+]Context compaction triggered after tool calls in a fresh session[/+] on Feb 8, 2026
3. etraut-openai commented on Feb 8, 2026

   

   etraut-openai

   on Feb 8, 2026

   Contributor

   More actions

   I looked at your session details (thanks for uploading!). The tool calls in question generated very large outputs (base64-encoded images) that immediately filled the remaining space in your context window. That explains why you saw a compaction.
4. etraut-openai

   closed this as not plannedon Feb 8, 2026
5. evarande commented on Feb 9, 2026

   

   evarande

   on Feb 9, 2026

   Author

   More actions

   @etraut-openai thanks for looking into this!
   Initially I also inspected tool call output and blamed large base64 blobs. However:

   1. this is a regression. I tested the same prompt in codex-cli 0.90.0 with gpt-5.2-codex xhigh using the same MCP server and it works correctly (auto compaction not triggered, codex has image in context): uploaded thread ID 019c40e7-557a-7ea0-bc91-4d5d9bc79ab3. I also tested on 0.95.0 (fails, auto compaction triggered) and 0.98.0 using gpt-5.2-codex xhigh (original session was using gpt-5.3-codex xhigh), with the same result
   2. manually increasing compaction limit to unrealistically large value in codex-cli 0.98.0 seems to fix the issue: auto compaction after those tool calls is not triggered, codex seems to have access to images in conversation history with 90% context free after multiple tools calls. To increase compaction limit I launched codex like this: codex -c model_auto_compact_token_limit=10000000. Uploaded thread ID 019c40ed-512a-75f2-a0af-9ed7121f039e

   Could you look at those sessions as well please? It looks like a bug since it works fine on the old version of codex-cli and also works fine when auto compactions are effectively disabled
6. etraut-openai

   reopened this on Feb 9, 2026
7. noahtolsen commented on Feb 10, 2026

   

   noahtolsen

   on Feb 10, 2026

   More actions

   I'm also seeing this behavior. Calling the playwright tool more often than not overwhelms the context window and causes compaction and then attempts to restart answering whatever prompt I gave it even though it had often already completed the requested work and was just calling playwright to validate changes. It seems like a bug that the playwright tool would send such large base64 encoded images to the context. The GPT 5.3 Codex context window is never going to be able to handle that.

   👍React with 👍2Reacted by Simon Hokesen and autotaker
8. etraut-openai

   added

   bugSomething isn't workingSomething isn't working

   contextIssues related to context management (including compaction)Issues related to context management (including compaction)

   on May 14, 2026
9. ryuhmanov-m commented on May 26, 2026

   

   ryuhmanov-m

   on May 26, 2026

   More actions

   Draft GitHub Comment - Codex Context Compaction Cross-Link

   Target issue: #11072

   Adding a related affected-user signal from Codex Desktop with `gpt-5.5`.
   
   I posted the fuller evidence in #21269 because my local trace shows both sides of the same problem:
   
   - `view_image(detail="high")` outputs are persisted as inline `input_image` payloads with `data:image/png;base64,...`
   - in one affected session there were `51` `data:image/png;base64` occurrences
   - the largest image tool outputs serialized to about `1.8M`, `1.34M`, `978k`, and `971k` chars
   - compaction then retained old inline images plus startup/context packets in `replacement_history`
   - the user-visible result was multiple automatic compactions during a short screenshot/artifact workflow, not a long intentional 250k-token conversation
   
   Full comment with counters: https://github.com/openai/codex/issues/21269#issuecomment-4539198193
   
   This issue remains important because screenshot/browser/frontend validation is a normal Codex Desktop workflow, and huge base64 image payloads make the agent hit compaction far earlier than the user would reasonably expect.