Wire MCP servers into Codex runtime sessions

[eladrave]

Summary

• forward each managed agent's configured MCP servers into its Codex thread/start request
• authenticate the built-in platform MCP without embedding the gateway secret in thread configuration
• accept JSON-RPC notifications without returning an invalid response payload
• optionally route already-validated platform MCP traffic over a private control-plane address
• skip Anthropic MCP-vault provisioning for Codex compatibility profiles
• keep platform-managed delegation authoritative by disabling native Codex collaboration on platform MCP threads
• isolate managed MCP threads from account-level apps
• return only the child agent's final message instead of concatenating commentary and final output
• verify platform routing behavior while building the Codex runtime image

Root cause

Codex-backed agents retained MCP definitions in LAP, but the runtime did not project them into the Codex thread configuration. Once projected, the built-in platform MCP exposed additional interoperability and ownership problems:

1. Codex compatibility profiles are represented by the managed-agent runtime enum, so provisioning attempted the Anthropic vault API against a Codex profile endpoint.
2. The platform endpoint replied to JSON-RPC notifications with a response carrying a null ID, which the Codex MCP client rejected.
3. Long-running sub-agent calls could traverse the public reverse proxy and exceed its request timeout even when the runtime and control plane share a private network.
4. Native Codex collaboration and the LAP platform MCP could both expose delegation tools, creating competing orchestration paths.
5. Managed MCP threads inherited account-level apps that were outside the managed agent's configured tool boundary.
6. The platform collector concatenated commentary and final message items, so structured child output could be contaminated by progress text.

Security and compatibility

• The gateway key is referenced by environment-variable name (LAP_GATEWAY_API_KEY); its value is never copied into Codex thread configuration.
• The key is attached only to the named platform MCP after its public origin and /mcp/platform/ path are validated against LAP_GATEWAY_MCP_BASE_URL.
• Optional private routing is applied only after that validation and uses the operator-configured LAP_GATEWAY_MCP_INTERNAL_BASE_URL.
• Other remote MCP servers remain unauthenticated by this bridge and retain their original URLs.
• Threads with managed MCP definitions disable account apps; platform threads additionally disable native Codex collaboration so LAP remains the sole delegation authority.
• A build-time verifier confirms ordinary Codex threads retain native collaboration while platform threads expose run_sub_agent without native collaboration or account apps.

Validation

• Node 20 Codex runtime suite: 23 passed, 0 failed
• Rust formatting check: passed
• Focused Rust final-message regression: passed
• Codex runtime image build and platform-routing verifier: passed
• Earlier full Rust library suite for the bridge: 141 passed, 0 failed
• Production-like end-to-end: a Codex parent agent listed sub-agents, invoked finance and browser sub-agents through the platform MCP, received both results, and completed without session errors or reverse-proxy timeouts

Dependency

This is a stacked PR based on #494, which introduces the Codex app-server runtime. The incremental bridge and orchestration work is contained in the eleven commits after the current #494 head. Once #494 merges, GitHub will automatically reduce this PR's diff to those follow-up changes.

[eladrave]

Follow-up reliability fixes are now included in the branch:

• Codex threads with the LAP platform MCP disable native Codex collaboration, keeping platform.run_sub_agent as the authoritative and visible child-session path.
• LAP child runs can take up to 30 minutes, while the Codex platform MCP client waits 31 minutes, avoiding premature transport failure and duplicate retries.
• The SSE parser now buffers raw bytes until a complete line is available, so a multi-byte UTF-8 character split across HTTP chunks cannot terminate an otherwise valid agent event stream.

Verification:

• Codex runtime suite: 21/21 passing.
• Rust SSE parser suite: 6/6 passing, including a regression that splits an en dash inside its UTF-8 byte sequence.
• Full production image builds and non-root boot/binary smoke checks passed.
• End-to-end platform acceptance produced visible finance and browser child sessions, matched every run_sub_agent call with a result, reached terminal parent/child events, and emitted no native collaboration or transport errors.
• A focused browser acceptance completed 5 real browser tool calls and returned a Unicode-containing terminal result through the platform MCP without error.
• No external-delivery agent was invoked during acceptance.