codex - 💡(How to fix) Fix Long Codex Desktop conversations make Browser Use screenshots slow and stale

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

26.506.31421 (2620)

What subscription do you have?

Pro subscription, $200/month.

What platform is your computer?

macOS 26.4.1, Darwin 25.4.0, arm64

What issue are you seeing?

In long Codex Desktop conversations, the app becomes progressively slower as the thread grows. This is especially noticeable in workflows that use Browser Use, screenshots, and scripts.

After a conversation has been running for a long time, tool/browser/screenshot interactions can take a very long time to load or process. Screenshot handling also appears to lag behind the current browser/app state: when Codex takes a screenshot, it can show a screenshot from a few steps earlier rather than the current screen.

Once this happens, the agent can get stuck for minutes thinking about or processing the stale/previous screenshot. The practical workaround is to manually send a fresh screenshot so the run can continue with the current state instead of remaining stuck on the old screenshot.

This feels like a combination of long-thread performance degradation and stale browser/screenshot state propagation, rather than normal model latency.

What steps can reproduce the bug?

1. Start a Codex Desktop conversation and keep it going for a long time.
2. Use Browser Use / browser inspection repeatedly during the same long thread.
3. Include screenshot-heavy work, for example UI debugging, web app inspection, browser interactions, or scripts that require visual verification.
4. Continue the conversation until the thread contains a lot of prior messages, tool outputs, screenshots, and script output.
5. Ask Codex to inspect the current browser/page state or take a screenshot.
6. Observe that loading/processing takes much longer than earlier in the thread.
7. In some cases, the screenshot Codex receives/uses appears to be from a few steps back rather than the current screen.
8. Codex may then spend minutes thinking about or processing that stale screenshot until the user manually sends a fresh screenshot.

What is the expected behavior?

Long conversations should remain usable for browser/screenshot workflows.

Browser screenshots should represent the current browser/page state, not a prior state from several steps earlier.

If screenshot capture or browser state refresh is delayed, Codex should either wait for a fresh capture, fail fast with a clear error, or expose that the screenshot is stale. It should not silently continue using old visual state and get stuck processing it for minutes.

Additional information

Related issues found before filing:

• #20805: image-heavy chats repeatedly reconnect and become very slow
• #18333: Codex Desktop repeatedly starts full MCP stacks for new sessions/subagents, causing severe slowdown and memory pressure
• #18693: desktop performance collapses in profiles with a few very large local conversation histories
• #21299: Codex app is laggy and unresponsive with long chat threads on Windows 11
• #11984: App UI gets extremely slow and laggy during long sessions

Those look related to long-thread / image-heavy / MCP/browser performance, but this report is specifically about Browser Use screenshot latency and stale screenshots from previous steps being used in the active run.