Codex-cli lag on every prompt when "background" apps/plugins discovery requests not disabled

Open 💬 2 comments Opened Apr 20, 2026 by andrew-adamson-proteros

What version of Codex CLI is running?

codex-cli 0.121.0

What subscription do you have?

pro

Which model were you using?

gpt-5.4

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

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

Powershell 7

What issue are you seeing?

Normal CLI responses stall for ~60-90 seconds while Codex performs
background apps/plugins discovery requests that fail behind Cloudflare.
The actual tool or prompt work is fast; the delay is dominated by these
background lookups.

What steps can reproduce the bug?

Uploaded thread: 019da62a-5035-7b70-8505-6d021c0bd416

  1. Start a fresh Codex CLI session on Windows with the default feature

set, leaving apps and plugins enabled.

  1. Use a trivial prompt or command that uses a local MCP server such as ooo help or other short

requests that should return quickly. ooo help is to use the ouroboros skill.

  1. Observe that each response can take roughly 60-90 seconds even when the

actual work is trivial.

  1. Check ~/.codex/log/codex-tui.log.
  2. The log shows repeated background discovery failures like:
  • failed to load discoverable tool suggestions
  • failed to warm featured plugin ids cache
  • startup remote plugin sync failed
  1. The failing requests are to endpoints such as:
  • /backend-api//connectors/directory/list?

tier=categorized&external_logos=true

  • /backend-api/plugins/list
  • /backend-api/plugins/featured
  1. Those requests return 403 Forbidden plus a Cloudflare HTML challenge

page (Enable JavaScript and cookies to continue).

  1. Add this to ~/.codex/config.toml:

[features]
apps = false
plugins = false

  1. Restart Codex CLI and repeat the same prompt.
  2. Latency drops dramatically. In my case it went from over a minute to

about 7 seconds.

What is the expected behavior?

Background discovery for apps/plugins/connectors should not materially
delay normal CLI responses. If those lookups fail, Codex should fail fast,
cache the failure, or continue without blocking the user-visible turn.

Additional information

  • This was observed in uploaded thread: 019da62a-5035-7b70-8505-

6d021c0bd416000

  • The actual Ouroboros MCP tool call was fast; the delay was on the Codex

side.

  • The problem appears tied specifically to the apps and plugins feature

paths.

  • The current workaround is:

[features]
apps = false
plugins = false

  • It would be helpful if:
  • these lookups were fully async/non-blocking
  • failures were cached
  • CLI did not depend on browser-style JS/cookie-protected endpoints

for background discovery

  • there were documented config flags for disabling this behavior

I hope this hasn't been chewing tokens unnecessarily.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗