[Windows] Switching to a large thread with an in-app Browser reattaches the WebView, shows a Chromium profile error, and repeatedly reloads history

Summary

On Codex Desktop for Windows, switching from another active task to a large,
Browser-enabled thread caused three events in the same time window:

1. the in-app Browser WebView was torn down and reattached;
2. Chromium displayed a native profile warning asking the user to sign out and

sign in again;

1. the app repeatedly issued thread/turns/list calls taking about 4–5 seconds

each.

The Codex account remained healthy during the warning. account/read and
getAuthStatus succeeded with no authentication error.

The strongest measured correlation is thread-history size rather than the raw
number of open tabs. In the same app process and log, 613–660 MiB threads took
4.3–4.9 seconds on average per thread/turns/list, while 5–24 MiB threads took
about 0.10–0.47 seconds.

Environment

• Codex Desktop: 26.721.4979.0
• OS: Windows x64
• Distribution: Microsoft Store / MSIX
• Local time zone: JST (UTC+09:00)
• Subscription tier: not verified in this diagnostic
• In-app Browser: open on a local generated HTML artifact

User-visible error

At 2026-07-28 17:55:21 JST (08:55:21 UTC), Chromium displayed:

Profile error occurred

There was a problem opening your profile.
Please sign out and then sign in again.

The actual dialog was localized in Japanese. The text was also found in the
Chromium ja.pak bundled with the installed Codex package.

This appears to be a Chromium browser-profile warning, not a Codex account
authentication error.

Steps to reproduce

1. Keep multiple Codex tasks available.
2. Use one long-running task with an in-app Browser tab.
3. Let that task accumulate large tool outputs, generated images, and repeated

compactions. In this reproduction its rollout JSONL was about 613 MiB.

1. Work in another task.
2. Switch back to the large Browser-enabled task.
3. Observe the app pause while the browser view is rebound and thread history

is fetched.

1. In this reproduction, Chromium also showed the profile warning above.

The profile dialog is intermittent. The slow history loading is consistently
visible for the largest threads in the captured log.

Exact timeline

Sanitized Codex Desktop log excerpt:

08:55:10.083Z previous thread active=false
08:55:10.109Z large target thread active=true, resumeState=needs_resume
08:55:10.112Z IAB_LIFECYCLE received browser sidebar owner sync
08:55:10.369Z IAB_LIFECYCLE renderer created browser sidebar webview
08:55:10.947Z IAB_LIFECYCLE reattaching existing browser sidebar webview
08:55:10.989Z IAB_LIFECYCLE previous browser sidebar guest torn down
08:55:11.017Z IAB_LIFECYCLE did attach browser sidebar webview
08:55:18.190Z app/list durationMs=7258 errorCode=null
08:55:21.000Z user screenshot of the native Chromium profile warning
08:55:24.993Z thread/resume durationMs=4507 errorCode=null
08:55:30.319Z thread/turns/list durationMs=4702 errorCode=null
08:55:34.860Z thread/turns/list durationMs=4489 errorCode=null
08:55:39.190Z thread/turns/list durationMs=4275 errorCode=null
...

From 08:55:00Z through 08:57:59Z:

• thread/turns/list calls: 21
• minimum: 4,186 ms
• median: 4,343 ms
• mean: 4,435.7 ms
• maximum: 5,012 ms
• IAB lifecycle log lines: 19
• authentication read/status errors: 0

Same-process size/latency comparison

The following values came from the same Codex Desktop process and log:

| Rollout size | Calls | Mean | Min | Max |
|---:|---:|---:|---:|---:|
| 660.1 MiB | 107 | 4,840.8 ms | 4,368 ms | 6,248 ms |
| 624.0 MiB | 138 | 4,922.6 ms | 4,242 ms | 8,110 ms |
| 613.4 MiB | 78 | 4,309.3 ms | 3,249 ms | 6,441 ms |
| 24.3 MiB | 12 | 264.8 ms | 224 ms | 319 ms |
| 20.6 MiB | 21 | 250.9 ms | 199 ms | 426 ms |
| 5.3 MiB | 22 | 97.5 ms | 68 ms | 232 ms |

This is correlation evidence, not a controlled proof of causation, but the
separation is large and repeatable within one process.

What made the affected rollout large

The 613.4 MiB JSONL was streamed and aggregated by record type without
exporting message contents:

| Record type | Count | Total size |
|---|---:|---:|
| response_item/function_call_output | 2,209 | 301.7 MiB |
| event_msg/image_generation_end | 42 | 114.3 MiB |
| compacted | 27 | 86.8 MiB |
| response_item/custom_tool_call_output | 1,050 | 62.1 MiB |
| event_msg/mcp_tool_call_end | 342 | 14.1 MiB |

Additional facts:

• JSONL lines: 18,427
• malformed JSON lines: 0
• largest single line: 15.7 MiB
• largest line type: response_item/function_call_output

Session inventory

At the time of the follow-up diagnostic:

• hot ~/.codex/sessions JSONL files: 1,286
• hot session total: 20.14 GiB
• session_index.jsonl: 116 lines
• archived session JSONL files: 78 / 0.39 GiB
• largest rollout: 660.1 MiB
• rollouts over 600 MiB: 3

This is consistent with reports that the Desktop hot path can become much
larger than the UI-visible session index. I have not proven that all 1,286
files were scanned during this exact switch.

Expected behavior

• Switching threads should load metadata plus a bounded recent tail rather

than repeatedly fetching an unbounded history.

• Large tool outputs and generated-image payloads should be stored by

reference, capped, summarized, or lazy-loaded.

• Repeated compaction should reduce the hot state rather than leave tens of

MiB of compacted records on the UI/resume path.

• Rebinding an in-app Browser view should not produce a Chromium profile

warning.

• If browser profile initialization fails, the message should identify the

browser state and should not recommend signing out of the healthy Codex
account.

• One oversized thread should not degrade switching or browser lifecycle

handling for the rest of the app.

Related issues checked

• #11011 — switching between threads is very slow
• #18693 — large local histories collapse Desktop performance
• #20864 — Desktop appears to scan the full hot sessions tree
• #21299 — long Windows threads cause several seconds of UI unresponsiveness
• #25779 — meta issue for unbounded session/turn state and full-history hydration

This report adds:

• an exact in-app Browser WebView detach/reattach timeline;
• a native Chromium profile warning during the same switch;
• same-process rollout-size versus history-load timing;
• and an aggregate breakdown of what occupies the large rollout.

Confirmed vs unconfirmed

Confirmed:

• task switch, IAB reattach, profile warning, and slow history calls occurred

in the same time window;

• the affected rollout was about 613 MiB;
• large threads were an order of magnitude slower than small threads in the

same app log;

• Codex account read/status calls succeeded during the warning.

Not yet confirmed:

• the low-level cause of the Chromium profile warning;
• whether the warning itself causes any of the history-load latency;
• whether in-app Browser tab count alone contributes independently;
• whether all hot session files are scanned on every switch.

Privacy

Full logs, rollout files, local paths, user messages, generated images, tokens,
cookies, account details, and website contents are intentionally not attached.
A screenshot and additional sanitized excerpts are available if maintainers
need them.