fix(daemon): let a Codex first turn wait for slow MCP servers

[zfy0701]

Refs #2770

Problem

When Codex builds a turn's tool list, it waits at most 1 s (DEFAULT_OPTIONAL_MCP_STARTUP_GRACE) for MCP servers that are still starting, and leaves the rest out of that turn. A remote HTTP MCP server that needs a second or more to answer initialize therefore misses the first turn of every new or loaded session. The agent then says the tool does not exist, or its first call fails, even though the daemon passed the server correctly.

Change

• codexConfigWithMcpStartupGrace() sets mcp_optional_startup_grace_ms to 10 s in CODEX_CONFIG. A value the runtime config already sets is kept.
• AcpHost.start() applies it to every Codex spawn, next to the account-app and request_user_input settings. Cluster launches build their env on the same path, so both local and pool sessions get it.

The setting is a top-level Codex config key, so codex-acp needs no change: it already merges CODEX_CONFIG into the config of every thread/start and thread/resume, including the resume behind session/load.

Why this and not the alternatives

• required = true on each MCP server also makes the turn wait, but Codex then fails thread/start / thread/resume when that server cannot start, so one broken server would break the whole agent.
• The adapter's _meta.mcpStartupAwaitTimeoutMs covers session/new and session/resume only. Its own docs say session/load ignores it, and a load is how the daemon reopens an idle session.

Verification

Reproduced locally against codex-acp 2.1.1-agentconnect.1 with its bundled Codex 0.159.3. The MCP server was an HTTP server that answers initialize after 3 s, passed through ACP mcpServers as the daemon does. A stub Responses endpoint recorded the tools Codex sent in the first model request.

CODEX_CONFIG	Open	First model request after prompt	Server's tool in first request
default	session/new	1.08 s	no
default	session/load	1.07 s	no
grace 10000	session/new	3.03 s	yes
grace 10000	session/load	3.03 s	yes
grace 10000, server never answers	new and load	10.07 s	no; the turn completes normally

Unit tests cover the helper and the env each Codex spawn receives.

Not covered

The issue also asks for a daemon log line when a turn starts with a configured server still pending. That is not part of this change. With the longer grace, the only remaining silent case is a server still not ready after 10 s.

🤖 Generated with Claude Code · Claude Opus 5.5

[agentconnect-md-test]

Reviewed d7ed0fc. No blocking findings.

The 10-second default is applied before the shared local/cluster launch, preserves explicit CODEX_CONFIG values (including zero), and composes with the existing account-app and user-input settings. The pending-server diagnostic remains an explicitly documented follow-up under #2770.

Validation: direct helper assertions and git diff --check passed. The focused Vitest suites were not run to completion: dependency bootstrap was slow and was stopped before tests started.

_{sent by review-bot (Codex · gpt-6-astra) · open in session}