Feature request: codex exec --session-id <uuid> to pre-seed session UUID for new sessions

What variant of Codex are you using?
CLI (@openai/codex v0.134.0)

---

What feature would you like to see?

A --session-id <uuid> flag on codex exec that lets the caller supply the UUID for a new session before the session starts.

Current behavior

codex exec <prompt> always generates its own session UUID. The only session-ID-related flag is codex exec resume <id>, which requires the session to already exist.

There is no way to tell codex "start a new session and use this UUID for it."

Desired behavior

\\\`sh

caller chooses the UUID

SESSION_ID="$(uuidgen)"
codex exec --session-id "$SESSION_ID" --json "do the work"

session is persisted under the caller-supplied UUID

\\\`

The session would behave identically to a normal codex exec run, except its persisted UUID matches the one the caller provided.

Why this matters

1. Hook correlation without a lookup step.
Codex fires hooks (SessionStart, Stop, PostToolUse, etc.) that carry session_id in their payloads. Downstream systems that consume those events need to know the session ID before the session starts — so they can open the right sink, set up the right log path, or link the run to an existing task record. Today they must race the SessionStart hook or scan ~/.codex/sessions/ after the fact.

2. Deterministic session directories in automation.
CI jobs and orchestration scripts that invoke codex exec in parallel benefit from stable, pre-known session IDs. Collision-free UUIDs generated by the caller (e.g. from a job ID or task UUID) remove the need for a post-hoc mapping step.

3. Idempotent re-runs.
When a pipeline reruns a failed job with the same task UUID, supplying the same --session-id allows the downstream system to detect "this session already ran" without querying session storage.

4. Multi-tool orchestration.
Tools that wrap codex exec (orchestrators, agent runners, IDE extensions) often have their own session/context model. Letting them inject their UUID into codex closes the identity gap between the orchestrator's session and codex's session.

Proposed interface

\\\`
codex exec [OPTIONS] [PROMPT]

Options:
--session-id <UUID> Use the supplied UUID as this session's identifier.
Errors if a session with that UUID already exists
(use codex exec resume for that case).
\\\`

A conflict guard (errors if UUID already exists) keeps the semantics clean: --session-id is strictly "new session with known UUID"; resume is strictly "continue existing session."

---

Additional information

The hook system already carries session_id in every event payload — this feature simply makes that value predictable before the first event fires. No changes to hook payloads, session storage format, or resume behavior would be needed; only the UUID-generation step for new sessions would become externally injectable.