[Regression] Codex Remote SSH WebView spins Code Helper (Renderer) at 100-200%; Service Worker reset is temporary

What version of the IDE extension are you using?

openai.chatgpt-26.707.31428 (macOS arm64 locally and Linux x64 on the Remote SSH hosts)

What subscription do you have?

ChatGPT login. The exact plan is not shown in the IDE or codex login status.

Which IDE are you using?

VS Code 1.128.0 with Remote SSH 0.124.0.

What platform is your computer?

Local: Darwin 25.5.0 arm64 arm (Apple Silicon, 16 GB RAM)

Remote workspaces: Linux x64 over VS Code Remote SSH.

What issue are you seeing?

The Codex WebView intermittently becomes stuck on the logo/loading screen or turns white. Sometimes the rest of the VS Code window remains usable, but a local Code Helper (Renderer) process enters a persistent 98-200% CPU loop and the Mac heats rapidly. VS Code also eventually shows its native "Window is not responding" dialog.

The remote Codex app-server processes remain near 0% CPU, so the direct CPU consumer is the local VS Code renderer rather than the remote workload.

On 2026-07-10 I reproduced this three times in sequence:

1. After a full macOS reboot, renderer PID 1025 reached about 100% CPU less than two minutes after VS Code started.
2. I killed the complete VS Code process tree and reopened it. Replacement renderer PID 2407 reached about 98% CPU and stayed hot for more than one minute.
3. I killed/restarted VS Code again. Replacement renderer PID 3557 reached about 100% CPU within two minutes.

In all three cases, terminating only the sampled hot renderer immediately removed the sustained VS Code CPU load. The visible editor windows and Remote SSH connections could remain alive after that targeted termination.

I then ran a controlled single-window test. Reloading only Remote SSH window B recreated the Codex WebView and produced renderer PID 9922. The PID shared the same --vscode-window-config UUID as window B, stayed at 94-100% CPU for over 24 minutes, and dropped immediately when that renderer alone received TERM. This rules out the other restored window as the direct owner of that specific hot renderer. Earlier rapid reproductions mapped to Remote SSH window A, so the failure is not host-specific.

Five-second macOS sample captures show sustained V8/Electron execution. Earlier captures of the same failure included a ServiceWorker thread; the latest capture spent most samples in V8 microtask/compiler paths such as:

Process:         Code Helper (Renderer)
Parent Process:  Code
v8::MicrotasksScope::MicrotasksScope(...)
v8::internal::compiler::CompilationDependencies::FieldTypeDependencyOffTheRecord(...)

The controlled 24-minute failure sample showed both the main renderer thread and the ServiceWorker thread spending most samples in these V8 microtask/compiler paths. Physical footprint was about 293 MB (308 MB peak).

VS Code logs at the same timestamps repeatedly contain:

CodeWindow: detected unresponsive
PendingMigrationError: navigator is now a global in nodejs
potential listener LEAK detected, popular
potential listener LEAK detected, dominated

I did not observe the open-in-target not supported in extension error signature from openai/codex#16849 in the incident logs. This appears to be a current regression or a different high-CPU path from that older report.

Clean-profile control and workaround

I started a separate VS Code process with a new temporary --user-data-dir, the same extension directory, the same VS Code build, and the same Remote SSH workspace. After opening the Codex sidebar:

• openai.chatgpt activated normally.
• The remote Codex app-server initialized successfully.
• Codex logged app routes mounted after 5564ms and ready provider mounted.
• The local WebView renderer stayed around 21-23% during startup instead of reaching 100%.
• There was no CodeWindow: detected unresponsive event.

The existing VS Code profile's Service Worker database contained registrations for many historical WebView origins and several old Remote SSH authorities. I then fully quit VS Code, moved only the local Service Worker directory aside as a reversible backup, and restarted.

After that reset:

• Both restored Remote SSH Codex panels rendered their full task list, new-task button, prompt input, and model controls.
• There were no hot renderers in a diagnostic snapshot.
• Renderer CPU stayed around 4-10%, rather than 99-200%.
• Reloading one Remote SSH window again loaded Codex successfully within about 12 seconds.
• A further stability check at roughly six minutes still showed both panels usable and no renderer over 10%.

This was an effective temporary workaround, and shows that VS Code WebView Service Worker state participates in the failure. It is not a permanent fix: the extension also emits navigator migration and listener-leak errors during startup.

Recurrence after resetting Service Worker state

About 90 minutes after the reset, I opened another Remote SSH workspace and its Codex WebView created a third origin in the newly rebuilt Service Worker database. A new local renderer then sustained about 199% CPU for roughly 16 minutes until terminated.

The new five-second sample again showed both the main renderer thread and ServiceWorker thread active in V8/Electron microtask/compiler paths. At the same time, that window's renderer log showed a listener-leak warning followed by an almost clockwork remote extension-host unresponsive/responsive cycle at roughly one-minute intervals.

The newly rebuilt Service Worker directory was only about 88 KB and had three registered WebView origins. The old backup had not been restored. This rules out a large accumulation of historical registrations as a necessary condition. Clearing Service Worker state remains a useful recovery step, but the stronger correlation is now between Codex WebView activation/registration and Remote SSH extension-host churn.

What steps can reproduce the bug?

The trigger is highly reproducible in my current setup:

1. Start VS Code on macOS.
2. Let VS Code restore two Linux Remote SSH workspace windows.
3. Enable/open the Codex sidebar in those remote workspaces, or run Developer: Reload Window with the Codex sidebar visible.
4. Wait about 30-120 seconds. In one controlled run the loop remained active for more than 24 minutes until manually terminated.
5. The Codex panel becomes stuck on its logo/loading state or white screen.
6. Check Activity Monitor or code --status: one local child Code Helper (Renderer) stays around 100% CPU, while remote Codex app-server processes remain near idle.
7. Quit and reopen all of VS Code. The same condition can return within about one minute after the Remote SSH windows and Codex WebViews are restored.

What is the expected behavior?

The Codex sidebar should load normally, and an idle or loading Codex WebView should not keep a local VS Code renderer at approximately 100% CPU. Restarting VS Code should not immediately recreate the bad renderer state.

Additional information

• VS Code main logs recorded CodeWindow: detected unresponsive during each rapid reproduction.
• The navigator is now a global in nodejs migration error and listener leak warnings occurred in both restored Remote SSH windows during extension startup.
• Renderer command-line UUIDs correlated the controlled hot PID with the specific Remote SSH window that had just been reloaded.
• macOS pmset -g therm did not record an OS thermal or performance warning, despite obvious chassis heating.
• Memory pressure was healthy and there was no swap activity during the captured incident.
• Similar but not identical reports: openai/codex#16849, openai/codex#16941, openai/codex#14620, openai/codex#26951, and openai/codex#26606.
• I have retained multiple timestamped process snapshots, failure/success screenshots, and five-second renderer samples and can provide sanitized copies if maintainers need them.