mcp-server: make codex-reply resumable across restarts

[leeroybrun]

What

This PR adds persistent resume/recovery to the MCP codex-reply tool-call.

• Fixes: #6168
• Fixes: #5066

Previously, codex-reply only succeeded if the conversation was still present in the server’s in-memory ConversationManager. After restarting codex mcp-server, that map is empty and codex-reply immediately fails with “Session not found…”.

With this change, when a conversation is not in memory, codex-reply will rehydrate it from the persisted rollout JSONL on disk (under CODEX_HOME/sessions/...) using the provided conversation_id, then continue the conversation normally.

Why

This closes the gap described in:

• #6168: MCP codex-reply cannot resume after restarting the MCP server even though the rollout exists and codex resume <sessionId> works.
• #5066: MCP tool cannot resume conversations from persistence.

Resume parity with CLI: This effectively adds “resume” functionality to the MCP server in the same spirit as codex resume <sessionId>. External integrations can continue a session after a process restart by providing the conversation/session id, and Codex will load the persisted history from disk.

How

• In the codex-reply handler:
  • Attempt conversation_manager.get_conversation(conversation_id)
  • If missing:
    • Locate rollout path via codex_core::find_conversation_path_by_id_str(&config.codex_home, <conversation_id>)
    • Resume via conversation_manager.resume_conversation_from_rollout(config.clone(), rollout_path, auth_manager.clone())
    • Emit a session_configured notification (so clients can observe the resume handshake)
    • Submit the new user prompt to the resumed conversation

Tests

Adds an integration test that:

• Writes a minimal rollout file for a new conversation_id
• Calls codex-reply directly (no prior in-memory conversation)
• Asserts the server emits session_configured for that id and the tool call completes successfully

Run locally:

• cargo test -p codex-mcp-server --tests

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[leeroybrun]

I have read the CLA Document and I hereby sign the CLA

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 38389bca5e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve per-session config when resuming from rollout

Resuming a codex-reply session always clones the server’s global config (self.config) before calling resume_conversation_from_rollout, which silently drops any per-session overrides that were used when the conversation was created (e.g., custom cwd, model, approval/sandbox policy supplied via the initial codex tool call). After an MCP server restart, the resumed session can therefore run in the wrong directory or with different policies/models than the original, which changes tool behavior and can lead to commands acting on the wrong workspace. Consider deriving the config for resume from the rollout’s session metadata (or persisting the original config alongside the rollout) so resumed sessions keep their original settings.

Useful? React with 👍 / 👎.

[leeroybrun]

Added a new commit to restore session settings from rollout TurnContext

[etraut-openai]

Our contribution guidelines clarify that we're currently accepting contributions for bugs fixes, but we're not accepting new features at this time. We need to make sure that all new features compose well with both existing and upcoming features and fit into our roadmap. If you would like to propose a new feature, please file or upvote an enhancement request in the issue tracker. We will generally prioritize new features based on community feedback.

[leeroybrun]

@etraut-openai Totally understand the contribution policy.

That said, I think this lands solidly in the “bugfix” category rather than a new feature: today codex-reply accepts a conversation_id, and Codex already persists that session’s rollout to disk, but if the MCP server process restarts/crashes the conversation is only stored in memory and codex-reply can no longer continue the session, even though the backing rollout exists. In practice, this breaks the expected durability of conversation_id and makes MCP sessions fragile to restarts.

The change I’m proposing doesn’t introduce new user-facing surface area or parameters; it only ensures that when a conversation_id isn’t found in memory, it rehydrates from the existing rollout file and continues. Behavior is unchanged when the session is already in memory.

In my sense, from an MCP consumer standpoint, this is a reliability/correctness fix for an already-supported workflow.

[etraut-openai]

I reviewed #6168 and #5066, and I think these are correctly categorized as enhancement requests rather than bug reports. I understand your perspective, but we're going to pass on this PR.

I'd be inclined to make an exception if this were a small and targeted change, but your PR is relatively large and makes some big behavioral modification. It would require a not-insignificant investment of time from someone on the codex team to review and validate the change and work with you on follow-on changes as part of the code review.

Given our large backlog of bug reports and feature requests, we need to be disciplined about prioritization and invest in the changes that will have the most impact for the most Codex users. We will eventually get to #6168 and #5066, but there are many higher-priority (more highly upvoted) features and bug fixes ahead of these issues.

In the meantime, you might find that non-interactive mode (either with or without the Codex SDK) suits your needs.