codex - 💡(How to fix) Fix [BUG] Session with `usage_limit_exceeded` becomes completely unopenable in VSCode — history is intact on disk but UI refuses to load it [1 participants]

What version of the IDE extension are you using?

openai.chatgpt 26.422.62136 (VSCode extension)

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Ubuntu Linux 6.17 (amd64)

What issue are you seeing?

When a Codex session hits the usage limit and terminates with usage_limit_exceeded, the entire conversation history becomes inaccessible from the VSCode UI. The session file exists on disk and contains all messages intact, but Codex refuses to open it — it simply doesn't appear or load in the history panel.

Expected behavior: The rate limit should only block NEW messages (API calls). Viewing past conversation history is a local read operation — the session JSONL file is stored locally and should always be readable regardless of rate limit status.

Actual behavior: The session is completely blocked. Older sessions that ended cleanly (without errors) open fine.

Steps to reproduce

1. Use Codex in VSCode on a Plus plan
2. Have a long/intense session that consumes the 5-hour rate limit window (~24.6M tokens in my case)
3. The session terminates with error: "codex_error_info": "usage_limit_exceeded" and message: "You've hit your usage limit... try again at 5:54 PM"
4. Close VSCode
5. Reopen VSCode → the session is gone from the history / cannot be opened
6. Older sessions (without errors) open fine

Evidence from disk

The session file exists and is fully intact:

~/.codex/sessions/2026/04/28/rollout-2026-04-28T12-53-55-019dd3b9-631a-7c71-ab84-087b02c7d125.jsonl
Size: 2.6 MB
Events: 1344
Messages: 108
Token usage: 24,655,646 total (24.5M input + 97K output)

The last events in the JSONL show the exact error:

{
  "type": "event_msg",
  "payload": {
    "type": "error",
    "message": "You've hit your usage limit. Upgrade to Pro (...), visit https://chatgpt.com/codex/settings/usage to purchase more credits or try again at 5:54 PM.",
    "codex_error_info": "usage_limit_exceeded"
  }
}

The ~/.codex/session_index.jsonl also contains the session entry:

{
  "id": "019dd3b9-631a-7c71-ab84-087b02c7d125",
  "thread_name": "Revisa tokens desde el domingo",
  "updated_at": "2026-04-28T10:54:11.894692851Z"
}

Why this is a distinct bug

I checked existing issues. Related but different:

• #19918 — Same 5-hour rate limit, but about the usage counter being wrong, not about session being unopenable
• #16817 — "Threads don't load after restart" but for Mac Desktop App, no rate limit involved
• #17354 — "Thread history wiped in app, present in CLI" but different root cause
• #19558 — Thread broken by compaction failure, not by rate limit error

None report: session blocked from UI specifically because it ended with usage_limit_exceeded.

Suggested fix

The session loader should distinguish between:

1. Session state (error, rate limited, etc.) — this should only block new API calls
2. Session data (messages, tool calls, outputs) — local data should always be viewable

A session that ended with usage_limit_exceeded should still be openable in read-only mode. The UI could show a banner "Rate limit reached — read-only mode" but must render the conversation history.