Expose thread/read and thread/list as MCP tools for tool-only clients

What variant of Codex are you using?

CLI (MCP server mode via codex mcp)

What feature would you like to see?

What version of the Codex App are you using?
CLI 0.100.0

What subscription do you have?
Pro

What platform is your computer?
macOS (Apple Silicon M2)

What issue are you seeing?
The App Server internally supports thread/read and thread/list, but these are not
exposed on the MCP tool surface. Clients that interact via tools/list + tools/call
have no read-only access to threads - only codex (create) and codex-reply (write).

Expected:
MCP tool-only clients should be able to read thread history and list existing threads
without writing to them.

Actual:
The only way to interact with a thread via MCP is to post a new message (codex-reply).
There is no way to inspect thread state, recover context after a client restart, or
discover existing threads without manually tracking threadIds.

Impact:

• If a client loses a threadId or restarts mid-session, the entire conversation context is

lost - forcing a costly cold start to rebuild in a new thread.

• Recovering context requires posting a "what did we discuss?" message, which pollutes the

thread.

• No way to make pre-flight decisions (resume vs fork vs new) based on thread recency,

archived state, or token usage.

• Cross-client continuity is broken - a thread touched by CLI, IDE, and MCP client has no

shared read path for tool-only clients.

Related: #6168, #5660, #3712, PR #9192.

What steps can reproduce the bug?
Steps to reproduce:

1. Start Codex as an MCP server.
2. Use codex tool to create a thread - save the returned threadId.
3. Use codex-reply to have a multi-turn conversation.
4. Simulate a client restart (lose local state but retain the threadId).
5. Attempt to read the thread history without posting a new message.
6. Observe that no read-only tool exists - tools/list only shows codex and

codex-reply.

What is the expected behavior?
tools/list should include read-only thread tools:

• codex-thread-read(threadId, includeTurns?, cursor?) - returns thread metadata +

paginated turn history without side effects.

• codex-thread-list(limit?, cursor?, archived?, cwd?) - returns list of threads with

metadata for discovery and resume decisions.

Both should return stable machine-readable structuredContent + human summary in
content, with cursor-based pagination for long threads.

Additional information

• The App Server already has these capabilities internally - this is a request for

tool-surface parity for MCP clients.

• Heavy MCP users who maintain long-running threads across sessions need context recovery,

thread discovery, and informed resume decisions - all without writing to the thread.

• Acceptance criteria: (1) tools/list includes both tools, (2) cursor-based pagination,

(3) no write side effects, (4) stable structuredContent format.