Codex CLI local Responses provider disconnects when base_url uses localhost; works with 127.0.0.1

Open 💬 2 comments Opened May 8, 2026 by infinitesteps
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.129.0

What subscription do you have?

pro

Which model were you using?

local, Qwen3 Coder Next Local

What platform is your computer?

Darwin 24.6.0 x86_64 i386

What terminal emulator and version are you using (if applicable)?

_No response_

What issue are you seeing?

Summary

Codex CLI local Responses provider fails when base_url uses localhost, but works when changed to 127.0.0.1.

Version

Codex CLI v0.129.0

Platform

macOS / Darwin

Configuration

I am using a custom local provider pointed at a vLLM OpenAI-compatible Responses endpoint:

[model_providers.qwen-local]
name = "Qwen3 Coder Next Local"
base_url = "http://localhost:8000/v1"
wire_api = "responses"

[profiles.local-qwen]
model_provider = "qwen-local"
model = "qwen3-coder-next"
model_reasoning_effort = "medium"
approval_policy = "never"


### What steps can reproduce the bug?

Reproduction
Start a local vLLM server listening on IPv4 localhost / 127.0.0.1:8000.
Configure Codex CLI provider with:
base_url = "http://localhost:8000/v1"
Launch:
codex --profile local-qwen --disable apps --disable plugins -a never
Send a simple prompt:
hello
Actual behavior
Codex TUI repeatedly reconnects and then fails:

Reconnecting... 5/5
Stream disconnected before completion: error sending request for url (http://localhost:8000/v1/responses)
The session log records the turn as completed with last_agent_message: null.

### What is the expected behavior?

Codex should successfully connect to the local provider using localhost, or at least handle IPv6-to-IPv4 fallback reliably.

Workaround
Changing only the provider URL from localhost to 127.0.0.1 fixes the issue:

[model_providers.qwen-local]
name = "Qwen3 Coder Next Local"
base_url = "http://127.0.0.1:8000/v1"
wire_api = "responses"
After this change, the same command works:

codex --profile local-qwen

### Additional information

curl showed that localhost resolves IPv6 first and then IPv4:

Trying [::1]:8000...
connect to ::1 failed
Trying 127.0.0.1:8000...
Connected
So this may be an IPv6 localhost fallback issue in Codex CLI’s HTTP client path, especially for streaming /v1/responses requests.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #19525

Powered by Codex Action

cauldron26 · 2 months ago

I’m seeing a related variant of this on Linux with a custom Responses provider.

Codex CLI: 0.139.0
Binary: x86_64-unknown-linux-musl, static-pie linked
Provider config:
base_url = "http://jetson.local:18080/v1"
wire_api = "responses"
requires_openai_auth = false

Observed:

  • codex exec fails with:

stream disconnected before completion: error sending request for url (http://jetson.local:18080/v1/responses)

  • changing only base_url to "http://192.168.1.23:18080/v1" succeeds.

Host checks:

  • getent hosts jetson.local -> 192.168.1.23
  • python socket.getaddrinfo("jetson.local", 18080) -> 192.168.1.23
  • curl http://jetson.local:18080/health -> 200
  • ssh jetson.local works

strace shows Codex querying 127.0.0.53 for A/AAAA records for jetson.local, receiving no usable answers, and never attempting a TCP connect to 192.168.1.23:18080.