Codex App shows 0% context usage after reopening historical threads until a new message or fork

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

26.623.61825

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

<img width="1554" height="432" alt="Image" src="https://github.com/user-attachments/assets/d2487637-5aa1-4ac6-934c-f6b09893aa71" />

After restarting/reopening the Codex desktop app, historical threads are restored correctly, but the context usage indicator in the lower-right composer area shows an empty circle / 0%.

The same stale/zero context usage is also reflected when using /status. It does not automatically refresh after the historical thread is opened.

However, the context usage becomes correct again after either:

1. sending a new message in that historical thread, or
2. forking the thread into a new conversation.

What steps can reproduce the bug?

1. Open Codex desktop app.
2. Open an existing historical thread that already has non-zero context usage.
3. Observe the context usage circle in the lower-right composer area.
4. It shows empty / 0%.
5. Run /status; context usage is not refreshed either.
6. Send a new message, or fork the thread.
7. The context usage indicator starts showing the correct usage.

What is the expected behavior?

When opening an existing historical thread after restarting the Codex desktop app, the context usage indicator and /status should be initialized from the thread's existing token/context metadata and show the current usage instead of 0%.

Additional information

Actual behavior

The restored historical thread initially shows 0% context usage. It only updates after a new turn starts or after forking.

Notes / local observations

This does not appear to mean the thread actually has zero context usage.

On my machine, the local Codex state already contains non-zero token usage for the restored thread, and the rollout JSONL contains prior token_count events with total_token_usage and model_context_window.

So this looks like the desktop app resume path restores the transcript/thread, but does not hydrate or replay the latest token_count state into the context usage UI and /status state until a new turn/fork causes fresh metadata to be emitted.

Screenshots

Attached screenshot shows the lower-right context usage circle displaying empty / 0% after reopening a historical thread.