Renderer process stuck in infinite microtask loop, consuming 100–180% CPU and disconnecting Remote SSH sessions
What version of the IDE extension are you using?
26.417.40842, 26.5417.40842
What subscription do you have?
plus
Which IDE are you using?
VS Code
What platform is your computer?
Darwin 24.5.0 arm64 arm
What issue are you seeing?
Summary
The extension's webview renderer process enters an infinite microtask loop upon startup, pinning one or more CPU cores at 100–180% indefinitely. The process is not terminated when the ChatGPT panel is closed. The resulting CPU starvation causes VS Code windows to become unresponsive and crash, which in turn terminates any active Remote SSH sessions.
---
What happens
After opening the ChatGPT panel, a Code Helper (Renderer) process enters a tight Promise microtask loop that never yields. The loop runs regardless of whether the panel is visible or actively used.
Observed CPU usage (Activity Monitor):
<img width="418" height="134" alt="Image" src="https://github.com/user-attachments/assets/6ed4fdcf-06db-4c11-aa9b-091afc4e40a0" />
Both high-CPU renderers shared the same --vscode-window-config UUID, confirming they belong to the same VS Code window hosting the extension's webview.
sample output for PID 46571 (3-second sample, 2126 total samples):
2026 / 2126 samples stuck in:
v8::MicrotasksScope::PerformCheckpoint
v8::MicrotasksScope::~MicrotasksScope
v8::Function::NewInstanceWithSideEffectType
... (repeating indefinitely)
The process never voluntarily yields control.
Secondary error present in renderer logs during the same sessions:
PendingMigrationError: navigator is now a global in nodejs,
please see https://aka.ms/vscode-extensions/navigator
This suggests the extension's webview code assumes a browser environment inside a Node.js context, which may be related to the runaway behavior.
---
Key observations
- Closing the ChatGPT panel in the UI does not terminate the renderer process — it continues spinning at full CPU
- Manually killing the process via kill <pid> causes VS Code to immediately spawn a replacement that exhibits the same behavior, confirming the loop is triggered at initialization, not by user interaction
- Removing the extension entirely drops all Code Helper (Renderer) CPU usage from ~300% combined back to normal background levels (~10–15% total)
---
Impact on Remote SSH
VS Code's Remote SSH connection is hosted inside the local VS Code window process. When that window becomes unresponsive due to CPU starvation, the Remote SSH session terminates — dropping all open terminals and unsaved state on the remote
machine. This is the primary user-visible symptom: unexplained, recurring Remote SSH disconnections.
What steps can reproduce the bug?
- Install extension version 26.417.40842 on macOS Apple Silicon
- Open the ChatGPT panel in VS Code
- Open Activity Monitor → CPU tab, filter by "Code Helper (Renderer)"
- Observe one or more processes consuming >100% CPU continuously
- Close the ChatGPT panel — processes remain and continue consuming CPU
- Leave VS Code open for an extended period — the window eventually becomes unresponsive or crashes
What is the expected behavior?
The extension's renderer process should consume negligible CPU when idle and should be fully terminated when its UI panel is closed.
Additional information
_No response_
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional findings from local analysis of the extension package (26.5417.40842)
---
The extension registers all webview panels and providers with retainContextWhenHidden: true (4 occurrences in extension.js). This instructs VS Code to keep the webview renderer process alive even when the panel is hidden or closed by the user. As a result, closing the ChatGPT panel does not terminate
the spinning renderer process — it continues consuming 100–180% CPU in the background until VS Code is fully restarted.
Changing these to retainContextWhenHidden: false would allow VS Code to destroy the renderer when the panel is not visible, which would at least contain the damage to periods when the panel is actively open. This is a one-line fix per call site and would meaningfully improve the user experience while
the root cause is being investigated.
---
The installed extension package contains only 24 JS files under webview/assets/, but index.html references 103 JavaScript modules via <link rel="modulepreload">. The majority of these files — including the main entry point (index-.js), the message bus (message-bus-.js), and the VS Code API bridge
(vscode-api-*.js) — are absent from the local package and are fetched from a remote server at runtime.
This has several implications worth flagging:
It would be helpful to understand whether this is intentional and, if so, whether there is a mechanism to verify the integrity of the remotely-loaded assets.