Codex Reconnecting Loop on Mac: Fixed by Clearing the DNS Cache

Codex occasionally stopped connecting on my Mac and kept displaying Reconnecting.... It happened in both the CLI and the desktop app. Restarting Codex did not help, but the connection eventually recovered on its own.

After this happened four times, I investigated and traced the problem to a negative DNS response cached by macOS's mDNSResponder.

Clearing the DNS cache restored the connection

On my machine, running this command restored the connection:

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

This runs two commands to clear caches:

• dscacheutil -flushcache clears the cache maintained by macOS's Directory Service. The -flushcache option tells it to empty that cache.
• killall -HUP mDNSResponder sends a HUP signal to mDNSResponder, which handles DNS queries and caches their responses. When it receives this signal, it clears its DNS cache and restarts queries. This behavior is also visible in Apple's published source code.

Clearing mDNSResponder's cache restored the connection on my machine.

If mDNSResponder's cache is the cause, sudo killall -HUP mDNSResponder alone should be sufficient. However, I have not verified recovery using that command on its own.

Codex kept reconnecting

While the connection was failing, Codex repeatedly displayed:

Reconnecting...

During that time:

• Browsers and other apps could still connect.
• Codex could not connect, even after retries or an app restart.
• The connection recovered after waiting anywhere from tens of seconds to tens of minutes.

A similar issue was reported in the openai/codex GitHub repository: Codex could not reconnect after a Wi-Fi switch, then recovered after some time, with logs suggesting DNS resolution failures. The issue remains open without a confirmed cause.

Only chatgpt.com failed to resolve

When I checked name resolution, chatgpt.com failed, while www.chatgpt.com and api.openai.com resolved successfully.

Codex connects to chatgpt.com/backend-api/.... Because that domain failed to resolve, Codex could not connect even though other websites remained accessible.

The result depended on how I queried DNS

While the connection was failing, this command returned No Such Record in about 1 ms:

dns-sd -q chatgpt.com A

This command resolves the name through mDNSResponder. Querying the DNS servers directly, however, returned valid responses:

dig chatgpt.com @172.20.10.1      # iPhone Personal Hotspot
dig chatgpt.com @100.100.100.100  # Tailscale MagicDNS
# Both returned valid A records

curl and ping also failed to resolve the name within 1–3 ms. The DNS servers returned valid responses, but resolution through mDNSResponder failed. This led me to suspect a cached negative response in mDNSResponder.

A negative response remained cached after switching networks

The failures occurred after switching networks, such as moving between Wi-Fi and an iPhone's Personal Hotspot.

I suspect a temporary negative response was cached during the switch and remained there after connectivity was restored. I have not confirmed which DNS server returned which response during the switch.

The eventual recovery may also be explained by the cache's TTL (time to live) expiring. In one instance, I confirmed that the connection recovered without any intervention.

If sudo is unavailable

On my machine, waiting anywhere from tens of seconds to tens of minutes restored the connection.

Another option is to run a local CONNECT proxy that queries DNS servers directly, then start Codex with HTTPS_PROXY configured to use it. This allows name resolution without going through mDNSResponder.

Clearing the cache automatically when networks change

After four occurrences, I automated cache clearing with a LaunchDaemon. It watches /etc/resolv.conf, which is updated when DNS settings change. A network switch that does not change those settings may not trigger it.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>local.dnsflush</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/sh</string>
        <string>-c</string>
        <string>sleep 2; dscacheutil -flushcache; killall -HUP mDNSResponder; sleep 10; dscacheutil -flushcache; killall -HUP mDNSResponder</string>
    </array>
    <key>WatchPaths</key>
    <array>
        <string>/etc/resolv.conf</string>
    </array>
</dict>
</plist>

A negative response could be cached again if another query runs while the network is still switching. To account for that, I configured two flushes: one after 2 seconds and another after 12 seconds.

Save the configuration as local.dnsflush.plist and register it with the commands below. The file must be owned by root and must not be writable by the group or other users.

sudo cp local.dnsflush.plist /Library/LaunchDaemons/
sudo chown root:wheel /Library/LaunchDaemons/local.dnsflush.plist
sudo launchctl bootstrap system /Library/LaunchDaemons/local.dnsflush.plist

About a week after setting this up, the same problem had not recurred.

Summary

In this case, the reconnecting loop was caused by a DNS response that remained cached after a network switch. Clearing mDNSResponder's cache with sudo killall -HUP mDNSResponder restored the connection.