[Windows][Plus][multi-account] Weekly quota/reset window switches after logging out and signing into another account

What version of the Codex App are you using?

Codex Desktop on Windows. The affected rollout reports:

• originator: Codex Desktop
• bundled/client cli_version: 0.153.4
• source: vscode in session metadata (the user did not use VS Code; this appears to be an internal source label)

The exact Desktop UI build number was not captured.

What subscription do you have?

Two separate ChatGPT Plus accounts (Account A and Account B).

What platform is your computer?

Windows x64. Exact Windows build not captured in the sanitized evidence.

What issue are you seeing?

Codex Desktop appears to switch between inconsistent weekly quota contexts after the user logs out of one ChatGPT Plus account and signs into another.

The user alternates between two Plus accounts when the active account's 5-hour Codex allowance is exhausted. The normal switch workflow is:

1. Use Account A until its 5-hour limit is exhausted.
2. Log out of the Desktop app.
3. Fully exit the Desktop app.
4. Reopen it and wait for the sign-in prompt.
5. Open a different Chrome profile that is already signed into Account B.
6. Complete ChatGPT OAuth/sign-in for Account B.
7. Continue using Codex Desktop.

The two accounts show different weekly reset times in the ChatGPT usage UI.

A local Codex rollout captured an especially suspicious transition inside one thread. The weekly (secondary, 10080-minute) rate-limit metadata changed from one reset window to another within 36 seconds:

2026-09-10 00:55:44 +08:00
secondary.used_percent = 16.0
secondary.window_minutes = 10080
secondary.resets_at = 1789461188
# 2026-09-15 16:33:08 +08:00

2026-09-10 00:56:20 +08:00
secondary.used_percent = 99.0
secondary.window_minutes = 10080
secondary.resets_at = 1789200744
# 2026-09-12 16:12:24 +08:00

The reset timestamp moved backward by about 3 days 21 minutes, while the reported weekly usage simultaneously changed from 16% used to 99% used.

Two minutes later:

2026-09-10 00:58:34 +08:00
secondary.used_percent = 100.0
secondary.window_minutes = 10080
secondary.resets_at = 1789200744

This surfaced in the UI as the weekly allowance suddenly reaching 0% remaining.

Token evidence around the transition

The change does not look like ordinary consumption by the request itself.

At 00:55:44, the thread's cumulative token usage was:

input_tokens = 31,733
cached_input_tokens = 17,152
output_tokens = 186
reasoning_output_tokens = 31
total_tokens = 31,919
weekly used = 16%

At 00:56:20, cumulative usage was:

input_tokens = 329,537
cached_input_tokens = 271,872
output_tokens = 1,347
reasoning_output_tokens = 270
total_tokens = 330,884
weekly used = 99%

So roughly 299k additional cumulative tokens were observed between the two rate-limit samples, while the weekly meter changed by 83 percentage points and its reset timestamp changed to a different weekly window.

The affected thread later ended at about 1.58M cumulative tokens total.

Why account context is suspected

The user has two separate Plus accounts and deliberately switches between them using a full logout / app exit / OAuth login through different Chrome profiles.

The two accounts' usage pages show different weekly reset windows. During the affected Codex thread, the server-provided secondary.resets_at changed from a reset on Sep 15 to a reset on Sep 12 at the same moment the reported weekly usage changed from 16% to 99%.

This strongly suggests a possible stale or mixed account/quota context after account switching, but this is not proven because the rollout rate_limits payload does not expose an account identifier. Another explanation could be that the backend is switching between different quota buckets while presenting both as the same weekly allowance.

Expected behavior

After a user explicitly logs out, fully exits Codex Desktop, and signs into another ChatGPT account:

• the new session should use only the newly authenticated account's quota state;
• weekly secondary usage should not silently switch to a different reset window inside one thread;
• if a thread is intentionally bound to an earlier account, Desktop should make that binding explicit and should not silently accept work under another account context;
• usage accounting should expose enough diagnostic identity to distinguish separate quota buckets/accounts without exposing sensitive account data.

Actual behavior

A single Codex Desktop thread received two incompatible weekly quota states within 36 seconds:

16% used / reset Sep 15
          ↓ 36 seconds
99% used / reset Sep 12
          ↓ ~2 minutes
100% used / reset Sep 12

The user then lost access because the weekly allowance was shown as exhausted.

Related issues

• #23706 — Usage limit incorrectly shared across different accounts
• #23190 — Codex weekly usage meter switches to inconsistent reset window
• #39096 — Remote Control turn from account B silently executes against account A usage (different workflow, but demonstrates account-bound execution identity can matter)

This report adds a Windows Codex Desktop reproduction involving two Plus accounts, explicit logout/relogin through separate Chrome profiles, and raw token_count.rate_limits evidence showing both used_percent and resets_at switching inside one thread.

Privacy / additional evidence

The raw rollout contains private project prompts/tool output and is therefore not attached publicly. I can provide additional sanitized rate-limit event windows, thread metadata, or a redacted usage timeline if maintainers need them.

No account email addresses, account IDs, OAuth tokens, cookies, API credentials, or project source code are included in this report.

Start by reproducing the logout, full exit, and relogin flow on Windows with two Plus accounts, then trace how the Desktop session handles token_count.rate_limits across the affected thread. Compare the account or session context associated with each secondary used_percent and resets_at update, using the related issues for context. Done means quota state remains tied to the authenticated account or any intentional thread binding is explicit and diagnosable.