[macOS][Desktop 26.818.61809] Opening code files can freeze the renderer; persisted editor tabs make the thread repeatedly unopenable

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.61809 (build 7019)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS 26.5.2 (build 25F84), Apple Silicon / arm64

What issue are you seeing?

Codex Desktop froze twice immediately after I clicked a code file in the frontend and the built-in text editor opened in the right panel.

After force-quitting and relaunching Desktop, reopening the affected task froze the UI again. The backend was still responsive, but the renderer became unusable. This made the task appear permanently unrecoverable from the Desktop UI.

The decisive recovery was to fully stop Desktop and remove only this task's persisted file-tab state from ~/.codex/.codex-global-state.json:

electron-persisted-atom-state["thread-tab-routes-v1:<redacted-thread-id>"]

That state contained three text-file-editor routes and an open right panel. After deleting only that one task-specific key, the same task opened normally and could continue. No conversation/session data, repository files, Git state, or task history was modified.

This strongly suggests that restoring persisted code-editor tabs can trap a task in a repeatable renderer freeze.

Actual behavior: the Desktop renderer becomes unresponsive, force-quit is required, and reopening the task repeats the freeze until the task-specific persisted file-tab state is manually removed.

What steps can reproduce the bug?

1. Open an existing local Codex task on macOS.
2. Click a code-file link/card in the Desktop frontend so it opens in the right-side text editor.
3. In the affected task, the entire Desktop UI becomes unresponsive.
4. Force-quit Desktop and relaunch it.
5. Reopen the same task.
6. Desktop freezes again while restoring the persisted editor tabs.
7. Fully quit Desktop and remove only the affected task's thread-tab-routes-v1:<thread-id> entry from .codex-global-state.json.
8. Relaunch Desktop and open the same task: it now loads and remains usable.

The original click-to-freeze behavior occurred twice. The persisted-tab recovery was then confirmed with an A/B result: tabs present -> repeatable freeze; task-specific tab state removed -> successful recovery.

The affected state contained three ordinary Go source files:
internal/policy/continuation.go — 3,450 bytes
internal/core/core.go — 147,147 bytes
internal/operatorcontrol/session.go — 58,542 bytes

The topology recorded:
right.open = true
right.tabIds = [three text-editor tabs]
right.activeTabId = internal/operatorcontrol/session.go

These are normal text files, not binary assets or files above the app's preview limit.

What is the expected behavior?

Opening or restoring a code editor tab should not block the conversation renderer or make a task permanently unopenable.

If editor restoration fails or repeatedly stalls, Desktop should degrade safely, for example by reopening the task with editor tabs closed, lazy-loading persisted editor tabs, isolating editor-pane failures from the conversation UI, or offering a task-specific "reset UI state / safe mode" recovery action.

Additional information

Diagnostic correlation:

• In-app feedback submitted for correlation: 01a03715-4678-7e61-a5e6-f0d00fd01f54.

Diagnostic observations:

• Affected task rollout size at recovery time: 15,042,438 bytes and 3,000 JSONL records.
• Desktop logs show thread/read completing in approximately 1-4 ms for the affected task, which argues against a blocked backend read.
• During the failed/repeated reopen attempts, Desktop logs repeatedly emitted:

[desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.

• Repeated failed launches were observed on 2026-08-25 between approximately 13:04 and 13:25 China Standard Time (UTC+8).
• Clearing generic Electron caches and changing repository data were not required for recovery.
• Editing the persisted state while Desktop was still running did not work because the in-memory state was written back. The app had to be fully stopped before removing the task-specific key.
• Raw logs and the raw global-state backup contain local paths and task identifiers, so they are not attached publicly. Sanitized excerpts can be supplied if useful.

GitHub suggested three potential duplicates. I reviewed all three; they appear related but distinct:

• #38315 is an intermittent, self-recovering whole-window freeze on Windows with no specific file-tab trigger.
• #33822 is a Windows renderer hang triggered by displaying about 200 KB of streamed tool output. It shares the ResizeObserver symptom, but not the editor-tab trigger or persisted task-state recovery.
• #26507 is the closest report because it involves macOS session-state restoration, but it progresses to a global blank-screen startup failure and is recovered by moving the entire ~/.codex directory. Here, only one task was affected, and deleting one task-specific persisted file-tab key recovered that same task while preserving all session and repository data.

Disclosure: this report was prepared by Codex at the account owner's request, based on a locally verified recovery procedure.