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
💡 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.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 ↗

2 Comments

github-actions[bot] contributor · 4 months ago

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

  • #16808
  • #17951
  • #17860

Powered by Codex Action

michaelvd2 · 1 month ago

Related Apple Silicon app-server evidence suggests the eventual fix needs to cover both background discovery egress and prompt-assembly enablement truth.

In an isolated temporary CODEX_HOME using a loopback-only Responses provider, OS-level sandboxing denied every non-loopback outbound socket. Startup still attempted featured/curated plugin discovery endpoints. This made an otherwise offline compaction fixture depend on external plugin warming even though no external plugin data was needed for the test.

Separately, regenerated cache directories for configured-disabled plugins remained legal on disk, but disabled skill IDs could still be exposed during prompt/context assembly. Cache presence is therefore not a safe proxy for enablement.

Suggested owning contract:

  • Filter discovered plugin skills by configured enablement before prompt assembly.
  • Keep generated caches legal without treating them as enabled.
  • Emit a bounded injected plugin/skill ID set or hash so startup cohorts can verify what actually entered context.
  • Provide an authoritative offline fixture mode, or skip featured-plugin warming when discovery is disabled.

Acceptance should include regenerated disabled caches with five fresh prompts injecting zero disabled IDs, enabled plugins unchanged, and an offline fixture making zero external plugin-discovery requests.