[Windows] Recurring file-pane failure: FileRenderer.processFileResult: Line doesn't exist

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

26.901.5280.0 (OpenAI.Codex Windows Store package; renderer release 26.901.41600)

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex Desktop file pane replaces the document with a raw JavaScript exception and stack trace, making the file unreadable in the pane. The problem is recurring on my machine and continues after closing and reopening the application.

Error: FileRenderer.processFileResult: Line doesn't exist
    at R1e.processFileResult (app://-/assets/app-initial-ffce11d82782.js:315:9298)
    at R1e.renderFile (app://-/assets/app-initial-ffce11d82782.js:315:8022)
    at Q0e.renderPreparedFile (app://-/assets/app-initial-ffce11d82782.js:1655:12879)
    at Q0e.renderPreparedFile (app://-/assets/app-initial-ffce11d82782.js:1655:36457)
    at Q0e.render (app://-/assets/app-initial-ffce11d82782.js:1655:11266)
    at g6e (app://-/assets/app-initial-ffce11d82782.js:1663:94874)
    at e.computeRenderRangeAndEmit (app://-/assets/app-initial-ffce11d82782.js:1663:1…)
    at e.render (app://-/assets/app-initial-ffce11d82782.js:1663:112722)
    at ResizeObserver.handleResize (app://-/assets/app-initial-ffce11d82782.js:1663:1…)

Two stack-frame column numbers are clipped in the recorded evidence; ellipses mark those missing columns.

This is a functional rendering/reliability bug. A separate system-wide low-memory incident occurred under heavy workload; no causal attribution to this viewer failure is established.

What steps can reproduce the bug?

1. Open W3SVC-before-disable.reg in the Codex file pane as text. If using the .reg.txt attachment, remove only the final .txt suffix first; do not change the file encoding or contents. Do not import or execute the registry file.
2. Click a line (the recorded sequence includes interaction around line 12) and scroll with the mouse wheel.
3. The document is replaced by the exception and stack trace while the file breadcrumb remains visible.
4. Close and reopen Codex. The rendering problem continues to recur on my machine.

The sequence above describes the observed interaction. The minimum click/scroll sequence has not been isolated; recurrence does not mean that every file or every attempt fails. Resize callbacks appear in the stack, but resizing alone has not been established as the trigger.

Relevant local session: 01a0737d-0bde-7601-ba2a-338bbfc46859. Token-limit and context-window usage were not recorded for this file-pane failure.

What is the expected behavior?

The file should remain readable when clicking, scrolling, or changing the pane layout. The viewer should handle UTF-16LE text with a BOM consistently. If rendering fails, the pane should provide a recoverable error state instead of replacing the document with a raw JavaScript stack trace.

Additional information

File properties and completed analysis

• Exact reproducer: 6,868 bytes, UTF-16LE with BOM FF FE.
• 63 CRLF pairs / 64 segments including the terminal empty segment; maximum line length: 80 characters.
• Tolerant UTF-8 decoding produces 3,433 NUL characters and two replacement characters. Splitting CR and LF independently yields 127 segments.

These results support the probable chain: incorrect encoding detection or normalization → inconsistent line models → a scroll/layout update requests a nonexistent line → FileRenderer.processFileResult throws. This is a supported hypothesis, not a confirmed implementation-level root cause. ResizeObserver is a possible trigger, not an established primary cause.

Renderer log context

The main-window log contains 473 global-error entries: 472 occurrences of ResizeObserver loop completed with undelivered notifications. and one framebuffer error. The ResizeObserver entries span 2026-09-05 21:34:40.105Z–23:58:14.573Z. This count is not the number of file-pane failures and does not establish a memory leak or an infinite loop.

A recoverable Chromium GPU-child crash was logged at 22:48:09.048Z, followed by a framebuffer error at 22:48:09.898Z. Application activity continued afterward. A concurrent system-wide memory-pressure incident occurred under heavy workload; no causal link to this file-pane failure was established.

Scope of the completed security review

Offline review confirmed a functional viewer bug. It found no demonstrated RCE, XSS, path traversal, exfiltration, remote DoS, or cross-user impact. The file contains no HTML, JavaScript, or URLs. The observed recurrence after reopening is a rendering/reliability symptom, not security persistence. No online exploitation tests were performed.

Environment and textual evidence

Windows 11 Pro N, x64, build 10.0.26200; NVIDIA GeForce RTX 3050; approximately 24 GB RAM; 12 logical processors. Local app-server/CLI metadata: 0.153.4. The Store package version and renderer release are recorded separately above.

Supporting files:

• W3SVC-before-disable.reg.txt: original reproducer bytes, with a .txt transport suffix; view as text only.
• codex-desktop-global-errors-summary.txt: error counts and timestamps.
• codex-desktop-version-context.txt: recorded renderer release and Store package version.

Only textual evidence is included; no screenshots or video.

codex-desktop-global-errors-summary.txt
codex-desktop-version-context.txt
W3SVC-before-disable.reg.txt

Start with the supplied W3SVC-before-disable.reg.txt reproducer and the FileRenderer.processFileResult and renderFile frames in app-initial-ffce11d82782.js. Reproduce the click-and-scroll sequence on Windows using the UTF-16LE file, then trace the file-rendering and layout update path. Done means the file remains readable and rendering failures show a recoverable error instead of a raw JavaScript stack trace.