Desktop: closing an IAB tab should not depend on a responsive renderer

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

Codex Desktop 26.820.9563.0 on Windows 11 x64.

What subscription do you have?

Not related to the issue

What platform is your computer?

Microsoft Windows NT 10.0.26200.9168 x64 (Windows 11 25H2)

What issue are you seeing?

When Codex Desktop's UI renderer hangs while displaying a large external HTML
file, preview, or tool result, the affected tab loses its close path too.
Clicking the visible close button does nothing, and the native close-tab command
still depends on the same renderer that has stopped responding.

This can leave the tab impossible to close without restarting Codex. Other
Codex tabs or windows may also become difficult to operate even though the main
process still owns the affected guest webContents.

This is a separate recovery problem from the renderer-freeze triggers tracked
in #33822 and #33016. A renderer may still fail, but that failure should not
take away the command needed to close it.

What steps can reproduce the bug?

1. Launch Codex Desktop 26.820.9563.0 on Windows.
2. Open a large external HTML file, document preview, or another rendering-heavy
   page in the Codex in-app browser.
3. Continue rendering or updating the page until the UI renderer becomes
   unresponsive. Large tool output is another known trigger, as reported in
   #33822.
4. Click the affected tab's visible close button.
5. Try the native close-tab command or shortcut.
6. Observe that the tab does not close because teardown still depends on the
   unresponsive renderer.
7. Try interacting with another Codex tab or window and observe that the failed
   surface can interfere with recovery from the rest of the app.

The exact amount of content needed to trigger the initial renderer hang varies.
The close-path dependency was also confirmed by inspecting the packaged Desktop
main-process code.

What is the expected behavior?

Codex should keep an escape path outside the failed renderer.

A native shortcut or menu command should let the main process close the affected
guest without waiting for renderer acknowledgement. Closing one failed guest
should not crash its renderer process, close neighboring tabs, or make another
Codex window unusable.

The visible close button may require a larger Chrome-style separation if it
currently lives in the same frozen renderer, but at least one host-owned close
command must remain available.

Additional information

I made a local, release-specific prototype only to test the suspected close
path.
The prototype confirms that the main process can finalize the affected guest
without waiting for renderer acknowledgement. Six focused tests pass, and a
patched copy of the 26.820.9563.0 production main bundle passes
node --check.

I also have found three ways to recover from the problem without editing the codes:

• One suggested workaround is to disable HTML preview and related rich
  rendering features in the Codex configuration. This may avoid the trigger,
  but it changes normal preview behavior and is cumbersome to use.
• The workaround I normally use is to remove the affected file so Codex no
  longer tries to render it, then reopen the task.
• Another option is to use Open in New Tab. The new tab can open without
  restoring the broken rendered view. I can then fork the task, confirm that
  the fork works, and delete the old task.

These workarounds avoid or discard the rendering state that triggered the
freeze. They do not solve the underlying problem: once the renderer is stuck,
the original tab still has no independent close path.

The installed AppX package was not modified, and I have not run an installed
patched-versus-unpatched UI test. I am including these results as mechanism
evidence.

Start in the Desktop main-process code around the native close-tab command and the affected guest webContents teardown path. Review the six focused tests and use node --check as the available validation; done means a host-owned close command can finalize a stuck guest without renderer acknowledgement, crashing neighboring tabs, or making another window unusable.