Elicitation support
Open 💬 11 comments Opened Mar 3, 2026 by theg1239
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What variant of Codex are you using?
CLI 0.107.0
What feature would you like to see?
When using MCP servers that require per-tool approval via form elicitation, Codex currently cannot complete the tool call. It would be good to have the Codex MCP client support tool approval via elicitation.
Additional information
_No response_
11 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This does not seem like a duplicate of #11816.
#11816 is a server-side bug in codex mcp-server: when approval requires elicitation and the client never answers, the server can hang indefinitely.
This issue is different. In my case there was no hang. The MCP server returned a clear error immediately:
> This MCP server requires a client with form elicitation support so each tool call can be explicitly approved.
So the server behaved correctly. The missing piece is client-side support, the Codex MCP client currently does not implement the MCPcorm elicitation flow needed to surface the approval UI and send the user’s response back to the server.
That makes this a feature request for Codex clients to support MCP form elicitation, not a report about the indefinite-hang bug in #11816.
I'd also like to see this. My understanding is this is a blocker to using GitHub MCP remotely via OAuth https://github.com/github/github-mcp-server/issues/132
The ask for GitHub MCP is URL Elicitation, not form mode however, as we are hoping to improve security by providing STDIO Oauth and we want to provide the interactive oauth login via secure URL Elicitation.
We have a fallback of form Elicitation for the device code if interactive oauth fails, but the strong desire is for MCP clients generally to support Elicitation fully.
This feature request hasn't received enough upvotes, so closing.
@etraut-openai does OAI require issue upvotes to implement standard parts of the MCP spec?
Can we reopen this, please? The reason we are not leveraging elicitation on our side is because codex doesn't support it.
Maybe change the title of the issue to "Elicitation support", and add "upvote police" in the issue template?
@Kludex, this feature request didn't receive enough upvotes for us to consider investing in it. If you'd like to open a new feature request, you're welcome to. Sometimes the title or description are not sufficiently compelling to attract upvotes from other Codex users. You could try rephrasing in a new feature request.
@etraut-openai I shared this on the MCP official discord client developers channel, https://discord.com/channels/1358869848138059966/1399982845144989786/1489592059773059103
Being spec compliant with MCP is not really a sensible thumbs up contest, if you really want I am sure I could send loads of fellow sever authors this direction, but you can’t really be expecting end users to realise it is due to lack of MCP Spec feature implementation. What they do instead is open up issues on MCP servers complaining they don’t work, misunderstanding that it’s the client.
Since this is a spec compliance issue, I'm going to change it from a feature request to a bug report.
Thank you, appreciate it! I understand you’ll have to prioritise. Just happy to have it tracked! 🙏