What version of Codex CLI is running?

codex-cli 0.120.0

What subscription do you have?

OpenAI API

Which model were you using?

gpt-5.4

What platform is your computer?

Windows 11 host + WSL2 Ubuntu 24.04.4 LTS (Linux 6.6.87.2-microsoft-standard-WSL2 x86_64)

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

bash inside WSL2

What issue are you seeing?

Interactive Codex startup in the terminal is consistently slow because startup spends a fixed ~15 seconds in:

session_init.auth_mcp ... time.idle=15.0s

The current setup uses a custom localhost model provider with:

model_provider = "custom"
model = "gpt-5.4"

[model_providers.custom]
name = "custom"
wire_api = "responses"
requires_openai_auth = true
base_url = "http://localhost:8317/v1"

Auth mode is API key login:

codex login status
Logged in using an API key

Observed behavior:

• codex --help is fast
• interactive codex startup is slow
• recent real startup timing was:

  real    0m21.630s
  user    0m2.548s
  sys     0m0.720s
  

• the dominant fixed delay in the log is still session_init.auth_mcp ... time.idle=15.0s

Relevant recent log excerpt:

2026-04-12T10:45:56.162921Z  INFO ... session_init.auth_mcp ... new
2026-04-12T10:46:11.179440Z  INFO ... session_init.auth_mcp ... close time.busy=13.7ms time.idle=15.0s
2026-04-12T10:46:11.237362Z  INFO ... session_init: codex_core::codex: close time.busy=42.9ms time.idle=15.0s

There are also plugin-sync warnings during startup:

starting remote plugin sync
chatgpt authentication required to sync remote plugins; api key auth is not supported
failed to warm featured plugin ids cache ... 401 Unauthorized

However, those requests fail quickly and do not appear to explain the fixed 15s delay.

I also ruled out a few nearby hypotheses locally:

• deleting the VS Code Codex extension did not remove the 15s auth_mcp delay
• changing requires_openai_auth = false as a temporary test did not eliminate the same 15s auth_mcp delay in my local runs
• previous database is locked symptoms appear to have been a side issue, not the current dominant startup blocker

This looks related to the general auth_mcp startup-latency class of bugs, but this reproduction is specifically about:

• custom localhost provider
• requires_openai_auth = true
• API-key login mode
• fixed ~15s terminal startup delay on WSL2

What steps can reproduce the bug?

1. Configure a custom localhost model provider in ~/.codex/config.toml:

model_provider = "custom"
model = "gpt-5.4"
model_reasoning_effort = "high"
disable_response_storage = true

[model_providers.custom]
name = "custom"
wire_api = "responses"
requires_openai_auth = true
base_url = "http://localhost:8317/v1"

2. Log in with API key mode:

codex login --with-api-key

3. Start Codex interactively from WSL2:

time codex

4. Inspect ~/.codex/log/codex-tui.log

5. Observe that startup contains:

session_init.auth_mcp ... time.idle=15.0s

What is the expected behavior?

Interactive startup should not incur a fixed ~15s delay in session_init.auth_mcp.

If this auth path is required, it should either:

• complete quickly for API-key login mode, or
• be skipped when it is not needed for the active provider/auth combination.

Additional information

A few more details that may help narrow scope:

• This is in WSL2, but the current fixed 15s delay persists even after removing the VS Code extension, so it does not look like an extension-sharing issue anymore.
• The plugin-sync warnings suggest a mismatch between ChatGPT-only remote plugin sync and API-key login mode, but those warnings return quickly and seem secondary.
• This may be distinct from the already-fixed disabled-MCP probing bug, because the 15s delay here still occurs in an active custom-provider setup and shows up before session_init.mcp_manager_init in the logs.