VS Code Codex Panel Stuck Loading or Gray Screen: From Webview Resource Errors to a Temporary CLI Switch

Recently, I prepared to start a new WordPress historical article processing project, planning to first complete the “historical article format inventory” before moving on to excerpt backfilling and other batch tasks.

I created a new project directory for this:

/home/wangqiang/code/wordpress-ai-excerpt-backfill

/home/wangqiang/code/wordpress-ai-excerpt-backfill

The original plan was simple:

1. Open this directory in VS Code;
2. Use the right-side Codex panel to initialize the repository;
3. Have Codex create the README, directory structure, and first-phase instructions;
4. Continue writing the read-only inventory script.

But as soon as I opened the Codex panel, I encountered a severely disruptive issue: Codex remained stuck in a loading state and then turned into a gray or white blank page.

This article documents the complete troubleshooting process and why I ultimately temporarily abandoned the VS Code panel in favor of the Codex CLI.

1. Symptom: The Codex Panel Keeps Loading

I first created an empty directory locally:

mkdir -p /home/wangqiang/code/wordpress-ai-excerpt-backfill

mkdir -p /home/wangqiang/code/wordpress-ai-excerpt-backfill

Then, in VS Code, I used:

File → Open Folder

File → Open Folder

to open:

/home/wangqiang/code/wordpress-ai-excerpt-backfill

/home/wangqiang/code/wordpress-ai-excerpt-backfill

The folder opened normally, and the Explorer on the left correctly displayed the project name.

However, after clicking the Codex panel on the right, the interface remained stuck on the OpenAI logo for a long time without entering the normal chat page.

I first tried a common operation:

Developer: Reload Window

Developer: Reload Window

which is:

Developer: Reload Window

Developer: Reload Window

But the problem persisted after reloading.

This indicated it was not just a simple UI initialization failure.

2. First, Verify if Codex CLI is Available

Since the VS Code panel was unusable, I decided to first confirm whether the Codex CLI was installed on my machine.

I executed:

command -v codex
codex --version

command -v codex
codex --version

The result showed:

Codex path: not found
Command "codex" not found

Codex path: not found
Command "codex" not found

The machine also did not have Node.js and npm at the time:

node --version
npm --version

node --version
npm --version

Both returned command not found.

To avoid installing Node.js and npm separately, I ultimately used the official Codex standalone installation script:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

curl -fsSL https://chatgpt.com/codex/install.sh | sh

The installation result was:

Codex CLI 0.144.6 installed successfully.

Codex CLI 0.144.6 installed successfully.

The installation location was added to:

/home/wangqiang/.local/bin

/home/wangqiang/.local/bin

Verifying again:

export PATH="$HOME/.local/bin:$PATH"
hash -r

codex --version

export PATH="$HOME/.local/bin:$PATH"
hash -r

codex --version

Output:

codex-cli 0.144.6

codex-cli 0.144.6

This showed that the Codex CLI itself was running normally.

3. Logging into Codex CLI

The current version uses the subcommand:

codex login

codex login

instead of:

codex --login

codex --login

Upon execution, Codex starts a local callback address and automatically opens the browser to complete ChatGPT account authorization:

Starting local login server on http://localhost:1455.

Starting local login server on http://localhost:1455.

After successful authorization, it displayed:

Successfully logged in

Successfully logged in

Then I ran the following in the project directory:

cd /home/wangqiang/code/wordpress-ai-excerpt-backfill
codex

cd /home/wangqiang/code/wordpress-ai-excerpt-backfill
codex

On first entry, Codex asks whether to trust the current directory:

Do you trust the contents of this directory?

Do you trust the contents of this directory?

Since this was a local project directory I had just created, I selected:

1. Yes, continue

1. Yes, continue

The CLI started normally and could execute read-only commands without issues.

This step was crucial because it proved:

• ChatGPT account login was working;
• The Codex service itself was usable;
• There was no issue with the current project directory;
• The failure was primarily concentrated in the VS Code Codex graphical panel.

4. Why I Still Wanted to Fix the VS Code Panel

Although the Codex CLI could continue working, I still wanted to fix the Codex panel in VS Code first.

The reason wasn’t that the CLI was unusable, but rather that the Codex panel better suited my current workflow.

In the right-side panel, there is a copy button next to each response, making it easy to copy Codex’s execution results into ChatGPT for further analysis.

Although the terminal has more space, copying long responses usually requires:

1. Selecting text with the mouse;
2. Using Ctrl + Shift + C;
3. Dealing with terminal line breaks and folded content.

For workflows that require frequently copying results back and forth between Codex and ChatGPT, the right-side panel is clearly more convenient.

Therefore, I continued troubleshooting the VS Code Webview.

5. Standard Codex Output Logs Provided No Useful Information

I first tried checking:

View → Output

View → Output

and selected the output source:

Codex

Codex

However, switching back and forth between “Chat” and “CODEX” did not reactivate the extension, nor did it generate any new useful logs.

I then tried:

Developer: Restart Extension Host

Developer: Restart Extension Host

which is:

Developer: Restart Extension Host

Developer: Restart Extension Host

The problem persisted, and the Codex output panel still did not show sufficient information.

At this point, continuing to stare at the extension output logs was unlikely to advance the troubleshooting.

6. Locating Webview Errors via Developer Tools

Next, I opened:

Help → Toggle Developer Tools

Help → Toggle Developer Tools

and navigated to:

Console

Console

This time, I finally saw a large number of clear errors.

The most frequent one was:

The FetchEvent for "<URL>" resulted in a network error response: insufficient resources.

The FetchEvent for "<URL>" resulted in a network error response: insufficient resources.

At the same time, many Codex Webview JavaScript files failed to load, for example:

GET https://file+.vscode-resource.vscode-cdn.net/.../webview/assets/appshot-window-IWY5MCjg.js net::ERR_FAILED

GET https://file+.vscode-resource.vscode-cdn.net/.../webview/assets/appshot-window-IWY5MCjg.js net::ERR_FAILED

And also:

use-chatgpt-composer-controller-5LuSW-YN.js
threads-create-DhlCLXwJ.js
codex-micro-DWAuwG0p.js
app-preloader-CPugGrqt.js

use-chatgpt-composer-controller-5LuSW-YN.js
threads-create-DhlCLXwJ.js
codex-micro-DWAuwG0p.js
app-preloader-CPugGrqt.js

These requests all pointed to Webview static resources in the local extension directory, but failed to load via VS Code’s Webview resource URL.

At this point, the scope of the problem had clearly narrowed:

• It was not a Codex login failure;
• It was not a project directory error;
• It was not that the Codex CLI was unavailable;
• It was not a standard API request failure;
• It was that the Codex Webview frontend resources were failing to load.

7. Confirming if the Extension Resource Files Actually Exist

Although the Console reported JavaScript file loading failures, I still needed to confirm whether these files actually existed on disk.

I checked the current Codex extension resource directory:

assets="$HOME/.vscode/extensions/openai.chatgpt-26.715.31925-linux-x64/webview/assets"

stat -c '%A  %U:%G  %s bytes  %n' "$assets"

find "$assets" -maxdepth 1 -type f | wc -l

assets="$HOME/.vscode/extensions/openai.chatgpt-26.715.31925-linux-x64/webview/assets"

stat -c '%A  %U:%G  %s bytes  %n' "$assets"

find "$assets" -maxdepth 1 -type f | wc -l

The result showed:

drwxrwxr-x  wangqiang:wangqiang
4959

drwxrwxr-x  wangqiang:wangqiang
4959

That is, there were 4959 files in the resource directory.

I then checked a few specific files mentioned in the errors:

for file in \
  appshot-window-IWY5MCjg.js \
  use-chatgpt-composer-controller-5LuSW-YN.js \
  threads-create-DhlCLXwJ.js \
  codex-micro-DWAuwG0p.js \
  app-preloader-CPugGrqt.js
do
    stat -c '存在：%s bytes  %n' "$assets/$file"
done

for file in \
  appshot-window-IWY5MCjg.js \
  use-chatgpt-composer-controller-5LuSW-YN.js \
  threads-create-DhlCLXwJ.js \
  codex-micro-DWAuwG0p.js \
  app-preloader-CPugGrqt.js
do
    stat -c '存在：%s bytes  %n' "$assets/$file"
done

All files existed, and their file sizes were normal.

For example:

Exists: 2622 bytes  appshot-window-IWY5MCjg.js
Exists: 2032413 bytes  use-chatgpt-composer-controller-5LuSW-YN.js
Exists: 6701 bytes  threads-create-DhlCLXwJ.js
Exists: 1069 bytes  codex-micro-DWAuwG0p.js
Exists: 337 bytes  app-preloader-CPugGrqt.js

Exists: 2622 bytes  appshot-window-IWY5MCjg.js
Exists: 2032413 bytes  use-chatgpt-composer-controller-5LuSW-YN.js
Exists: 6701 bytes  threads-create-DhlCLXwJ.js
Exists: 1069 bytes  codex-micro-DWAuwG0p.js
Exists: 337 bytes  app-preloader-CPugGrqt.js

This indicated that the extension installation package was not simply missing files.

More accurately:

The files existed on disk, but the VS Code Webview could not properly read or load them.

8. Clearing the Service Worker Cache

Since the errors occurred at the Webview’s resource loading layer, I first targeted VS Code’s Service Worker.

After completely closing VS Code, I executed:

source_dir="$HOME/.config/Code/Service Worker"
backup_dir="$HOME/.config/Code/Service Worker.bak-$(date +%Y%m%d-%H%M%S)"

mv "$source_dir" "$backup_dir"

source_dir="$HOME/.config/Code/Service Worker"
backup_dir="$HOME/.config/Code/Service Worker.bak-$(date +%Y%m%d-%H%M%S)"

mv "$source_dir" "$backup_dir"

Instead of deleting the directory directly, I renamed it to back it up as:

/home/wangqiang/.config/Code/Service Worker.bak-20260720-171027

/home/wangqiang/.config/Code/Service Worker.bak-20260720-171027

The benefits of doing this were:

• The original directory was not lost;
• It could be restored at any time;
• VS Code would automatically regenerate the Service Worker on the next launch;
• It would not affect project files or the Git repository.

After reopening VS Code, the Codex panel did change:

• The original loading logo disappeared;
• But the page turned into a completely gray blank area.

This showed that the cache rebuild had some effect, but the problem was not truly resolved.

9. Continuing to Clear Other Rebuildable Caches

Next, I continued to back up the following directories:

Cache
Code Cache
CachedData
GPUCache

Cache
Code Cache
CachedData
GPUCache

I executed:

timestamp="$(date +%Y%m%d-%H%M%S)"

for name in \
    "Cache" \
    "Code Cache" \
    "CachedData" \
    "GPUCache"
do
    source_path="$HOME/.config/Code/$name"
    backup_path="$HOME/.config/Code/${name}.bak-$timestamp"

    if [ -e "$source_path" ]; then
        mv "$source_path" "$backup_path"
    fi
done

timestamp="$(date +%Y%m%d-%H%M%S)"

for name in \
    "Cache" \
    "Code Cache" \
    "CachedData" \
    "GPUCache"
do
    source_path="$HOME/.config/Code/$name"
    backup_path="$HOME/.config/Code/${name}.bak-$timestamp"

    if [ -e "$source_path" ]; then
        mv "$source_path" "$backup_path"
    fi
done

The generated backups included:

Cache.bak-20260720-171447
Code Cache.bak-20260720-171447
CachedData.bak-20260720-171447
GPUCache.bak-20260720-171447

Cache.bak-20260720-171447
Code Cache.bak-20260720-171447
CachedData.bak-20260720-171447
GPUCache.bak-20260720-171447

After reopening VS Code, the Codex panel was still a gray blank.

Thus, it could be confirmed that:

Clearing the Service Worker, Cache, Code Cache, CachedData, and GPUCache individually did not resolve this issue.

10. Uninstalling and Reinstalling the Codex Extension

For the next step, I uninstalled Codex directly from the VS Code extensions page and then reinstalled the official OpenAI extension.

The extension ID is:

openai.chatgpt

openai.chatgpt

After reinstalling, the Codex panel still did not recover, turning into a white or grayish-white blank page.

At this point, the likelihood of a corrupted extension installation was further reduced.

11. Attempting to Roll Back the Codex Extension Version

Since the issue appeared suddenly that day, I suspected it might be a compatibility problem caused by a Codex extension update.

In the extension management menu, I selected:

Install Another Version

Install Another Version

The current failing version was:

26.715.31925

26.715.31925

I first rolled back to the version from 4 days ago:

26.707.91948

26.707.91948

After installation, the extension details page showed:

Version: 26.707.91948

Version: 26.707.91948

But after restarting the extension and VS Code, the Codex panel still failed to display.

I then continued to roll back to the version from a week ago.

The result was still the same.

There is a notable phenomenon here:

I can confirm that using Codex a week ago was normal, but now, even after installing that same version, the problem persists.

Therefore, this failure cannot simply be attributed to “a bug in a specific Codex extension version.”

More likely scenarios include:

• The current runtime environment of the VS Code Webview has changed;
• A system resource or Electron state has become abnormal;
• The extension upgrade left behind state that is not only located in standard cache directories;
• There is a compatibility boundary between the old/new extension and the current VS Code version combination;
• Loading a large amount of resources simultaneously in the Webview triggered a resource limit in the current environment.

The location of the failure can currently be identified, but a single root cause cannot yet be confirmed.

12. Final Decision: Temporarily Use the Codex CLI

Continuing to repeatedly clear caches, downgrade extensions, or modify the VS Code environment meant the time cost was beginning to exceed the value of solving the problem itself.

And the Codex CLI had already been verified as working normally:

cd /home/wangqiang/code/wordpress-ai-excerpt-backfill
codex

cd /home/wangqiang/code/wordpress-ai-excerpt-backfill
codex

Therefore, I ultimately decided to:

• Temporarily stop troubleshooting the VS Code Codex panel;
• Keep the current rolled-back version;
• Disable automatic updates for the Codex extension;
• Use the Codex CLI to move the project forward for now;
• Return to testing in VS Code after an official fix or a new version is released.

13. Currently Retained Backup Directories

During this troubleshooting process, I did not directly delete the VS Code caches, but instead kept the following backups:

~/.config/Code/Service Worker.bak-20260720-171027
~/.config/Code/Cache.bak-20260720-171447
~/.config/Code/Code Cache.bak-20260720-171447
~/.config/Code/CachedData.bak-20260720-171447
~/.config/Code/GPUCache.bak-20260720-171447

~/.config/Code/Service Worker.bak-20260720-171027
~/.config/Code/Cache.bak-20260720-171447
~/.config/Code/Code Cache.bak-20260720-171447
~/.config/Code/CachedData.bak-20260720-171447
~/.config/Code/GPUCache.bak-20260720-171447

I will not restore or delete them for now.

Once I confirm that VS Code is running stably and a rollback is no longer needed, I will clean up these directories all at once.

14. Conclusions Confirmed by This Troubleshooting

After this round of troubleshooting, the following points can currently be confirmed.

1. Codex Service and Account Login are Normal

The Codex CLI can complete the login and enter the project directory normally, so there are no obvious issues with the account or the service itself.

2. The Project Directory is Not the Cause of the Failure

Whether opening an empty directory or launching the CLI, the project path works normally:

/home/wangqiang/code/wordpress-ai-excerpt-backfill

/home/wangqiang/code/wordpress-ai-excerpt-backfill

3. Codex Extension Resource Files Actually Exist

The JavaScript files that failed to load in the Console all exist in the local extension directory, and their permissions and file sizes are normal.

4. The Failure Occurs at the VS Code Webview Resource Loading Layer

The most direct errors are:

insufficient resources

insufficient resources

and:

net::ERR_FAILED

net::ERR_FAILED

The failed requests primarily point to:

file+.vscode-resource.vscode-cdn.net

file+.vscode-resource.vscode-cdn.net

5. Clearing Standard Caches Did Not Solve the Problem

I have already processed:

Service Worker
Cache
Code Cache
CachedData
GPUCache

Service Worker
Cache
Code Cache
CachedData
GPUCache

But the problem persists.

6. Reinstalling and Rolling Back the Extension Also Did Not Solve It

After reinstalling the latest version, rolling back to the version from 4 days ago, and the version from a week ago, the Codex panel remained blank.

7. Using the CLI is Currently the Most Practical Solution

While the root cause has not been fully confirmed, the CLI is a more stable and lower-maintenance temporary alternative.

15. Next Steps

I will not expand the troubleshooting scope any further for this failure.

Going forward, I will:

1. Continue using the Codex CLI;
2. Proceed with initializing the wordpress-ai-excerpt-backfill repository;
3. Complete the historical article format inventory;
4. Keep the VS Code Codex extension from automatically updating;
5. Wait for a subsequent fix release;
6. Test the right-side Codex panel again once a new version is released.

This troubleshooting did not completely fix the Codex panel in VS Code, but it at least defined the boundaries of the problem and established an alternative path to continue working.

Compared to continuing to invest a lot of time tracking down an issue that temporarily does not affect core tasks, switching to the CLI to keep the project moving forward is the more appropriate choice right now.