[Codex App] Existing task becomes systemError and cannot resume after usage-limit response

What issue are you seeing?

An existing Codex App task became systemError and every attempt to resume it failed immediately with a usage-limit error, even though the user's usage dashboard indicated that the applicable limit had not been exhausted.

Affected task/session ID:

019fcaf0-dcb4-7651-9b4a-e9718cf82cf7

The task runs locally through a remote SSH host. Repository names, source code, and task contents are intentionally omitted from this public report.

Observed timeline

Timezone: JST (UTC+09:00), 2026-08-08.

Four follow-up attempts failed in about 1.4–1.6 seconds:

• 13:12:43
• 13:13:30
• 13:16:03
• 13:17:32

Each failed with:

You've hit your usage limit. Visit https://chatgpt.com/codex/settings/usage to purchase more credits or try again at 1:21 PM.

The thread status was then exposed as:

{"type":"systemError"}

In the UI, the user could not resume the task and was told it was blocked by the usage limit.

At 13:22 JST, after the retry time shown in the error, the same existing task accepted a background follow-up. At 13:23 it was active again and continued from its retained history. No task fork, repository fork, or worktree was needed.

Steps to reproduce

1. Run a long Codex App task.
2. While the usage dashboard still shows applicable capacity remaining, send a follow-up near a usage-window boundary.
3. Observe the follow-up fail immediately with the usage-limit message.
4. Retry the existing task several times before the displayed retry time.
5. Observe that the thread is classified as systemError and cannot be resumed.
6. Retry after the displayed time; the same thread may become active again.

This may be related to existing reports of usage-limit responses despite visible remaining quota, but this report specifically covers recovery of an existing Codex App task and its transition to systemError.

Expected behavior

• If capacity is actually available, the follow-up should run.
• If a temporary usage window is exhausted, the task should remain in a clearly recoverable waiting/limited state rather than systemError.
• The UI should preserve a one-click retry path for the existing task after the shown reset time.
• Usage-limit state should agree with the usage dashboard.
• Failed retry attempts should not make an otherwise intact task appear permanently broken.

Recovery observed

Wait until the exact retry time shown in the error, then send a follow-up to the same task. In this case, the original task recovered with its completed history intact.

Additional information

The user can provide an in-product feedback upload privately if maintainers need the full session. No private repository contents are included here.