Feature request: expose current Codex session ID programmatically (env var or JSON)

What feature would you like to see?

##Feature request: expose current Codex session ID programmatically (env var or JSON)

###Summary
Codex CLI maintains a session ID internally (used for resume/history), but there is no supported way to access the active session ID programmatically from scripts, wrappers, or tools. This makes it difficult to safely run multiple concurrent Codex instances with isolated state (e.g., continuity ledgers, logs, artifacts).

###Current behavior

• Codex sessions have IDs that can be:
• seen interactively (e.g. /status),
• resumed via codex resume <SESSION_ID>,
• found in ~/.codex/sessions/<session_id>/.
• However, the active session ID is not exposed:
• not as an environment variable,
• not via a machine-readable command,
• not via JSON output.

As a result, external tooling must:

• invent its own session IDs (parallel to Codex’s),
• or scrape human-oriented output or filesystem state (brittle).

###Why this matters
This blocks several legitimate workflows:

• Running multiple Codex instances in parallel without collisions
• Isolating continuity ledgers, logs, artifacts, or caches per session
• Building robust wrappers around codex / codex exec
• Integrating Codex cleanly into automation pipelines (CI, task runners, MCP tooling)

In practice, users are forced to re-implement session identity outside Codex, which duplicates state Codex already tracks internally.

###Proposed solutions (any one would solve this)
All options below are additive and backward-compatible:

1) Expose an environment variable
CODEX_SESSION_ID=<current_session_id>

Available to:

• tools launched by Codex
• shell wrappers invoking Codex

2) Add a machine-readable status command
codex status --json

Example output:
{
"session_id": "abc123",
"model": "gpt-5.2-codex",
"directory": "/path/to/repo"
}

3) Add a launch flag
codex --session-name mytask

• Sets a stable, user-defined session identifier
• Useful for long-running or named tasks

###Why this is safe

• No breaking changes
• No behavior change for existing users
• Enables advanced users without affecting simple workflows
• Aligns with existing session semantics already present in Codex

###Version

• Codex CLI: v0.79.x
• Platform: Linux / WSL (platform-independent issue)

###Real-world example
Running two Codex instances concurrently:

codex (task A)
codex (task B)

Both currently share implicit global state unless the user builds custom isolation. Exposing the session ID would allow tooling to do:

LEDGER=~/.codex/ledgers/$CODEX_SESSION_ID.md

###Closing
Codex already has a strong internal notion of sessions; exposing that identity programmatically would unlock cleaner tooling, safer concurrency, and better automation with minimal implementation risk.

Thank you for considering this.

Additional information

_No response_