VS Code Codex extension DNS failures: Could not resolve any host name

Also experiencing this issue, VS plugin 26.504.30809 cli 0.181.0

Same here with the latest version of the plugin

Same. Started last Friday.

Seeing also the same. Do any of you have network extensions in place from a corporate VPN client or is this just on personal macs?

Seeing also the same. Do any of you have network extensions in place from a corporate VPN client or is this just on personal macs?

it doesn't seem to matter. I initially thought it was our corporate network which I connect to using a hardware network device (not any extension), then I tried it with just my personal internet (with and without a software vpn client). All configurations resulted in the problem as soon as I sent a message to codex through the VSCode extension. Using terminal seems to work fine.

I'm experiencing this on my corporate Mac laptop. When it happens, all DNS queries (in terminal, browser, etc) just hang for several minutes. I suspect it might be related to an installed network inspecting extension. My workaround has been to use the Codex CLI, which doesn't trigger this issue.

> Seeing also the same. Do any of you have network extensions in place from a corporate VPN client or is this just on personal macs? it doesn't seem to matter. I initially thought it was our corporate network which I connect to using a hardware network device (not any extension), then I tried it with just my personal internet (with and without a software vpn client). All configurations resulted in the problem as soon as I sent a message to codex through the VSCode extension. Using terminal seems to work fine.

That's interesting. I'm able to consistently reproduce it using the Secure Client with the ZTA module. However, if I strip it back to just using AnyConnect and Umbrella I can't consistently reproduce the issue. I just wondered if there was a correlation to whether to any network extensions at all on macOS and the use of Codex extension would trigger the scenario.

I'm experiencing this on my corporate Mac laptop. When it happens, all DNS queries (in terminal, browser, etc) just hang for several minutes. I suspect it might be related to an installed network inspecting extension. My workaround has been to use the Codex CLI, which doesn't trigger this issue.

Equally I've noticed that using the Codex app directly doesn't cause the issue either. I did a bit of a dig and may seem that the extensions won't necessarily to any proxy or network handling should I say to VScode it itself. It's interesting to why / how this behaviour has only just appeared within the last week or so.

I think I managed to isolate it to apps feature, disabling it seems to help:

codex features disable apps

or through ~/.codex/config.toml:

[features]
apps = false

Okay, I did a little bit more digging around (with Codex CLI obviously), and prepared somewhat proper technical report.
I don't think that anyone from OpenAI will see this and the extension does not seem to be open source, so not sure if anyone would even fix this, but I'll post it anyway.

Problem statement

With the apps feature enabled, messaging Codex through VS Code extension can completely break DNS/network resolution on a corporate laptop for a couple of minutes. While the issue is active, the browser, terminal commands, and other network clients also fail to resolve/connect. The only recovery is waiting several minutes or rebooting the laptop.

This makes the Codex VS Code extension unusable.

This may not reproduce on every laptop/network, but it consistently reproduces on several corporate laptops. The standalone Codex CLI works normally.

Investigation summary

Using Codex CLI to inspect local extension logs and the installed extension bundle, I narrowed the trigger to the apps feature.

Workaround:

codex features disable apps

With apps=false, the DNS/network failure goes away.

With apps=true, opening/reloading VS Code with the Codex extension triggers a large burst of failed connector-logo fetches.

Log path:

~/Library/Application Support/Code/logs/*/window*/exthost/openai.chatgpt/Codex.log

Example failed run:

Error fetching: 1353
/aip/connectors/.../logo: 1334
TypeError: fetch failed: 1353
unique connector logo URLs: 1334
light logos: 991
dark logos: 343

Example failing URLs:

/aip/connectors/asdk_app_.../logo?theme=light
/aip/connectors/connector_.../logo?theme=dark

During the same window, system-wide networking/DNS becomes unreliable, affecting browser and terminal as well.

Local bundle finding

The extension is bundled/compiled/minified. The relevant file in my installed extension was:

~/.vscode/extensions/openai.chatgpt-26.513.21555-darwin-arm64/webview/assets/apps-queries-WOENo1q8.js

The relevant logic, deminified for readability, appears to:

1. Parse connectors://... logo URLs from the app catalog.
2. Convert them into connector/theme pairs.
3. Fetch every connector logo via /aip/connectors/<id>/logo?theme=<theme>.
4. Use Promise.all(...) over the whole connector list.

Equivalent deminified snippet:

async function fetchLogo({ connectorId, theme }) {
  const response = await api.get(
    `/aip/connectors/${encodeURIComponent(connectorId)}/logo?theme=${theme}`
  );

  return `data:${response.body.contentType};base64,${response.body.base64}`;
}

async function loadConnectorLogos(connectorLogoRequests) {
  const results = await Promise.all(
    connectorLogoRequests.map(async (request) => {
      try {
        return {
          cacheKey: cacheKey(request),
          dataUrl: await fetchLogo(request),
        };
      } catch {
        return null;
      }
    })
  );

  const map = new Map();
  results.forEach((result) => {
    if (result != null) {
      map.set(result.cacheKey, result.dataUrl);
    }
  });

  return map;
}

In my failing run, this produced 1334 unique logo requests.

Diagnostic patch 1: disable logo hydration only

I locally patched the connector-logo loader to return an empty map:

async function loadConnectorLogos(connectorLogoRequests) {
  return new Map();
}

Result with apps=true:

fetch=0 connector=0 typeerror=0 dns=0

Codex VS Code extension worked, and the laptop networking/DNS did not break.

Diagnostic patch 2: bounded concurrency

Then I replaced the no-op with bounded concurrency, keeping logo fetching enabled but limiting it to 4 concurrent requests:

async function loadConnectorLogos(connectorLogoRequests) {
  const map = new Map();
  let next = 0;
  const concurrency = 4;

  async function worker() {
    for (;;) {
      const index = next++;
      if (index >= connectorLogoRequests.length) return;

      const request = connectorLogoRequests[index];

      try {
        map.set(cacheKey(request), await fetchLogo(request));
      } catch {
        // Preserve current behavior: logo failure is non-fatal.
      }
    }
  }

  await Promise.all(
    Array.from(
      { length: Math.min(concurrency, connectorLogoRequests.length) },
      worker
    )
  );

  return map;
}

Result with apps=true:

fetch=0 connector=0 typeerror=0 dns=0

Multiple fresh logs stayed clean, and system-wide DNS/networking did not break.

Hypothesis

The apps feature eagerly hydrates the full connector/app logo catalog at startup or early extension activation. On some environments, the unbounded Promise.all(...) fan-out over ~1300 logo requests appears to overload or destabilize networking/DNS at the system level, not just inside VS Code.

The issue does not appear to be:

• The Codex CLI binary.
• The entire apps feature.
• A single bad connector.

It appears specifically related to eager/bulk connector-logo hydration.

Suggested fix

The product likely does not need to disable app connectors. A narrower fix should be enough:

• Do not eagerly fetch every connector logo at startup.
• Lazy-load only visible logos.
• Add bounded concurrency for logo fetches.
• Optionally split connector logo hydration behind a separate feature flag/kill switch, so users can keep app connectors enabled even if logo fetching is problematic.

The strongest local evidence is that apps=true works when only connector-logo hydration is no-op'd or concurrency-limited.

@etraut-openai you seem to be active in issues labeled extension and bug, will someone be able to take a look?

I tried to provide as much information as possible here, though full disclosure - most of the work of reading the logs and minified code was done by Codex.

I just update the extension to 26.519.32039 and the issue is gone.

I'm using 26.519.32039 and I have still encountered this issue

@thsands-te have you tried this fix?

https://github.com/openai/codex/issues/21218#issuecomment-4462467903

Seems to work just fine for me and a couple of my colleagues for the last 2 weeks.