Allow thread/start to accept a caller-supplied thread ID for a new session

What variant of Codex are you using?

CLI, SDK, and app-server / MCP

What feature would you like to see?

Basically, codex --session-id [CUSTOM_ID], or something like that.

Any use case or integration currently where the session/thread ID needs to be known ahead of time is pain with Codex right now. I was looking for something like this, and was surprised not to find it.

I'd like a way to create a brand-new thread with a caller-supplied thread ID,
instead of having Codex always generate the ID on thread/start.

This is not about resume, fork, or reopening an existing thread. The ask is
specifically:

• start a fresh session
• provide the thread/session ID up front
• have that ID become the canonical ID for the new thread

Today, the thread APIs are good at continuing existing work:

• thread/resume can resume by threadId, history, or path
• thread/fork can branch existing work

But there does not seem to be a supported way to say "start a new thread, and
use this ID as its identity from the beginning."

This would help when Codex is embedded in a larger system that already has its
own stable conversation/job/task IDs and wants a 1:1 mapping without maintaining
a separate alias layer.

A minimal version could be:

• add an optional threadId field to thread/start
• reject if the ID already exists
• otherwise create a new thread with that ID

Additional information

A few concrete use cases:

• an app wants its own conversation ID to match the Codex thread ID
• a job runner wants deterministic IDs so logs, traces, and persisted metadata

all line up

• external tooling wants to create a thread first, then attach later via

resume using an ID it already knows

Right now the workaround is to keep a separate mapping from external IDs to
Codex-generated thread IDs, or to reconstruct via history / path. That
works, but it is awkward when the outer system wants Codex to fit into an
existing identity model.

Claude has an explicit version of this idea already:

• claude --session-id [CUSTOM_ID]

If preserving Codex-owned rollout metadata is a concern, another acceptable
shape would be a separate external ID field that is indexed and resumable, but
the main thing I'm looking for is first-class support for stable
caller-controlled identity at thread creation time.