›_ Codex Issues
Codex Issues / #30399

Make Codex startup, MCP, and subagent orchestration non-blocking and observable for multi-machine workflows

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

Make Codex startup, MCP, and subagent orchestration non-blocking and observable for multi-machine workflows

Issue URL: https://github.com/openai/codex/issues/30399
Retrieval / posting date: 2026-06-28 JST

Summary

I am opening this as a synthesis / discussion issue rather than another single "Codex is slow" report.

There are several already-open issues that look related from the perspective of a multi-machine, multi-agent developer workflow:

  • #16335 - TUI/CLI startup performance regression
  • #18693 - large local conversation histories can collapse Desktop performance
  • #22037 - /resume picker can block on global rollout scans
  • #23608 - multi-agent orchestration regressions / insufficient dispatch
  • #24397 - startup blocks on MCP/App connector initialization
  • #25715 / #27240 - Windows + WSL Codex App latency
  • #28640 / #29321 / #29376 - slow or stale MCP startup can block first turns or new conversations
  • #19197 / #24389 / #29057 - subagent lifecycle, shutdown, and resource exhaustion issues

My working environment is not a single-machine happy path:

  • macOS and Windows/WSL development machines
  • Codex Desktop and Codex CLI
  • Claude Code, Cursor / Copilot-style IDE assistance, and other review agents
  • GitHub-based review / issue workflows
  • Google Drive and browser/app connectors when explicitly scoped
  • local skills / AGENTS.md workflows that intentionally split planning, implementation, review, and verification across bounded agents

This kind of setup makes performance failures harder to diagnose because startup, session history, MCP discovery, connector initialization, subagent policy, remote/WSL handoff, and model streaming can all look like the same symptom: "Codex is slow" or "Codex got stuck".

What I think would help

Codex would be much easier to optimize and operate if these paths were treated as separate dependency classes with explicit timing and degradation behavior.

Concrete asks:

  1. First-keystroke / first-turn path should not block on nonessential work.
  • local session history scans
  • MCP tool discovery for optional servers
  • rate-limit reads
  • app-server bootstrap details that can be loaded later
  • connector inventory that is not required for the current turn
  1. MCP servers should have required vs optional classification.
  • required: may block the turn with a clear diagnostic
  • optional cached: use last known manifest with freshness marker
  • optional unavailable: start the thread and show a warning
  1. Subagents need explicit lifecycle and bounded orchestration controls.
  • deterministic spawn authorization when AGENTS.md / selected skills require bounded subagents
  • cwd/worktree/profile/model/MCP scoping for workers
  • parent-visible timeout, cancel, close, and stale-worker diagnostics
  • no indefinite wait on spawn, wait, or close paths
  1. Codex should emit a run record that separates latency sources.

Suggested fields:

  • surface: Desktop / CLI / IDE / remote
  • OS and shell class: macOS / Windows / WSL / Linux
  • Codex version
  • first paint / first keystroke / first model request timings
  • session-history scan time and count
  • MCP server startup time, manifest source, timeout, required/optional status
  • subagent spawn/wait/close timings and terminal state
  • model/profile actually used by parent and workers
  • whether degradation was cached, skipped, blocking, or failed
  1. Multi-agent workflows should have a product-level performance mode.

Example shape:

  • planner can use a high-capability model
  • workers can use fast/cheap profiles
  • verifier can use a stable middle profile
  • each child records its effective model/provider/profile/tool surface
  • parent can continue while optional workers or MCP servers initialize

Local validation I ran before posting

I created a local, read-only control board for this workflow and verified:

  • Codex CLI is installed and callable
  • Claude Code, Oracle CLI, GitHub CLI, and selected local skills are discoverable
  • GitHub read access works
  • agmsg identity and team membership are available for local message passing
  • external writes remain gated
  • current operational policy limits fanout to bounded subagents, not literal unlimited workers

I am intentionally not attaching logs, hostnames, local paths, or private connector details here. The useful part for this issue is the dependency model and acceptance-test shape, not private machine inventory.

Acceptance-test shape

A regression test for this class of workflow could configure:

  1. one fast MCP server;
  2. one optional MCP server that times out;
  3. a large local session history;
  4. a Windows/WSL or remote shell environment;
  5. a prompt that authorizes bounded subagents through AGENTS.md / selected workflow instructions.

Expected behavior:

  • the new thread becomes usable before the optional MCP timeout expires;
  • the first user input is not delayed by a full session-history scan;
  • the fast MCP server is usable even if the optional server is pending;
  • the optional server is surfaced as pending/unavailable with timing;
  • bounded subagents can be spawned, waited, cancelled, and closed without indefinite hangs;
  • the run record makes it clear whether latency came from startup, MCP, session history, WSL/remote, subagent control, or model streaming.

This would also give users a better way to report issues without collapsing everything into generic "slow" reports.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #29321
  • #29376
  • #29057
  • #29937
  • #28935

Powered by Codex Action

Nicolas0315 · 2 months ago

Adding one sanitized local measurement that supports the dependency-splitting request above.

Contributing note: I read docs/contributing.md and am keeping this as issue analysis / reproduction data rather than opening an unsolicited PR.

Environment class:

  • macOS / arm64
  • Codex CLI callable
  • read-only measurement only; no cleanup, auth mutation, config mutation, or MCP mutation

Normal CODEX_HOME:

  • codex --version: 94.5 ms
  • codex mcp list: 1729.1 ms
  • gh issue view: 811.2 ms
  • local sessions: 564 files, about 1.06 GB
  • archived sessions: 10 files, about 33.5 MB
  • logs_2.sqlite: about 487 MB
  • state_5.sqlite: about 2.7 MB
  • board classification: codex mcp list warning, logs_2.sqlite above local soft cap

Clean temporary CODEX_HOME:

  • codex --version: 49.2 ms
  • codex mcp list: 79.2 ms
  • gh issue view: 701.3 ms
  • local sessions: 0
  • SQLite state/log files: 0
  • board classification: no blocker detected

Interpretation:

  • This single-machine sample does not prove the full root cause.
  • It does show that startup-adjacent commands can differ sharply between a real long-lived Codex home and a clean home.
  • The biggest observed delta here is codex mcp list:
  • normal home: 1729.1 ms
  • clean home: 79.2 ms
  • That supports separating local history/state pressure, MCP discovery, and first-turn readiness in diagnostics instead of presenting one generic "Codex is slow" symptom.

The local board I used records only aggregate timings and file counts. I am intentionally not attaching hostnames, raw logs, local paths, token-bearing config, connector contents, or private machine inventory.

Nicolas0315 · 2 months ago

Follow-up local measurement, sanitized and aggregate-only.

This adds two clarifications to my earlier report:

  1. separate aggregate codex mcp list timing from codex mcp get <name> config retrieval timing;
  2. record one live codex exec --ephemeral first-turn probe.
  • normal long-lived CODEX_HOME
  • codex --version: 78.7 ms
  • codex mcp list: 1644.6 ms
  • configured MCP entries discovered: 12
  • enabled: 6
  • disabled: 6
  • codex mcp get <name> detail probes: 12 measured
  • slow detail probes: 0 in this run
  • codex exec --ephemeral no-tool first-turn probe: 9550.6 ms, status ok
  • local sessions: 572 files, about 1.07 GB
  • logs_2.sqlite: about 580 MB
  • clean temporary CODEX_HOME
  • codex mcp list: 405.5 ms in the latest clean run
  • configured MCP entries discovered: 0
  • blockers: none

Important caveat:

The per-MCP detail probe uses codex mcp get <name>, so it measures config retrieval through Codex CLI, not actual server startup or tool-list readiness. It is useful only to separate "listing/config retrieval overhead" from a true live MCP startup/tool-list benchmark. It should not be used as proof that a specific MCP server is slow.

Interpretation:

  • In this run, the aggregate codex mcp list path was still warning-level while individual codex mcp get config retrievals were fast.
  • The live first-turn probe is now a separate signal: about 9.6 seconds for a minimal ephemeral read-only codex exec prompt.
  • I still would not attribute that first-turn time to MCP or local history from this single run. The next useful product diagnostic would be a supported run record that splits CLI startup, config load, MCP listing/discovery, model request, and first token.

I am intentionally not including server names, hostnames, local paths, token-bearing config, connector data, or raw logs.

Nicolas0315 · 2 months ago

Sanitized paired first-turn probe using the same CODEX_HOME authentication.

Probe shape:

  • normal: codex exec --ephemeral with a no-tool prompt
  • comparison: same command plus --ignore-user-config
  • same CODEX_HOME, so auth state is not copied or modified
  • read-only sandbox, no cleanup, no config mutation

Run 1:

  • normal: 7464.8 ms, status ok
  • ignore user config: 4892.0 ms, status ok
  • delta: 2572.8 ms

Run 2:

  • normal: 10977.5 ms, status ok
  • ignore user config: 5207.6 ms, status ok
  • delta: 5769.9 ms

Aggregate across the two paired runs:

  • normal mean: about 9221.2 ms
  • ignore-user-config mean: about 5049.8 ms
  • mean delta: about 4171.4 ms

Interpretation:

  • This still does not prove causality because model latency varies and the probe is intentionally tiny.
  • It does suggest that a same-auth comparison with user config ignored is a useful diagnostic surface for splitting user config / rule / MCP setup overhead from auth and model response behavior.
  • A built-in Codex run record could expose this more reliably by splitting:
  • CLI startup;
  • user config and rule loading;
  • MCP discovery/config listing;
  • first model request;
  • first token/final response.

Do not include server names, local paths, auth details, logs, connector data, or raw config in public comments.

wiety · 6 days ago

Additional reproducible report from a Linux Codex user:

  • Codex CLI: 0.149.0
  • An existing interactive session became extremely slow/stalled on short follow-up messages.
  • The user was advised to start a fresh session.
  • The fresh session exhibited the same behavior: ordinary conversational follow-ups and a simple image-based check could pause for roughly three minutes before a visible answer.
  • Starting a new thread therefore did not clear the latency.
  • From the user's perspective the UI provides no useful distinction between model latency, tool/bootstrap work, context processing, or a stalled continuation.

Expected: a fresh session should respond promptly, and any operation lasting more than a few seconds should expose its current phase and remain interruptible.

No private repository, host, screenshot, or customer-system details are included.