[macOS Desktop] In-app browser tabs closed with × reappear after restart; persisted tab topology still contains closed tabs #45004

Environment

• ChatGPT/Codex desktop on macOS
• App version: 26.908.40834
• Bundle identifier: com.openai.codex
• Observed September 12, 2026

Summary

Closing an in-app browser tab using its own × button removes it from the live browser tab inventory. After quitting and relaunching the app, previously closed tabs reappear with the same tab identifiers.

This is a tab-close persistence issue, not merely hiding the browser pane and not a website sign-in issue.

Observed reproduction

1. An existing task had several in-app browser tabs.
2. The user closed two tabs using their individual × buttons.
3. Read-only browser inventory confirmed the two tabs were no longer present.
4. The user restarted the desktop app.
5. The previously closed tabs reappeared in the browser inventory with the same provider tab IDs. The post-restart set differed from the set observed immediately before restart and matched an earlier set.
6. In a separate follow-up check, the user closed one of the restored tabs again, without restarting afterward.
7. Read-only browser inventory confirmed this tab was absent, but the on-disk persisted tab state still contained its ID both in routes and topology.right.tabIds.

Persisted-state evidence

The inspected location was:

.codex-global-state.json → electron-persisted-atom-state → thread-tab-routes-v1:<redacted-thread-id>

Sanitized observation after the follow-up close:

live browser inventory contains closed tab: false
persisted routes contains closed tab: true
persisted topology.right.tabIds contains closed tab: true

The snapshot was inspected while the app remained running. This demonstrates a live/persisted-state discrepancy before restart. It does NOT establish whether the exact cause is a missed close-state write, delayed persistence, competing state stores, or stale-state reconciliation. The file-wide modification time is not proof that this specific key was updated.

Expected

Closing a tab removes it from the live tab set and the state used for restoration. It should remain closed after restarting the app.

Actual

The live tab closes, but persisted right-pane tab membership retains it, and restarting restores previously closed tabs.

Related reports, not claimed duplicates

• [macOS] Restoring a persisted Google sign-in tab in the in-app browser pins the renderer at 100% CPU #39552: macOS persisted browser-tab restoration causing a renderer hang; discusses the same persisted-state keys.
• [Windows Desktop] Reopening chats eagerly restores every persisted in-app-browser tab, adding ~3.2 GB RAM #38751: eager restoration of persisted tabs on Windows and memory impact.

This report specifically concerns tabs explicitly closed through the GUI, rather than inactive tabs that were left open.

Privacy and test boundaries

Inspection was read-only. No cookies, authentication data, browser profiles, or persisted configuration were cleared or edited during this diagnosis. No tabs were reopened by the investigating assistant during the controlled comparison. Raw logs, browsing URLs, local user paths, and actual task/tab IDs are omitted for privacy. No workaround or root-cause fix has been verified.