[macOS][Desktop] Restored 224 MB PDF preview causes crash/relaunch loop and makes task inaccessible

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

26.901.20858 (build 7658); bundled codex-cli 0.153.0-alpha.5

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.6.0 arm64 arm (macOS 26.6.2, build 25G83; 24 GB RAM)

What issue are you seeing?

Summary

If a very large local PDF is the active right-panel preview when a task is left, reopening that task restores the PDF automatically and can terminate the entire Codex app. Subsequent launches/reopens restore the same preview again, so the task enters a crash/relaunch loop and becomes inaccessible.

This is more severe than a failed preview because there is no safe way to open the task without restoring its last right-panel tab.

PDF characteristics

• Size: 234,397,436 bytes (about 224 MiB)
• Pages: 196
• PDF version: 1.4
• Not encrypted
• Not linearized/optimized
• The file opens normally in external viewers, and selected pages render successfully with standard PDF tools.

The PDF contains private educational material, so it is not attached. I can try to provide a synthetic large PDF if maintainers need one.

What steps can reproduce the bug?

1. Open a large local PDF from an assistant-provided file/artifact link in the Codex right-panel preview.
2. Leave the task with that PDF tab selected and the right panel open.
3. Reopen the task, or relaunch Codex while that task is restored.
4. Codex automatically restores the PDF preview.
5. The app becomes unresponsive and exits/relaunches.
6. Reopening the same task repeats the failure, making the task effectively inaccessible.

The private session ID is intentionally omitted from this public issue.

What is the expected behavior?

• Apply the preview size guard to every entry point, including assistant file/artifact links and session restoration.
• Render large PDFs lazily and enforce a memory budget.
• If preview restoration fails or exceeds a resource limit, discard/disable that preview tab and still open the task.
• Provide a safe-open action such as “Open task without restoring previews” or “Clear preview state.”

Additional information

Observed relaunch pattern

During one reproduction window, the app was launched six times in about 88 seconds after repeated attempts to reopen the affected task:

08:46:53Z
08:47:08Z
08:47:23Z
08:47:37Z
08:47:57Z
08:48:21Z

The desktop logs show the affected conversation becoming active and file watches being established shortly before each log ends. They do not contain an explicit OOM, renderer-gone, or native crash reason, and macOS did not create a matching .ips report. Memory exhaustion is therefore only a hypothesis, not a confirmed root cause.

Recovery/workaround

The task became accessible again only after both of these were done externally, without opening the task:

1. Queue a small Markdown file as the next right-panel tab for the affected task.
2. Rename the PDF so the persisted preview path no longer resolves.

Editing the persisted tab route on disk while Codex was running did not work because the application rewrote the old in-memory state.

Related issue

Possibly related to #26805, which documents a 10 MB file-preview limit in the workspace tree. This report is not a request to raise that limit: it describes a path that appears to bypass the guard and can make an entire task inaccessible.

Start by tracing the right-panel PDF preview size guard through assistant file/artifact links and session restoration, using a synthetic large PDF to reproduce the relaunch loop. Inspect persisted preview-tab state and the recovery path when rendering exceeds a resource limit. Done means large previews cannot crash or block task access, and a failed restoration is discarded or can be bypassed safely.