[Codex Extension][VS Code][macOS] Renderer CPU spikes after file-changing task completes

What version of the IDE extension are you using?

26.325.21211

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

After Codex completes a task that actually changes files, the VS Code renderer/window CPU spikes heavily and the Codex task UI becomes very slow or effectively unusable.

Pure text-only conversations are fine.
Simple read-only interactions are also fine.

The issue appears after a file-changing task completes and the Codex UI renders the result state.

Developer: Reload Window temporarily clears the bad state, but the problem comes back after Codex completes another file-changing task.

What steps can reproduce the bug?

1. Open VS Code with the OpenAI Codex extension enabled.
2. Start a normal text-only conversation with Codex. This works fine.
3. Ask Codex to perform a small real task that changes a file.
4. Wait for the run to complete.
5. Observe very high CPU usage in VS Code renderer/window processes and severe slowdown in the Codex task view.

What is the expected behavior?

Completing a file-changing task should not cause the Codex task webview / VS Code renderer to enter a high-CPU bad state.

Additional information

What I ruled out:

codex_additional_info_20260327.md

• Not explained by Copilot/Copilot Chat interference. I reproduced it with Codex isolated.
• Not just terminal execution. Some read-only/status interactions are fine.
• Not just verification. The consistent trigger is a task that actually changes files.

During reproduction, code --status showed renderer/window processes much higher than the extension host, suggesting this is primarily a renderer/webview issue rather than the Codex child process itself.

The logs repeatedly show this error:

• Error fetching errorMessage="open-in-target not supported in extension"
• url=vscode://codex/open-in-targets

That looks potentially related to the failure mode.

I am attaching a redacted debug capture with the relevant code --status output and the repeated open-in-target not supported in extension log entries.