codex - 💡(How to fix) Fix [Bug] ChatGPT Plus integration/DesktopApp/IDE loses chat history and triggers false rate limits due to unresolved Cloudflare CAPTCHAs [6 comments, 3 participants]

Title: [Bug] ChatGPT Plus integration loses chat history and triggers false rate limits due to unresolved Cloudflare CAPTCHAs

Description: When using the ChatGPT Plus integration (where API keys are not required and the app uses web session tokens), the application experiences severe degraded performance after extended use. It silently drops weeks' worth of chat history from active windows and returns false "Rate Limit / Usage Limit" warnings.

This appears to be caused by expiring Cloudflare cf_clearance cookies resulting in background compaction failures, which triggers a cascading failure loop within the local context manager.

Environment:

• OS: Windows / macOS / Linux
• Platform: Desktop App & VS-Code Extension
• Configuration: ChatGPT Plus Plan (Web Session Auth / auth_mode: "chatgpt")

Steps to Reproduce:

1. Log in via the ChatGPT Plus web auth portal in the app.
2. Maintain an active session for several days until the underlying Cloudflare cf_clearance cookie expires naturally or via a Cloudflare security update.
3. Attempt to use the app in an active chat window with severe/large context.
4. Note that the application returns "Usage Limit" errors and retroactively drops older messages from the history context.

Expected Behavior:

The background compaction task should successfully summarize the history context or securely prompt the user to re-authenticate / solve a CAPTCHA if their headless web session tokens can no longer bypass the Cloudflare shield.

Actual Behavior:

Background tasks fail silently. The app consumes massive Cloudflare HTML CAPTCHA payloads as if they were valid JSON strings, logs these failures perpetually, and drops chat history because it enters a failed compaction loop to stay within local token limits.

Root Cause Analysis:

1. Cloudflare Clearance Expiration: When logging in normally, the app retrieves a session cookie and a cf_clearance token to bypass ChatGPT's web firewalls. When this clearance token expires naturally over time or due to a Cloudflare security update, background requests to ChatGPT's web endpoints are intercepted and rejected.
2. The Compaction Loop & Lost History: When an active chat context becomes too large, the app runs a background "compact task" to summarize older history. Because Cloudflare intercepts this specific background task, the app receives a massive (~36,000+ character) Captcha HTML block (<noscript>Enable JavaScript and cookies...</noscript>) instead of the expected JSON.
3. Forced History Truncation: Because the compaction fundamentally fails, the app has no alternative way to compress the active context window. To prevent a hard crash on the next user prompt due to token overflows, it forcefully drops the older message history (resulting in weeks of lost text).
4. False "Rate Limits": Simultaneously, the app attempts to parse or retry these giant Cloudflare Captcha HTML payloads, continuously inflating local token constraints and repeatedly triggering false "rate limit / high usage" UI warnings.

Diagnostic Citations & Discovery:

This root cause was discovered and validated by inspecting the local configuration and state databases within the ~/.codex configuration directory on the affected machine.

1. Authentication Mode & Stale Session State File: ~/.codex/auth.json The configuration confirms the app is relying on ChatGPT web session tokens rather than an API key. Notably, the last_refresh timestamp was confirmed to be nearly a week old (approaching the exact timeframe of Cloudflare clearance expiration):

"auth_mode": "chatgpt",
"OPENAI_API_KEY": null,
"last_refresh": "2026-04-08T11:16:12.287934500Z"

2. Background Compaction Task Failures File: ~/.codex/logs_2.sqlite (table: logs) The logs database captures the initial front-end failure string that cascades into the history drop. The exact error thrown internally prior to history truncation is:

Error running remote compact task: You've hit your usage limit. > Re-try

3. Direct Cloudflare Interception Payloads File: ~/.codex/logs_2.sqlite (table: logs) Querying the feedback_log_body column immediately surrounding the compaction failures reveals massive 30kb+ Cloudflare defensive payloads polluting the telemetry strings, targeting specific ChatGPT endpoints. Target trace example: /backend-api/plugins/list and /backend-api/codex/analytics-events/events.

Instead of JSON, the internal daemon receives and attempts to process this explicit CAPTCHA block from Cloudflare:

<noscript><div class="h2"><span id="challenge-error-text">Enable JavaScript and cookies to continue</span></div></noscript>
<!-- Followed by roughly 35,000 characters of Cloudflare challenge JS/SVG data -->

Suggested Workaround for Users:

Until developers can implement a better fallback prompt for expired Cloudflare tokens, circumvent this issue by manually forcing a clearance refresh:

1. Force a Session Refresh: Completely Log Out of your Plus account within the app's settings and Log back in. This forces the app's internal webview for ChatGPT to open, allowing you to manually solve newly-required Cloudflare Captchas. This will immediately grant a fresh cf_clearance cookie for headless tasks.
2. Clear Corrupted Local State: While the app is fully closed, safely delete or rename your local log databases (e.g., logs_2.sqlite) to flush out the corrupted error loops caused by the giant HTML payloads.

Proposed Code Fixes:

• Better API Exception Handling: The compaction service needs to properly validate JSON responses. If the background web request returns text/html containing a Cloudflare challenge, it should halt the operation instead of trying to parse, loop, or consume the payload.
• Proactive Re-auth Prompts: If a standard background task hits a Cloudflare HTTP 403 / Challenge, pop open a webview immediately to prompt the user to solve the CAPTCHA, preventing silent history truncation.