DEV Community

Josué Sevahc
Josué Sevahc

Posted on

Codex in VS Code would not load on Linux Mint: plugin sync failure, broken IPv6 (solution)

#linux #vscode #openai #ai

Short description / summary

The Codex extension interface remained completely blank in VS Code, while the logs showed failures when synchronizing plugins with ChatGPT and GitHub. This is the complete diagnosis on Linux Mint and the steps that restored the interface.

Tags 

#linux, #vscode, #openai, #debugging, #Codex, #Linux Mint, #VS Code, #OpenAI, #Plugins, #IPv6, #GitHub, #NetworkManager, #Troubleshooting
Enter fullscreen mode Exit fullscreen mode

Codex in VS Code would not load on Linux Mint: plugin sync failure, broken IPv6, and the solution

Recently, the Codex extension interface stopped loading in my VS Code installation on Linux Mint.

The main visual symptom was not a clear error message: the Codex panel simply remained blank. The extension appeared to be installed, the tab opened, but the main controls and chat area did not load.

After checking the extension logs, I found failures related to synchronizing the Codex plugin catalog with ChatGPT services and GitHub.

This post documents the diagnosis, the tests performed, and the sequence that restored the interface.

Environment

The problem occurred in the following environment:

  • Linux Mint 22.3
  • VS Code
  • Official Codex/OpenAI extension
  • Codex CLI installed locally
  • Connection with no proxy configured
  • Functional IPv4
  • IPv6 available on the system, but without functional external connectivity

Visual symptom

When opening the Codex tab in VS Code, the interface remained almost completely blank.

The following elements did not appear normally:

  • conversation history;
  • functional model selector;
  • usable prompt field;
  • complete session controls;
  • clear error messages in the interface itself.

The only way to understand what was happening was to open the extension logs.

Initial messages found

The first logs indicated a failure when accessing the remote plugin catalog:

WARN codex_core_plugins::manager:
failed to load recommended plugins

failed to send remote plugin catalog request to:
https://chatgpt.com/backend-api/ps/plugins/suggested
Enter fullscreen mode Exit fullscreen mode

Similar errors also appeared while warming the caches:

failed to warm featured plugin ids cache

failed to warm remote plugin catalog cache

failed to refresh remote installed plugins cache
Enter fullscreen mode Exit fullscreen mode

The failing requests included endpoints such as:

https://chatgpt.com/backend-api/plugins/featured
https://chatgpt.com/backend-api/ps/plugins/list
https://chatgpt.com/backend-api/ps/plugins/installed
Enter fullscreen mode Exit fullscreen mode

Initially, this appeared to be only a failure in the ChatGPT remote plugin catalog.

However, after disabling the remote catalog, a second and more specific message appeared.

Failure while synchronizing curated plugins from GitHub

The next log showed that Codex was also trying to synchronize a curated plugin repository from GitHub:

WARN codex_core_plugins::startup_sync:

GitHub HTTP sync failed for curated plugin sync

failed to get curated plugins repository from:
https://api.github.com/repos/openai/plugins
Enter fullscreen mode Exit fullscreen mode

The Git fallback also failed:

git ls-remote curated plugins repo failed

fatal: unable to access
'https://github.com/openai/plugins.git/':

Could not resolve host: github.com
Enter fullscreen mode Exit fullscreen mode

Codex also reported that a local snapshot already existed:

skipping export archive fallback because
a local curated plugins snapshot already exists
Enter fullscreen mode Exit fullscreen mode

At this point, the situation was as follows:

  1. the interface did not load;
  2. the ChatGPT remote catalog failed;
  3. the curated GitHub repository was not synchronized;
  4. there were local temporary files related to plugins;
  5. the local Codex process remained active even after reloading the VS Code window.

Initial network diagnosis

To distinguish a general internet connection issue from a Codex-specific failure, I tested the ChatGPT endpoint directly.

IPv4 test 

curl -4 -sS -o /dev/null \
  -w 'HTTP IPv4: %{http_code}\n' \
  --connect-timeout 15 \
  'https://chatgpt.com/backend-api/plugins/featured?platform=codex'
Enter fullscreen mode Exit fullscreen mode

Result:

HTTP IPv4: 401
Enter fullscreen mode Exit fullscreen mode

The 401 response was acceptable for this test.

The purpose was not to access authenticated content, but to confirm that:

  • the domain was resolved;
  • the TCP connection was established;
  • TLS worked;
  • the server responded.

Therefore, IPv4 was operational.

IPv6 test 

curl -6 -sS -o /dev/null \
  -w 'HTTP IPv6: %{http_code}\n' \
  --connect-timeout 15 \
  'https://chatgpt.com/backend-api/plugins/featured?platform=codex'
Enter fullscreen mode Exit fullscreen mode

Result:

curl: (28) Failed to connect to chatgpt.com port 443
after 15002 ms: Timeout was reached

HTTP IPv6: 000
Enter fullscreen mode Exit fullscreen mode

This confirmed a second problem: the system had IPv6 configured or advertised, but the IPv6 route was not functional.

Applications that tried IPv6 before IPv4 could wait for the timeout before continuing.

Proxy verification

I also checked whether VS Code or Codex were inheriting proxy environment variables:

env | grep -iE '^(http|https|all|no)_proxy='
Enter fullscreen mode Exit fullscreen mode

The command returned no values.

Therefore, there was no evidence of:

  • HTTP_PROXY;
  • HTTPS_PROXY;
  • ALL_PROXY;
  • NO_PROXY.

A proxy was ruled out as the cause.

Solution that restored the interface

The recovery involved two fronts:

  1. temporarily disabling the plugin subsystem;
  2. completely terminating Codex and VS Code, while removing temporary synchronization residues.

Using only Developer: Reload Window was not sufficient.

1. Disable plugins in Codex

I opened the global configuration file:

code ~/.codex/config.toml
Enter fullscreen mode Exit fullscreen mode

It would also be possible to use:

nano ~/.codex/config.toml
Enter fullscreen mode Exit fullscreen mode

In the [features] section, I added:

[features]
plugins = false
remote_plugin = false
Enter fullscreen mode Exit fullscreen mode

If the [features] section already exists, only the two properties should be added:

plugins = false
remote_plugin = false
Enter fullscreen mode Exit fullscreen mode

There must not be two [features] sections in the same TOML file.

The complete configuration was structurally as follows:

[features]
plugins = false
remote_plugin = false
Enter fullscreen mode Exit fullscreen mode

This change temporarily disables:

  • the remote plugin catalog;
  • general plugin loading and synchronization.

The Codex core remains usable, but features provided by plugins remain unavailable while the flags are disabled.

2. Completely terminate Codex and VS Code

I closed the VS Code windows and terminated the remaining processes:

pkill -f codex || true
Enter fullscreen mode Exit fullscreen mode 
pkill -f '/usr/share/code/code' || true
Enter fullscreen mode Exit fullscreen mode

The path in the second command may vary if VS Code was installed through Snap, Flatpak, or another method.

The goal was to ensure that the app-server and the extension process did not remain active in the background.

3. Remove temporary plugin clones

Next, I removed only the temporary plugin clone directories:

find ~/.codex/.tmp \
  -maxdepth 1 \
  -type d \
  -name 'plugins-clone-*' \
  -print \
  -exec rm -rf -- {} + \
  2>/dev/null
Enter fullscreen mode Exit fullscreen mode

This command is restricted to directories named:

plugins-clone-*
Enter fullscreen mode Exit fullscreen mode

inside:

~/.codex/.tmp
Enter fullscreen mode Exit fullscreen mode

I did not delete the entire ~/.codex directory.

This was important because ~/.codex may also contain:

  • configurations;
  • authentication;
  • history;
  • sessions;
  • still-valid caches;
  • MCP definitions.

4. Open VS Code again

After the cleanup, I started VS Code again:

code
Enter fullscreen mode Exit fullscreen mode

At this point, the Codex interface loaded normally.

The following elements appeared again:

  • chat area;
  • prompt field;
  • model selector;
  • reasoning level selector;
  • session controls;
  • workspace access options.

Therefore, the visual recovery happened after the combination of:

  • disabled plugins;
  • complete termination of the processes;
  • removal of temporary clones;
  • restarting VS Code.

Preventive correction for broken IPv6

Although the interface had already returned, the previous test showed that the connection's IPv6 route was unavailable.

To prevent applications from trying a broken IPv6 route before using IPv4, I configured Linux to prioritize IPv4.

I ran:

grep -q '^precedence ::ffff:0:0/96  100$' /etc/gai.conf \
  || echo 'precedence ::ffff:0:0/96  100' \
  | sudo tee -a /etc/gai.conf
Enter fullscreen mode Exit fullscreen mode

The following line was added:

precedence ::ffff:0:0/96  100
Enter fullscreen mode Exit fullscreen mode

This configuration does not remove IPv6 from the machine.

It changes the priority used by the system resolver, favoring IPv4-mapped addresses when both IPv4 and IPv6 are available.

I then restarted NetworkManager:

sudo systemctl restart NetworkManager
Enter fullscreen mode Exit fullscreen mode

IPv4 DNS validation

I verified the resolution of the involved services:

getent ahostsv4 chatgpt.com
Enter fullscreen mode Exit fullscreen mode 
getent ahostsv4 github.com
Enter fullscreen mode Exit fullscreen mode 
getent ahostsv4 api.github.com
Enter fullscreen mode Exit fullscreen mode

All three commands returned IPv4 addresses.

Copying specific IP addresses into static configurations is not recommended, because those addresses may change.

GitHub validation

I tested the GitHub API:

curl -4 -I --connect-timeout 15 https://api.github.com
Enter fullscreen mode Exit fullscreen mode

Main result:

HTTP/2 200
Enter fullscreen mode Exit fullscreen mode

I then tested the main website:

curl -4 -I --connect-timeout 15 https://github.com
Enter fullscreen mode Exit fullscreen mode

Main result:

HTTP/2 200
Enter fullscreen mode Exit fullscreen mode

Finally, I validated the exact Git operation that had failed in the logs:

git ls-remote https://github.com/openai/plugins.git HEAD
Enter fullscreen mode Exit fullscreen mode

The command returned:

<commit-hash>    HEAD
Enter fullscreen mode Exit fullscreen mode

This confirmed that:

  • the github.com domain was resolving;
  • HTTPS was functional;
  • Git could query the repository;
  • the ls-remote operation was no longer blocked.

What was the actual cause?

It was not possible to prove a single, isolated cause.

The evidence pointed to a combination of factors:

1. Plugin synchronization during startup

Codex attempted to load:

  • the remote catalog;
  • remotely installed plugins;
  • featured plugins;
  • the curated repository hosted on GitHub.

These operations were failing during startup.

2. Local processes still running

Reloading only the VS Code window did not completely restart the entire local Codex layer.

Explicitly terminating the processes was necessary.

3. Temporary residues

There were directories related to temporary plugin clones.

The removal was limited to the plugins-clone-* directories.

4. IPv6 without connectivity

IPv4 worked, but IPv6 ended in a timeout.

This could introduce delays and failures in applications that prioritized IPv6.

5. Apparently transient GitHub resolution failure

The log recorded:

Could not resolve host: github.com
Enter fullscreen mode Exit fullscreen mode

Later, the tests with getent, curl, and git ls-remote worked.

Therefore, it would not be correct to state that there was a permanent DNS failure.

The failure may have been:

  • transient;
  • related to the previous process;
  • aggravated by the IPv6 route;
  • associated with the plugin synchronization attempt.

What was not necessary

In this case, it was not necessary to:

  • delete the entire ~/.codex directory;
  • reinstall Linux;
  • reinstall certificates;
  • change DNS servers;
  • remove the extension;
  • log in to the OpenAI account again;
  • delete MCP configurations;
  • reinstall VS Code.

Those actions would have been more invasive and could have removed valid configurations without addressing the actual cause.

How to re-enable plugins later

Disabling plugins should be treated as a controlled workaround.

After a Codex update or once the network is stable, the features can be tested again, one flag at a time.

First, test only the remote catalog:

[features]
plugins = false
remote_plugin = true
Enter fullscreen mode Exit fullscreen mode

After completely restarting Codex and VS Code, check the logs.

If it remains stable, test the complete subsystem:

[features]
plugins = true
remote_plugin = true
Enter fullscreen mode Exit fullscreen mode

If the interface becomes blank again, return to:

[features]
plugins = false
remote_plugin = false
Enter fullscreen mode Exit fullscreen mode

This strategy helps identify whether the problem is:

  • in the remote catalog;
  • in the curated repository;
  • in a specific plugin;
  • or in the general synchronization process.

Precautions when publishing logs

Commands such as:

curl -I
Enter fullscreen mode Exit fullscreen mode

may return headers such as:

set-cookie
authorization
x-github-request-id
Enter fullscreen mode Exit fullscreen mode

Before publishing logs in blogs, forums, or issues, remove:

  • cookies;
  • tokens;
  • authentication headers;
  • email addresses;
  • unnecessary usernames;
  • private paths;
  • session IDs;
  • signed URLs.

For public documentation, showing the following is usually sufficient:

HTTP/2 200
Enter fullscreen mode Exit fullscreen mode

or the specific error message.

Solution summary

The sequence that resolved the problem was:

code ~/.codex/config.toml
Enter fullscreen mode Exit fullscreen mode

Add:

[features]
plugins = false
remote_plugin = false
Enter fullscreen mode Exit fullscreen mode

Terminate the processes:

pkill -f codex || true
pkill -f '/usr/share/code/code' || true
Enter fullscreen mode Exit fullscreen mode

Remove temporary clones:

find ~/.codex/.tmp \
  -maxdepth 1 \
  -type d \
  -name 'plugins-clone-*' \
  -print \
  -exec rm -rf -- {} + \
  2>/dev/null
Enter fullscreen mode Exit fullscreen mode

Open VS Code again:

code
Enter fullscreen mode Exit fullscreen mode

Then, as a network stabilization measure:

grep -q '^precedence ::ffff:0:0/96  100$' /etc/gai.conf \
  || echo 'precedence ::ffff:0:0/96  100' \
  | sudo tee -a /etc/gai.conf
Enter fullscreen mode Exit fullscreen mode 
sudo systemctl restart NetworkManager
Enter fullscreen mode Exit fullscreen mode

Validate:

getent ahostsv4 chatgpt.com
getent ahostsv4 github.com
getent ahostsv4 api.github.com
Enter fullscreen mode Exit fullscreen mode 
curl -4 -I --connect-timeout 15 https://api.github.com
curl -4 -I --connect-timeout 15 https://github.com
Enter fullscreen mode Exit fullscreen mode 
git ls-remote https://github.com/openai/plugins.git HEAD
Enter fullscreen mode Exit fullscreen mode

Conclusion

The most misleading aspect of this problem was visual.

The extension did not display an explicit failure screen: the interface simply did not load.

The logs showed that Codex was failing during plugin synchronization operations. Recovery required temporarily disabling that layer, completely terminating the local processes, and removing temporary clones.

Separately, the tests revealed a broken IPv6 route, while IPv4 remained functional. Prioritizing IPv4 reduced the risk of further timeouts.

The main lesson was not to treat a blank interface as a simple VS Code visual failure. In this case, the problem was in the startup flow of the local Codex process and in the network dependencies triggered during plugin synchronization.

Technical references

The official documentation confirms that the VS Code extension is powered by the Codex app-server and that the CLI and extension share the ~/.codex/config.toml configuration. The configuration reference also documents features.remote_plugin, while the official repository records recent problems related to plugin synchronization and temporary plugin directories.

Top comments (0)