structuredContent is actually sent to the model. It’s included in the serialized tool result that the model sees. So the model can technically access the threadId, it just may not know to use it for follow-up calls unless you tell it to.
Workaround: Try adding a Cursor Rule .cursor/rules that instructs the agent to always extract threadId from the Codex MCP result’s structuredContent and pass it in subsequent calls. Something like:
When using the Codex MCP server, always look for threadId in the structuredContent of the tool result. Include this threadId in all follow-up calls to maintain conversation continuity.
The hooks gap is real though. afterMCPExecution currently only serializes content and isError, dropping structuredContent. I’ve flagged this with the team.
Let me know if the rules workaround helps with the model passing the threadId.
I went into the rabbit hole of setting up hooks exactly because i was unable to get cursor read the threadId from structuredContent, now i’m even building my own MCP because the one from codex is too defensive and the models are biased to run it in read-only mode, and with a custom MCP i can return the threadId directly in the text response as well
I see the screenshot, the model clearly says it didn’t get threadId from structuredContent. Looks like my earlier reply was too optimistic.
Technically, structuredContent goes through serialization, but based on your test, the model doesn’t actually see that data or can’t access it. I shared this with the team for a deeper look, but we don’t have a clear answer yet on why it happens.
For now, your workaround with a custom MCP that returns threadId directly in the text response is the most reliable path. I’ll let you know if there’s any update on this.
