Context compaction triggered after tool calls in a fresh session

Open 💬 4 comments Opened Feb 8, 2026 by evarande

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

260206.1448 (565)

What subscription do you have?

Pro

What issue are you seeing?

After some tool calls like playwright MCP browser_take_screenshot tool, figma MCP get_screenshot tool, figma MCP get_design_context tool and some other tools from figma or playwright MCPs context compaction is triggered even in fresh sessions with 98% context left

Uploaded thread ID: 019c3c28-e230-72a2-99b7-3438b4f66054

What steps can reproduce the bug?

To reproduce use prompt like

use figma mcp to analyze this figma design:
<link to figma frame here>
and tell me what you see here

The result will be:

Called figma.get_screenshot
Called figma.get_metadata
Context compacted

What is the expected behavior?

Context should not be auto compacted unless compaction threshold is exceeded

Additional information

This is reproducible both in app and in cli. Initially I though that images returned by tools might be too large, but it doesn't seem to be the case: in Codex app I can copy get_screenshot tool image output, if I send it as a regular image it does not trigger auto compaction

View original on GitHub ↗

4 Comments

etraut-openai contributor · 6 months ago

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.

evarande · 6 months ago

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

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

noahtolsen · 6 months ago

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.

ryuhmanov-m · 3 months ago

Draft GitHub Comment - Codex Context Compaction Cross-Link

Target issue: https://github.com/openai/codex/issues/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.