MCP Server: codex-reply tool missing conversationId in response
Resolved 💬 2 comments Opened Dec 28, 2025 by Galaxy-0 Closed Dec 28, 2025
Summary
When using codex mcp-server as an MCP server (e.g., integrated with Claude Code), the codex tool does not return the conversationId in its response, making it impossible to use codex-reply for continuous conversations without manually retrieving the session ID from the filesystem.
Current Behavior
- Call
codexMCP tool → Get result text only codex-replyrequiresconversationId(UUID format)- The session ID is only available by parsing filenames in
~/.codex/sessions/YYYY/MM/DD/rollout-{timestamp}-{SESSION_ID}.jsonl
Expected Behavior
The codex MCP tool response should include the conversationId so that subsequent codex-reply calls can be made seamlessly:
{
"result": "...",
"conversationId": "019b63ce-02a4-7223-8d1d-f5dc6a1b4877"
}
Reproduction Steps
- Configure
codex mcp-serverin an MCP client (e.g.,.mcp.json) - Call the
codextool with a prompt - Attempt to call
codex-reply- fails because noconversationIdwas provided in the initial response - Workaround: Manually extract UUID from
~/.codex/sessions/directory
Workaround
# Get the latest session ID from filesystem
ls -t ~/.codex/sessions/$(date +%Y)/$(date +%m)/$(date +%d)/*.jsonl | head -1 | \
grep -oE '[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}'
Environment
- Codex CLI version: latest
- MCP integration: Claude Code
- OS: macOS
Impact
This limitation prevents seamless multi-turn conversations when using Codex as an MCP server, which is a key use case for AI-to-AI collaboration workflows.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗