[VS Code][Windows] Codex panel becomes permanently blank under resource pressure and only recovers after restarting Extension Host

<!-- Failed to upload "Codex.log" -->

What version of the IDE extension are you using?

26.803.61601-win32-x64

What subscription do you have?

Pro

Which IDE are you using?

Visual Studio Code 1.123.0

What platform is your computer?

Windows 11 x64

What issue are you seeing?

The Codex panel in VS Code can become permanently blank/gray while Codex itself is still running in the background.

The issue occurred while the machine was under significant memory/resource pressure.

At the time, Windows was using approximately 87% of system memory. A Dart Language Server process was using about 5 GB of RAM, VS Code about 2.6 GB, Chrome about 1.6 GB, and other development tools/agents were running at the same time.

The rest of VS Code remained operational, including other extensions such as Claude Code, but the Codex panel became completely gray and stopped rendering.

Reducing memory usage afterward did not make the Codex UI recover.

Developer: Reload Webview did not recover the Codex panel either.

The only action that restored Codex was:

Developer: Restart Extension Host

After restarting the Extension Host, Codex immediately initialized again and the UI worked normally.

This is disruptive because restarting the Extension Host also restarts unrelated VS Code extensions, potentially interrupting other agents or tools that are actively working.

Important observation: the backend was still working

The blank panel does not appear to simply mean that the Codex backend crashed.

While the UI was experiencing problems, the Codex logs continued to show active reasoning/task events and normal background activity.

At the same time, the extension log contained a very large number of frontend errors such as:

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

These errors occurred repeatedly while Codex task processing was still progressing.

I do not know whether the ResizeObserver errors are the root cause, but they appear to show that the frontend was repeatedly encountering rendering/layout errors while the backend remained active.

Recovery behavior when the app-server is unavailable

As a separate diagnostic test after the panel had already become blank, I manually terminated the Codex codex.exe app-server process to see whether the extension could recover it.

It could not.

The log reported:

[CodexMcpConnection] Codex process fatal error
errorMessage="Codex process errored: Codex app-server process exited unexpectedly (code=1 (0x1), signal=null)."

After reopening/reloading the Codex UI, the extension then logged:

[CodexMcpConnection] Attempted to send app-server message but stdin is destroyed

followed by:

[CodexMcpConnection] Codex process fatal error
errorMessage="Codex process errored: Codex process is not available"

and:

[CodexWebviewProvider] Fatal error
message="Codex process errored: Codex process is not available"

Developer: Reload Webview still did not recover Codex.

However, immediately after running:

Developer: Restart Extension Host

the log showed:

Activating Codex extension
[CodexMcpConnection] Spawning codex app-server
[CodexMcpConnection] Initialize received id=1

followed shortly afterward by:

React root render requested windowType=extension
[startup][renderer] app routes mounted
ready provider mounted

The Codex UI then worked again.

This suggests that the extension keeps a dead app-server/IPC state after the process disappears and does not automatically recreate it until the extension itself is reactivated.

What steps can reproduce the bug?

The original blank-panel issue is not 100% deterministic, but I have observed it when the system is under significant memory/CPU/I/O pressure.

1. Open VS Code with the Codex extension.
2. Start a long-running Codex task.
3. Run other memory-intensive development workloads at the same time.
4. Allow system memory usage to become high enough for Windows to experience significant memory pressure and paging.
5. Continue using Codex or switch back to the Codex panel.
6. The Codex panel may become completely blank/gray while VS Code and other extensions remain responsive.
7. Reduce memory pressure.
8. The Codex panel remains blank.
9. Run Developer: Reload Webview.
10. The Codex panel still remains blank.
11. Run Developer: Restart Extension Host.
12. Codex works again.

There is also a deterministic recovery problem:

1. Start Codex normally.
2. Terminate the extension's codex.exe app-server process.
3. Open/reload the Codex panel.
4. The extension reports that stdin is destroyed / the Codex process is unavailable.
5. No replacement app-server is spawned.
6. Developer: Reload Webview does not recover it.
7. Run Developer: Restart Extension Host.
8. The extension activates again, spawns a new app-server, and Codex works.

What is the expected behavior?

If the Codex frontend/WebView enters a failed state, reopening or reloading the Codex panel should recreate the frontend without requiring the entire VS Code Extension Host to be restarted.

If the Codex app-server process terminates, the extension should detect this, dispose of the dead IPC connection, spawn a replacement app-server, initialize a new connection, and reconnect the UI.

At minimum, the extension should provide a dedicated command such as:

Codex: Restart

or:

Codex: Restart App Server

so that users can recover Codex without restarting unrelated VS Code extensions.

Additional information

I did not find a Rust panicked at message or a Rust panic backtrace associated with the original blank-panel issue.

There were occasional slow SQLite operations in the Codex logs during periods of heavy system load. These may be a consequence of memory/disk pressure rather than the root cause.

The most notable frontend symptom in the extension log is the repeated occurrence of:

ResizeObserver loop completed with undelivered notifications.

The most reliable workaround currently is:

Developer: Restart Extension Host

Developer: Reload Webview alone does not recover the broken state.

<!-- Failed to upload "Codex.log" -->