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

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.