Session continuity not working - no session ID returned from initial calls
Description
When using Codex through an MCP (Model Context Protocol) integration, session continuity doesn't work because the initial Codex call doesn't return a session ID that can be used for subsequent conversation turns.
Expected Behavior
Based on the MCP integration design:
- Initial call to Codex should return both the response text AND a session ID
- Subsequent calls should be able to use this session ID to continue the conversation with maintained context
Actual Behavior
- Initial Codex call only returns the text response, no session ID
- Attempting to continue the conversation fails with "Session not found" errors
- Context is lost between calls
Steps to Reproduce
- Start a Codex conversation with an initial prompt including context to remember:
````
"Hello! My favorite color is blue. Please remember this."
- Attempt to continue the conversation with a follow-up that references the context:
````
"What was my favorite color that I mentioned earlier?"
- The continuation fails because there's no session ID to reference
Impact
This prevents building stateful, multi-turn conversations with Codex, which is essential for:
- Complex coding tasks that require iterative refinement
- Maintaining context across multiple related questions
- Building conversational AI experiences with Codex
Possible Solutions
- Return session IDs: Modify Codex to return a session identifier along with each response
- Document session management: If session management exists but works differently, provide documentation on the correct approach
- Stateless context passing: If sessions aren't supported, document how to pass previous context in subsequent calls
Environment
- Using Codex through MCP (Model Context Protocol) integration
- Testing with both sync and async execution modes
Additional Context
The MCP wrapper for Codex expects session functionality (with sessionId parameters), suggesting this was intended to work but may have an implementation gap between what the MCP server expects and what Codex provides.
Would appreciate guidance on whether session continuity is supported and if so, how to properly implement it.
4 Comments
Threw this together which works for me locally https://github.com/openai/codex/pull/2449
@ebeloded if you wish to test my changes quickly you can run it locally via:
Faolain:fix/sessionId-inclusionbranchcd <Directory>/codex/codex-rs && cargo build --release --bin codex-mcp-servercodex/code-rs/target/releasefolder which should have thecodex-mcp-serverbinary which you can run as is.If you want to get some nice interactivity as a followup:
export PATH="$PATH:/Users/<Directory>/codex/codex-rs/target/release"to ensure it's available in your path (make sure you built it in the previous step)npx @modelcontextprotocol/inspectorwithin the same terminal, this will open a browser where you can test the newly created mcp server binarycodex-mcp-serverwhich is the same binary we just created and press connect<img width="233" height="424" alt="Image" src="https://github.com/user-attachments/assets/b29e8d8e-9aa1-4c61-b2e2-0ad2d4308434" />
list_tools<img width="701" height="224" alt="Image" src="https://github.com/user-attachments/assets/c3bd1607-0d64-4fd1-863f-3b75655f5ed3" />
which will now show
codexandcodex-replysessionIdin the structured response<img width="1362" height="874" alt="Image" src="https://github.com/user-attachments/assets/9aecfe90-d7a3-4727-b492-ffe8887f90e1" />
codex-replytool and provide thesessionIdyou got back (it will be your own unique session and different from mine)<img width="2814" height="1170" alt="Image" src="https://github.com/user-attachments/assets/2bb6c3b5-96b6-4734-8e81-0f221baaa5ad" />
Tada. If you have any questions codex might be able to help better hehe
I think it's implemented in https://github.com/openai/codex/pull/3219 and will be released with v0.32.0 in a few days
Sorry for the misleading comment. Although #3219 introduced more consistent foundations with conversation id, but currently it seems to be only exposed in session_configured MCP event that's not being utilized by many MCP clients yet.
This was addressed a while ago, just forgot to close the issue.