Markdown preview tab becomes unresponsive after Codex edits the file #33160

Activity

1. azolotov

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jul 14, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   on Jul 14, 2026
3. Oct-2300 commented on Jul 21, 2026

   

   Oct-2300

   on Jul 21, 2026 – with ChatGPT Codex Connector

   More actions

   I can reproduce this on the Windows desktop app, and the production bundle plus logs point to a stale onBeforeClose guard rather than a missed pointer event.

   Environment

   • Microsoft Store ChatGPT/Codex app: 26.715.8383.0
   • Embedded frontend: 26.715.61943
   • Windows 11 x64
   • Native local Windows host (not WSL or VMOS)
   • A generated/local Markdown file opened in the right-side file viewer

   Evidence

   1. The desktop breadcrumb records the actual click on the Markdown tab's close button, including the button aria-label. The click reaches the renderer.
   2. The generic tab controller correctly supports closing index 0 and the final remaining tab: after removing the tab, an empty tab array closes the panel. The close is blocked before that reducer path.
   3. In the shipped review-file-source-tab-CDePGYBR.js, the file editor lifecycle represented by MF effectively does this when the file is dirty:

   const capturedSave = saveRef.current;
   onBeforeClose: dirty
     ? () => {
         capturedSave?.().then(saved => {
           if (!saved) return;
           clearGuard();
           closeTab();
         });
         return false;
       }
     : undefined;

   This creates permanent blocking states:

   • If saveRef.current was null when the guard was installed, optional chaining does nothing but the guard still returns false forever.
   • If saveUntilClean() resolves false or rejects (load/write/conflict/read-only/path failure), the guard is not removed and there is no retry/discard path.
   • Editor cleanup unregisters the save callback but does not remove an already installed guard.
   • The JF open/reopen path unconditionally carries existing?.onBeforeClose into the new descriptor, so a guard from an old editor lifecycle can survive reopening.

   In this reproduction, the same file open also hit the Windows path-normalization error tracked in #32474: a native path became /C:/..., and fs/watch failed with AbsolutePathBuf deserialized without a base path. That failure can make the save/load path return false and expose the stale guard.

   After the failed close, the panel remained mounted. The log recorded 73 additional ResizeObserver loop completed with undelivered notifications messages over the next several minutes, along with high renderer CPU/memory churn (working set peaked around 1.59 GB). Chinese IME input became effectively unresponsive while the renderer was saturated. This confirms severe layout/render churn, though it is not enough by itself to prove a monotonic JS heap leak.

   Suggested fix

   • Read saveRef.current when the close guard runs, not when dirty state installs it.
   • On missing save callback or load error, remove the guard and provide an explicit close path.
   • On save false/rejection, show Retry / Discard and close / Cancel; never leave a no-exit false guard.
   • Remove an owned guard on onSaveChange(null) and editor cleanup.
   • Track guard identity plus an editor/save epoch so an old cleanup or Promise cannot clear/close a reopened tab.
   • Deduplicate concurrent close attempts.
   • Do not inherit onBeforeClose across reset, path/host change, or a new editor lifecycle.
   • Disconnect the DetailPanel's observers and cancel any pending RAF during unmount.

   No raw logs are attached because they contain local workspace and task metadata. I can provide targeted sanitized excerpts if maintainers need them.