High CPU usage when using Codex extension v26.415.20818 in Cursor 3.1.15

Overview

In my environment (Cursor 3.1.15 with the Codex VS Code extension version 26.415.20818), opening the Codex chat window triggers sustained high CPU usage. Simply enabling the extension does not consume significant CPU; the spike occurs only after the chat panel is opened. Once triggered, the high CPU state persists even if the chat window is closed and the agent is idle. CPU usage returns to normal only after disabling the extension or restarting the application.

Several existing GitHub issues describe similar behaviour for earlier extension versions. Issue #16231 reports that after several prompt exchanges, the VS Code extension host and renderer processes run at high CPU, independent of prompt complexity, and that closing the conversation drops CPU usage【857017889042531†L472-L499】. The author also notes repeated “open‑in‑target not supported in extension” errors and that the problem returns after starting a new conversation【857017889042531†L472-L523】. Issue #16210 (now closed as a duplicate) describes that leaving the Codex tab does not reduce CPU load; a core remains pinned at ~100 % until the program is restarted【525159032561906†L238-L243】. These issues were reported for version 26.325.31654.

This report documents that the same high‑CPU behaviour persists in version 26.415.20818 and affects the Cursor app. The reproduction steps below and environment details should help the maintainers confirm that this is a regression or persistent bug.

Environment

• Cursor version: 3.1.15 (latest at the time of reporting, released 15 Apr 2026)
• Codex extension version: 26.415.20818
• Subscription: user is on the Plus plan.
• Operating system: Windows 11 Pro on bare metal with the Codex extension running inside a Windows Subsystem for Linux (WSL) environment. Similar behaviour has been observed on macOS and Linux【525159032561906†L238-L243】【857017889042531†L472-L499】, suggesting the issue is not platform‑specific.

Observed behaviour

• Opening the Codex chat in Cursor (or VS Code) causes the relevant process (renderer or extension‑host) to spike to roughly 25 % CPU utilisation, which remains elevated even while the application is otherwise idle.
• The high CPU load persists even after navigating away from the chat panel; closing the chat window does not reduce CPU usage.
• Only disabling or uninstalling the Codex extension, or restarting the application, reduces CPU usage. Simply re‑enabling the extension does not cause the CPU spike; the spike reappears only after opening the chat panel again.
• CPU usage does not return to normal after the agent finishes responding; it remains high even when idle.
• The problem occurs even if no prompt is sent at all; merely opening the chat panel is sufficient to trigger the high CPU usage. It does not depend on prompt complexity, diff rendering or code patching.
• There is no user‑visible error message. The behaviour matches the loop described in issue #16231, where logs show repeated “open‑in‑target” errors【857017889042531†L501-L523】.

Steps to reproduce

1. Install Cursor 3.1.15 and ensure the Codex extension is updated to version 26.415.20818.
2. Launch Cursor and open a new folder or workspace.
3. Open the Codex chat sidebar. It is not necessary to send any messages; the high‑CPU state appears immediately upon opening the panel.
4. Monitor system CPU usage (e.g., via Task Manager or Activity Monitor). As soon as the chat panel opens, the extension‑host or renderer process spikes to roughly 25 % and remains around that level even though Cursor is otherwise idle.
5. Navigate away from the chat or close the chat panel. CPU usage remains high.
6. Disable the Codex extension from the extensions list. CPU utilisation drops immediately.
7. Re‑enable the extension. High CPU does not appear until the chat panel is opened; once you reopen the chat, the high CPU behaviour returns.

These steps mirror the reproduction steps described by other users【857017889042531†L525-L533】 and confirm that the bug is not limited to earlier versions. Note that issue #16210 also reports that “just having the extension open eventually pins a core … even after closing the tab”【525159032561906†L238-L243】.

Expected behaviour

Opening the Codex chat should not cause sustained high CPU usage when the extension is idle. Navigating away from the chat or closing the panel should free resources and return CPU utilisation to normal. The extension should not leave a renderer or extension‑host process stuck at 100 % when not actively generating responses.

Analysis of related issues

• Issue #16231:  Reports high CPU usage on macOS/Linux with extension version 26.325.31654. The reporter notes that CPU and renderer processes “ramp up and remain high” after several prompts, regardless of prompt complexity, and that closing the conversation immediately drops CPU back to normal【857017889042531†L472-L499】. They also observe repeated “open‑in‑target not supported in extension” errors and suggest that the bug is tied to the conversation state machine【857017889042531†L501-L523】.
• Issue #16210:  Describes that the Codex extension in Cursor and VS Code “pins a core in both cursor and vs code” and that closing the tab does not reduce CPU; only restarting the program or disabling the extension helps【525159032561906†L238-L243】.
• Several other issues (#15764, #15397) mention high CPU usage when Codex applies code patches or renders diffs, but my reproduction does not involve code edits; it matches the conversation‑state loop described in #16231.

The persistent high‑CPU behaviour in version 26.415.20818 suggests that the regression has not been fully resolved. This report may be a duplicate of #16231, but it provides evidence that the problem continues in a later extension build and affects Cursor as well as VS Code.

Workarounds

• Disable the Codex extension when not actively using it. CPU usage drops immediately after disabling the extension.
• Roll back to an earlier extension version (e.g., 0.4.79) as suggested in issue #16231【857017889042531†L547-L549】. This is not ideal, as it removes recent features and fixes.
• Keep conversations short; closing and reopening chat windows may temporarily reduce CPU usage.

Suggested next steps

1. Investigate the “open‑in‑target” error loop noted in issue #16231【857017889042531†L501-L523】 and verify whether it still occurs in version 26.415.20818.
2. Test the extension in Cursor 3.1.15 across platforms and confirm whether the conversation‑state machine triggers the same high‑CPU loop.
3. Provide an update or patch that breaks the loop and releases CPU resources when the chat panel is closed.

I hope this report helps the maintainers diagnose and fix the persistent high CPU issue in the latest Codex extension. Please let me know if more logs or profiling data are needed.