ACP ignores MCP timeout settings for runtime-injected mcpServers (tool_timeout_sec/startup_timeout_sec forced to None)

[BitsInBytes]

Summary

When mcpServers are provided dynamically via ACP session/new or session/load, codex-acp rebuilds each server config and hard-sets:

• startup_timeout_sec = None
• tool_timeout_sec = None

This makes timeout tuning impossible for dynamically injected MCP servers, even though static TOML-configured servers support these fields.

Why this matters

Some MCP tools legitimately run longer than the default timeout (for example 2–3 minute operations).
With dynamic injection, these calls time out and abort, and there is currently no way to configure timeouts without patching codex-acp.

Repro

1. Use an ACP client that injects MCP servers at runtime through session/new/session/load mcpServers (not static ~/.codex/config.toml).
2. Call a tool that runs longer than the default timeout (~2 mins).
3. Tool call times out.
4. Attempting to configure timeout via injection has no effect because injected config is overwritten to None.

Current behavior

In src/codex_agent.rs, build_session_config(...) inserts injected servers and explicitly sets:

• startup_timeout_sec: None
• tool_timeout_sec: None

So runtime-injected servers cannot carry timeout config.

Expected behavior

Runtime-injected MCP servers should be able to configure timeouts (or at least preserve existing configured timeout values), so long-running tools can be supported without local source modifications.

Suggested fix

In build_session_config(...) when mapping ACP McpServer -> McpServerConfig:

1. Do not unconditionally set timeout fields to None.
2. Preserve existing timeout values from same-name server if present.
3. Optionally parse timeout overrides from McpServer._meta (e.g. namespaced keys) and apply them.
4. Keep current defaults only when no explicit timeout is provided.

[BitsInBytes]

I have created a PR that fixes this and verified the fix works - #278