VS Code Stuck Loading Codex: From Suspecting Directory Renaming to Upgrading VS Code

Recently, I renamed my local project directory from its original debug-oriented name to one more suited for long-term maintenance:

/home/wangqiang/code/wordpress-ai-translation-pipeline

/home/wangqiang/code/wordpress-ai-translation-pipeline

After renaming the project directory, the Git repository, file list, and code itself all appeared normal. However, when I prepared to continue using Codex to inspect the translation plugin code, I noticed that the Codex chat panel on the right side of VS Code remained stuck in a loading state.

Because the issue occurred immediately after renaming the project directory, I initially suspected a connection between the two. However, through step-by-step troubleshooting, I ultimately found that the problem was more likely caused by a compatibility issue between VS Code and the Codex extension’s Webview resource loading. After upgrading VS Code from 1.127.0 to 1.129.1, Codex returned to normal.

This article documents the complete troubleshooting process.

1. Background of the Issue

I opened Codex this time to continue working on the protected placeholder validation issue during the SlyTranslate translation process.

This time, the validator correctly prevented incorrect content from being written into the article. Next, I needed to check whether it was appropriate to add a very strict single-token misnumbering fix in TranslationValidator.php, so I planned to have Codex perform a read-only analysis of the repository and production code.

But right at that moment, Codex in VS Code failed to load properly.

2. Codex Chat Panel Stuck in Loading State

After opening the project, VS Code’s file list displayed normally, and I could browse the code without any issues.

Although the Codex panel opened, a loading icon remained in the center of the interface, and no history tasks, input box, or chat content appeared.

My initial suspicions fell mainly on two causes:

1. The project directory had just been renamed, and the old VS Code workspace state might still point to the original path.
2. The Codex extension’s own Webview or login state might have encountered an anomaly.

Because the directory rename and the onset of the failure occurred so close in time, I investigated the directory issue first.

3. Reloading the VS Code Window Did Not Fix It

The first step was to execute the following in the Command Palette:

Developer: Reload Window

Developer: Reload Window

After the VS Code window reloaded, Codex remained stuck on the loading screen.

This indicated that the problem was not a simple UI refresh glitch.

Next, I closed the old window, opened a new VS Code window, and explicitly selected the new project directory:

/home/wangqiang/code/wordpress-ai-translation-pipeline

/home/wangqiang/code/wordpress-ai-translation-pipeline

This time, the file list loaded normally, but Codex still could not enter the chat interface.

At this point, I could safely conclude: Renaming the project directory was not the primary cause of Codex failing to load.

If the workspace path had simply become invalid, it would typically manifest as the project failing to open, file path errors, or loss of context, rather than the entire Codex Webview being stuck in a loading state.

4. Checking the Codex Extension Output

Next, I opened the “Output” panel at the bottom of VS Code and selected the following from the output source dropdown:

Codex

Codex

The logs showed that the Codex extension itself had activated successfully:

[info] Activating Codex extension
[info] [CodexMcpConnection] Spawning codex app-server
[info] [CodexMcpConnection] Initialize received id=1
[info] [IpcRouter] I am the router

[info] Activating Codex extension
[info] [CodexMcpConnection] Spawning codex app-server
[info] [CodexMcpConnection] Initialize received id=1
[info] [IpcRouter] I am the router

These logs indicated that:

• The Codex extension had been activated by VS Code;
• codex app-server had started;
• The IPC initialization request had been received;
• The backend process had not crashed outright during startup.

Therefore, the scope of the problem was narrowed down to the frontend Webview of the Codex chat interface.

5. Discovering Resource Loading Failures in Developer Tools

To further inspect the Webview frontend errors, I opened VS Code’s Developer Tools:

Help → Toggle Developer Tools

Help → Toggle Developer Tools

In the Console, I could see a large number of resource loading failures:

Failed to load resource: net::ERR_FAILED

Failed to load resource: net::ERR_FAILED

The failing files were located in the Codex extension directory:

/home/wangqiang/.vscode/extensions/openai.chatgpt-26.715.31925-linux-x64/webview/assets/

/home/wangqiang/.vscode/extensions/openai.chatgpt-26.715.31925-linux-x64/webview/assets/

These included multiple JavaScript modules, such as:

chats-thin-CkAcsMtd.js
settings-group-BhhtyN64.js
route-scope-provider-Dro00OIJ.js
settings-shared-CV4ZE1aS.js
page-header-DtzUAdLe.js

chats-thin-CkAcsMtd.js
settings-group-BhhtyN64.js
route-scope-provider-Dro00OIJ.js
settings-shared-CV4ZE1aS.js
page-header-DtzUAdLe.js

The most critical error was:

Uncaught TypeError: Failed to fetch dynamically imported module:
https://file+.vscode-resource.vscode-cdn.net/home/wangqiang/.vscode/extensions/openai.chatgpt-26.715.31925-linux-x64/webview/assets/app-main-BPH9pd0X.js

Uncaught TypeError: Failed to fetch dynamically imported module:
https://file+.vscode-resource.vscode-cdn.net/home/wangqiang/.vscode/extensions/openai.chatgpt-26.715.31925-linux-x64/webview/assets/app-main-BPH9pd0X.js

This error clearly explained why the Codex panel remained stuck in the loading state.

Although the Codex backend had started, the main JavaScript module for the chat interface failed to load, so the Webview naturally could not complete initialization.

Some other warnings also appeared in the logs:

potential listener LEAK detected
Extension host is unresponsive

potential listener LEAK detected
Extension host is unresponsive

And:

Loading the font ... violates Content Security Policy

Loading the font ... violates Content Security Policy

However, based on the symptoms, these were more likely secondary effects of the Webview repeatedly failing to load. The direct cause of the interface failing to start was still the failure to load dynamic modules like app-main.

6. Why I Didn’t Immediately Reinstall the Codex Extension

Upon discovering the extension resource loading failures, a straightforward fix would have been to uninstall and reinstall the Codex extension.

For example, I could have executed:

code --uninstall-extension openai.chatgpt

code --uninstall-extension openai.chatgpt

Then deleted the corresponding extension directory and reinstalled it.

However, VS Code happened to be prompting me about a new version update at the time.

Considering that the failure occurred during the local resource loading phase of the Webview, while the Codex extension backend was already starting normally, there was another possibility:

The Webview resource loading method used by the current Codex extension version had a compatibility issue with the older version of VS Code.

Compared to directly deleting the extension and its cache, upgrading VS Code first was a less invasive change and easier to roll back and verify.

Therefore, I decided to hold off on reinstalling Codex and just update VS Code first.

7. Upgrading VS Code from 1.127.0 to 1.129.1

The path for the downloaded new version installer was:

/home/wangqiang/Downloads/code_1.129.1-1784303641_amd64.deb

/home/wangqiang/Downloads/code_1.129.1-1784303641_amd64.deb

After closing all VS Code windows, I executed the following in the terminal:

sudo apt install "/home/wangqiang/下载/code_1.129.1-1784303641_amd64.deb"

sudo apt install "/home/wangqiang/下载/code_1.129.1-1784303641_amd64.deb"

The installer recognized this as an upgrade to the existing code package:

Upgrading:
  code

Summary:
  Upgrading: 1, Installing: 0, Removing: 0

Upgrading:
  code

Summary:
  Upgrading: 1, Installing: 0, Removing: 0

The original version was:

1.127.0-1782814776

1.127.0-1782814776

The upgraded version was:

1.129.1-1784303641

1.129.1-1784303641

The installation completed normally:

Unpacking code (1.129.1-1784303641) over (1.127.0-1782814776) ...
Setting up code (1.129.1-1784303641) ...

Unpacking code (1.129.1-1784303641) over (1.127.0-1782814776) ...
Setting up code (1.129.1-1784303641) ...

8. Codex Returns to Normal After the Upgrade

I restarted VS Code and opened the project directory again:

/home/wangqiang/code/wordpress-ai-translation-pipeline

/home/wangqiang/code/wordpress-ai-translation-pipeline

This time, the Codex panel loaded successfully.

The interface correctly displayed:

• History tasks;
• The Codex input box;
• Model and reasoning effort;
• The settings entry;
• The new task entry.

Ultimately, resolving this issue did not require:

• Reverting to the old project directory name;
• Deleting the new Git repository;
• Clearing the entire VS Code user directory;
• Deleting the Codex login state;
• Reinstalling the Codex extension.

Simply upgrading VS Code restored Codex to normal operation.

9. Actual Assessment of This Failure

The facts that can currently be confirmed include:

1. After renaming the project directory, VS Code could still open the project and load the file list normally.
2. The Codex extension could activate successfully, and codex app-server could also start.
3. Multiple local JavaScript modules in the Codex Webview failed to load.
4. After the main entry dynamic module app-main-BPH9pd0X.js failed to load, the chat interface remained stuck in the loading state.
5. After upgrading VS Code from 1.127.0 to 1.129.1, Codex returned to normal.

Therefore, the most reliable conclusion is:

This failure was more likely a Webview resource loading compatibility issue between the older version of VS Code and the current Codex extension, rather than being caused by the project directory rename.

However, since I did not further compare the internal Webview implementations of VS Code, nor did I reinstall the same version of the Codex extension for cross-testing, I cannot definitively prove exactly which code had the compatibility issue.

From a practical maintenance perspective, this conclusion is sufficient to guide future actions.

10. Troubleshooting Steps for When Codex is Stuck Loading

Based on this experience, you can follow this sequence to handle similar issues in the future.

1. Reload the VS Code Window

Execute:

Developer: Reload Window

Developer: Reload Window

If it is just a temporary Webview state anomaly, this step might directly fix it.

2. Reopen the Project Directory in a New Window

Do not directly use the old .code-workspace file; explicitly open the actual project directory.

This rules out the impact of workspace cache, old paths, and directory renames.

3. Check the Codex Output Logs

Open:

View → Output

View → Output

Then select from the dropdown:

Codex

Codex

Focus on confirming whether the extension has activated successfully and whether codex app-server has started.

4. Check the Developer Tools Console

Open:

Help → Toggle Developer Tools

Help → Toggle Developer Tools

Look specifically for:

Failed to load resource
Failed to fetch dynamically imported module
ERR_FAILED
401
403
CSP
WebSocket

Failed to load resource
Failed to fetch dynamically imported module
ERR_FAILED
401
403
CSP
WebSocket

If a large number of errors point to the Codex extension’s webview/assets directory, the problem is usually no longer with the project code itself.

5. Update VS Code First

If an update is available for VS Code, try upgrading VS Code first, then test again.

This step is generally safer than deleting extension directories and user caches.

6. Consider Reinstalling the Codex Extension as a Last Resort

Only consider the following if Codex still fails to load after upgrading VS Code:

• Uninstalling openai.chatgpt;
• Deleting leftover extension directories;
• Reinstalling the extension;
• Logging back into ChatGPT or Codex.

This avoids overly broad cleanup right from the start.

11. Additional Notes on Renaming the Project Directory

Before this failure occurred, the project directory had just been renamed from a temporary debug name to:

/home/wangqiang/code/wordpress-ai-translation-pipeline

/home/wangqiang/code/wordpress-ai-translation-pipeline

The temporal proximity makes it easy to assume a direct relationship between the two.

However, during troubleshooting, the new directory opened normally, and the Git repository and file list showed no anomalies. Even after completely closing the old window and reopening the new directory from a new window, Codex still failed to load.

This indicates that renaming the directory could, at most, affect:

• Recent project history;
• Workspace cache;
• Project path references;
• Certain project-level configurations.

It cannot explain why a large number of JavaScript files in the Codex Webview encountered net::ERR_FAILED.

When troubleshooting software issues, recently made changes are indeed worth suspecting first, but you still need to use logs to determine the actual layer where the failure occurred.

12. Summary

On the surface, this issue appeared as Codex being stuck loading, and since it happened right after renaming the project directory, it was easy to focus attention on the repository path and VS Code workspace state.

But the actual logs showed:

• The Codex backend started normally;
• The Webview frontend modules failed to load;
• The main dynamic module could not be fetched;
• The issue disappeared after upgrading VS Code.

The final solution was very simple:

VS Code 1.127.0
→ Upgrade to VS Code 1.129.1
→ Codex returns to normal

VS Code 1.127.0
→ Upgrade to VS Code 1.129.1
→ Codex returns to normal

This troubleshooting experience also reinforces that when encountering IDE extension anomalies, you cannot just observe the UI behavior. Output logs and Developer Tools can often quickly distinguish between:

• Project path issues;
• Extension backend issues;
• Login and network issues;
• Webview frontend resource issues;
• Version compatibility issues between the IDE and the extension.

Once the scope of the failure is confirmed, choosing the minimal repair action is safer than directly deleting configurations and reinstalling the entire environment.