openai / openai/codex

[macOS app] Existing chats hang after Wi-Fi SSID switch until restart

Open
#38,314 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app bug connectivity
Dominant language
Rust
Stars
125k
Forks
19.5k
PR merge metrics
PR metrics pending

Description

What version of the Codex App are you using (From “About Codex” dialog)?

26.803.61601 (build 6396); bundled codex-cli 0.147.0-alpha.6.5

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 25.5.0 arm64 arm; macOS 26.5.2 (25F84); MacBook Air (M1, 8 GB)

What issue are you seeing?

After macOS switches between two working Wi-Fi SSIDs, an existing Codex chat often stops processing new messages. The submitted turn remains “thinking” indefinitely, with no assistant output or status change.

Both Wi-Fi networks are stable and internet access continues to work normally in other apps. Codex sometimes recovers after about 2 minutes, but often takes 5+ minutes. Fully quitting and reopening the Codex app restores normal operation.

This happens on every observed SSID switch, whether macOS switches automatically or I switch manually. I have only observed it in existing chats.

What steps can reproduce the bug?
  1. Open an existing Codex chat and confirm new turns work.
  2. Switch from Wi-Fi SSID A to SSID B, manually or through macOS automatic switching. Both networks have working internet.
  3. Submit a new message in the existing chat.
  4. Observe that Codex remains “thinking” with no output or status change, sometimes for 2–5+ minutes.
  5. Quit and reopen Codex; the chat accepts and processes input again.
What is the expected behavior?

Codex should detect the network-interface/SSID transition, reconnect its session transport, and process the new turn promptly without requiring an app restart.

Additional information

Reproduction rate: every observed Wi-Fi SSID switch.

The issue appears isolated to Codex session recovery: connectivity in browsers and other apps remains normal throughout. No error message is shown.

No VPN, custom DNS, DNS filtering, proxy, or other network-routing/changing mechanism is configured on this Mac.

Related: #30777 reports similar behavior with possible Tailscale/DNS involvement; this reproduction occurs without those mechanisms and is consistently observed in existing desktop chats.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the macOS Codex app's existing-chat flow and session transport, then reproduce the documented Wi-Fi SSID switch sequence. Trace how the session responds when connectivity remains available but the network interface changes. Done means existing chats resume processing new turns promptly without requiring an app restart.

Written by the indexing model from the issue text.

Assessment

Tech stack
macos
Domain
desktop, networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.