codex - 💡(How to fix) Fix MCP: re-evaluate resume_path for Codex sessions

Summary

Requesting that MCP clients be able to resume a prior Codex session from its rollout file — e.g. an optional resume_path (or conversation_id) parameter on the codex MCP tool, wiring the already-existing RolloutRecorderParams::Resume through the MCP runner.

Background

This was previously proposed and closed:

• #10117 (PR) — "MCP: add resume-path support for Codex sessions"
• #10122 (issue) — "MCP resume_path for Codex sessions"

The PR was closed under the updated contribution guidelines ("we're no longer accepting unsolicited code contributions. All code contributions are by invitation only."), not for technical reasons — so I'm filing this as a feature request rather than a contribution.

The gap

A live codex mcp-server exposes two tools: codex (start a new session) and codex-reply (continue by threadId). codex-reply resolves a threadId only through the in-memory ThreadManager of the running server process. Once that process exits, the thread map is gone and codex-reply returns "thread not found". There is no MCP path to re-attach to a session by its on-disk rollout, even though RolloutRecorderParams::Resume { path } already exists in the core crate and backs codex resume.

Why it matters

I maintain Mardi Gras, a TUI that integrates Codex over MCP. The lack of this one parameter is the only blocker to robust resume-after-restart: when the client restarts, in-flight sessions are orphaned. Today's only workaround is shelling out to codex resume in a separate pane, which leaves the MCP client's transcript out of sync. The same gap affects any MCP-mode client that wants to survive a restart.

Ask

If a rollout-based resume aligns with the roadmap, I'd be glad to see #10117 revisited (and happy to rebase it if invited), or to follow whatever shape you'd prefer.