Skip to content

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

Open
Open
Make Codex startup, MCP, and subagent orchestration non-blocking and observable for multi-machine workflows#30399
Labels
CLIIssues related to the Codex CLIappIssues related to the Codex desktop appenhancementNew feature or requestmcpIssues related to the use of model context protocol (MCP) serversperformancesubagentIssues involving subagents or multi-agent features

Description

@Nicolas0315
Nicolas0315
opened on Jun 28, 2026

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

Issue URL: #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:

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

  2. 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

  3. 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

  4. 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

  5. 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.

Activity

  1. github-actions
    added
    enhancementNew feature or request
    CLIIssues related to the Codex CLI
    appIssues related to the Codex desktop app
    mcpIssues related to the use of model context protocol (MCP) servers
    subagentIssues involving subagents or multi-agent features
    performance
    on Jun 28, 2026

  2. github-actions commented on Jun 28, 2026

    @github-actions
    github-actionsBot
    on Jun 28, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. Nicolas0315 commented on Jun 28, 2026

    @Nicolas0315
    Nicolas0315
    on Jun 28, 2026
    Author

    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.

  4. Nicolas0315 commented on Jun 29, 2026

    @Nicolas0315
    Nicolas0315
    on Jun 29, 2026
    Author

    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.

  5. Nicolas0315 commented on Jun 29, 2026

    @Nicolas0315
    Nicolas0315
    on Jun 29, 2026
    Author

    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.

  6. wiety commented on Aug 22, 2026

    @wiety
    wiety
    on Aug 22, 2026 – with ChatGPT Codex Connector

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLIappIssues related to the Codex desktop appenhancementNew feature or requestmcpIssues related to the use of model context protocol (MCP) serversperformancesubagentIssues involving subagents or multi-agent features

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions