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.