›_ Codex Issues
Codex Issues / #30567

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

Open 💬 2 comments Opened Jun 29, 2026 by ITGianter
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #29437

Powered by Codex Action

Adkid-Zephyr · 8 days ago

Adding a current macOS reproduction with persisted-token evidence.

Environment

  • ChatGPT/Codex Desktop: 26.814.41407
  • Bundled Codex runtime reported by the feedback client: 0.148.0-alpha.15
  • macOS: 26.6.1 (arm64)
  • Show context window usage: enabled
  • Feedback ID: 01a019d9-24c6-7f30-8784-44cd28c9f660

Reproduction

  1. Use a local Codex thread until it has non-trivial context usage.
  2. Restart/reopen the desktop app.
  3. Open the historical thread.
  4. The composer context donut is absent.
  5. Run /status: it shows the thread ID and 7-day limit, but omits context usage.
  6. A currently active local thread displays the donut correctly.

Persisted evidence

The affected thread's rollout still contains a valid latest token_count:

{
  "last_token_usage": {
    "total_tokens": 229723
  },
  "model_context_window": 828400
}

So the context state is persisted and non-zero; the restored desktop surface is not displaying it. This matches the original report's hypothesis that the resume path fails to hydrate or replay the latest token-usage state until a fresh turn emits new metadata.

Implementation-level observation

Current main contains codex-rs/app-server/src/request_processors/token_usage_replay.rs and resume coverage for thread/tokenUsage/updated. The installed behavior may therefore be either:

  • a desktop release/runtime gap,
  • an uncovered hot or metadata-only resume path, or
  • the desktop frontend receiving but not applying the replayed notification.

I cannot distinguish delivery from frontend hydration from the persisted rollout alone, but the attached Feedback ID includes the affected thread logs and doctor diagnostics.