Codex Recovers After VS Code Upgrades to 1.130.0: Old Extensions Load Without Updates

On July 20, 2026, I documented an issue where the Codex panel in VS Code was stuck in a continuous loading state, displaying gray and white screens.

At the time, I confirmed that the Codex CLI worked properly, but the Codex Webview in VS Code failed to load. I tried clearing the cache, reinstalling the extension, and rolling back the Codex extension version, but the problem persisted. I ultimately decided to pause troubleshooting and switch to the Codex CLI to continue working.

The complete troubleshooting process is documented in the previous article:

“Codex Panel Continuously Loading and Gray Screen in VS Code: Troubleshooting Webview Resource Errors and Temporarily Switching to CLI” (site article 19684)

On July 29, 2026, I upgraded VS Code from 1.129.1 to 1.130.0.

After reopening VS Code, the previously unusable Codex panel surprisingly recovered immediately.

Even more noteworthy:

I had not even updated the Codex extension to the latest version at this point; I was still using the version from a week ago that I had rolled back to during troubleshooting.

This result clarifies the scope of the previous problem.

1. The July 20 Issue Was Not Investigated Further

The previous article already documented the full troubleshooting process, so I will not repeat it here.

The key conclusions at the time were:

• Codex CLI was normal;
• The Codex panel in VS Code was abnormal;
• Webview resource loading failures appeared in the Developer Tools;
• Clearing various VS Code caches had no effect;
• Reinstalling the Codex extension had no effect;
• Rolling back to an older Codex extension version that previously worked still had no effect.

Therefore, I did not continue investigating Electron, Chromium, Webview, or the Linux desktop environment, and instead proceeded with development directly via the Codex CLI.

My reasoning was that since my work was not truly blocked, I would wait for subsequent VS Code or Codex updates and then retest.

Nine days later, the opportunity to test arrived.

2. Upgrading VS Code from 1.129.1 to 1.130.0

On July 29, I downloaded the new VS Code Debian package:

code_1.130.0-1784734578_amd64.deb

code_1.130.0-1784734578_amd64.deb

The computer originally had VS Code 1.129.1 installed.

Navigated to the download directory:

cd ~/下载

cd ~/下载

Then executed:

sudo apt install ./code_1.130.0-1784734578_amd64.deb

sudo apt install ./code_1.130.0-1784734578_amd64.deb

APT correctly identified this as an upgrade to the existing code package:

Note, selecting 'code' instead of './code_1.130.0-1784734578_amd64.deb'

The following packages will be upgraded:
  code

Summary:
  Upgrading: 1, Installing: 0, Removing: 0, Not upgrading: 81

Note, selecting 'code' instead of './code_1.130.0-1784734578_amd64.deb'

The following packages will be upgraded:
  code

Summary:
  Upgrading: 1, Installing: 0, Removing: 0, Not upgrading: 81

The overwrite upgrade then completed:

Preparing to unpack .../code_1.130.0-1784734578_amd64.deb ...
Unpacking code (1.130.0-1784734578) over (1.129.1-1784303641) ...
Setting up code (1.130.0-1784734578) ...

Preparing to unpack .../code_1.130.0-1784734578_amd64.deb ...
Unpacking code (1.130.0-1784734578) over (1.129.1-1784303641) ...
Setting up code (1.130.0-1784734578) ...

That is:

VS Code 1.129.1 → VS Code 1.130.0

The entire upgrade process completed without errors.

3. Reopening VS Code, Codex Has Returned to Normal

After the upgrade completed, I reopened VS Code.

Upon entering the Codex panel this time, the previous continuous loading, gray blank screen, and white blank screen did not reappear.

Codex history tasks displayed properly, and the input area was restored.

In other words, on this computer, the actual state changed from:

VS Code 1.129.1: Codex panel abnormal

to:

VS Code 1.130.0: Codex panel normal

In between, I did not repeat the previously complex cache clearing operations.

4. More Crucially: The Codex Extension Remained the Older Rolled-Back Version

After the recovery, I checked the Codex extension version again.

I noticed a very interesting detail.

The extension marketplace currently offers a newer version:

26.721.41059

26.721.41059

But the version actually installed on my system is still:

26.715.61943

26.715.61943

Which appears in the version list as:

1 week ago (current)

This point is more valuable for reference than a simple “it works after an upgrade.”

When troubleshooting the issue on July 20, I specifically rolled back the Codex extension to this earlier version, hoping to restore normal operation via the older version.

But at that time:

VS Code 1.129.1 + older Codex extension still failed to load properly.

Now it has become:

VS Code 1.130.0 + the same older Codex extension loads properly.

In other words, Codex did not recover this time because I simultaneously upgraded the Codex extension.

As of the time of the screenshot, I had not even installed the latest Codex extension.

The only definitive version change that occurred was upgrading the VS Code core itself from 1.129.1 to 1.130.0.

5. This Further Reduces the Likelihood That the Codex Extension Version Itself Was the Root Cause

During the previous troubleshooting, I could not completely rule out an issue with the Codex extension itself.

Because what happened at the time was:

The Codex panel suddenly became abnormal while I happened to be using a VS Code extension that updates frequently.

So my first reaction was naturally to suspect the extension version.

But I later found that rolling the extension back to the version from a week ago—which had previously worked perfectly—had no effect either.

And now new evidence has emerged:

With the Codex extension kept at the older version, the problem disappeared after only upgrading the VS Code core.

Therefore, it now seems even less likely that the previous problem was caused solely by a specific Codex extension version.

More suspicious directions include:

• VS Code 1.129.1 itself;
• The Electron / Chromium runtime environment used by VS Code;
• The resource loading mechanism of the VS Code Webview;
• Some compatibility issue between VS Code 1.129.1 and the Codex extension.

However, I still will not directly conclude that “VS Code 1.129.1 has a definitive bug.”

6. For Now, It Cannot Be Proven That the Root Cause Is VS Code 1.129.1

What I can confirm right now is only the actual phenomenon.

The original combination was:

VS Code 1.129.1 + Codex 26.715.61943 → Codex abnormal

The current combination is:

VS Code 1.130.0 + Codex 26.715.61943 → Codex normal

This is a quite valuable comparison.

However, to strictly prove the root cause, I would need to at least repeat the following:

1. Downgrade VS Code to 1.129.1;
2. Confirm whether Codex shows a gray screen again;
3. Upgrade back to 1.130.0;
4. Confirm whether the problem disappears again.

If I wanted to further pinpoint the specific code-level cause, I would need to study the changes regarding Webview, Electron, or Chromium between VS Code 1.129.1 and 1.130.0.

But I do not plan to continue doing this.

Because Codex is now working normally.

Actively downgrading a working environment back to a faulty state just to prove an issue that no longer affects usage offers little practical value.

So the more accurate conclusion at present is:

With the Codex extension version unchanged, upgrading VS Code from 1.129.1 to 1.130.0 resolved the previous issues of Codex continuously loading, gray screens, and white screens. This further indicates that the problem was likely related to the VS Code core, the Webview runtime environment, or compatibility between the two, but a single root cause cannot yet be confirmed.

7. The Previous Decision to Stop Troubleshooting Proved Correct

On July 20, I had already spent a considerable amount of time dealing with this issue.

If I had insisted on tracing the problem to its lowest level back then, I would likely have needed to continue researching:

The relationships among VS Code, Electron, Chromium, Webview, Service Worker, the Linux desktop environment, and the Codex extension.

At the same time, the Codex CLI remained fully functional.

So I ultimately chose to:

Stop troubleshooting the VS Code panel → Use Codex CLI → Continue advancing the project → Wait for subsequent software updates.

As it turned out, this decision did not hinder subsequent development work.

Over the past few days, I was still able to use Codex in the terminal to continue working on projects like wordpress-ai-excerpt-backfill and WordPress historical article migrations.

Nine days later, a routine VS Code upgrade caused the problem to vanish on its own.

Some development tool issues genuinely do not require tracing to the root cause the first time they are encountered.

As long as a reliable alternative exists, keeping work moving forward is usually more important.

8. Next Time I Encounter a Similar Issue, I Will Check the VS Code Core Version First

After this practical verification, if I encounter the following again:

Codex CLI works, but Codex in VS Code continuously loads, shows a gray screen, or shows a white screen

I will prioritize checking for VS Code updates.

Especially after confirming:

• Codex CLI is normal;
• The account is normal;
• The extension is correctly installed;
• The problem is concentrated in the VS Code Webview;

Instead of immediately performing extensive cache clearing or repeatedly switching extension versions, it is better to first check if a new stable version of VS Code is available.

At least this time, the change that ultimately worked was not updating the Codex extension, but:

VS Code 1.129.1 → 1.130.0

Of course, this does not mean that all future Codex gray screen issues can be resolved by upgrading VS Code.

If the problem persists after upgrading, I can continue analyzing based on Console, Network, and Webview errors in the Developer Tools.

9. Codex CLI Will Still Be Kept

Now that Codex in VS Code is restored, I will prioritize using the Codex panel in VS Code again.

The reason is simple: the graphical interface is more convenient when I need to review project code, read lengthy execution results, and copy content into ChatGPT for further analysis.

However, after this failure, the Codex CLI has proven itself to be a highly reliable backup entry point.

So I will maintain both methods of usage going forward:

VS Code Codex as the primary entry point, and Codex CLI as a backup and for terminal scenarios.

Even if the VS Code panel becomes temporarily unavailable again due to a version issue in the future, as long as the CLI works, development work will not need to stop.

10. Summary

On July 20, Codex in VS Code suddenly experienced continuous loading, gray screens, and white screens.

After troubleshooting, I confirmed that the Codex CLI was normal. I also tried clearing the cache, reinstalling the extension, and rolling back the Codex version, but the issue was never resolved.

So I temporarily stopped troubleshooting and switched to the CLI.

On July 29, I upgraded:

VS Code 1.129.1 to VS Code 1.130.0.

After restarting, the Codex panel returned to normal.

Further inspection revealed:

The Codex extension was actually still the version from a week ago, 26.715.61943, that I had rolled back to; the latest 26.721.41059 had not even been installed yet.

Therefore, this practical verification is more meaningful than a simple “it worked after upgrading.”

With the Codex extension unchanged:

It was abnormal on VS Code 1.129.1, and returned to normal on VS Code 1.130.0.

While this is still insufficient to prove the specific root cause, it further points suspicion toward the VS Code core, the Webview runtime environment, or compatibility between VS Code and the Codex extension.

Now that it has recovered, I do not plan to downgrade to reproduce the issue.

For me, the most valuable lesson from this issue is actually:

When a development tool experiences a relatively low-level compatibility failure but a reliable alternative exists, you can prioritize keeping work moving. Waiting for upstream software updates and then verifying later is sometimes more effective than continuing hours or even days of local troubleshooting.

On July 20, I temporarily gave up on Codex in VS Code.

On July 29, I did not modify the Codex extension; I only upgraded VS Code.

And then, Codex recovered.