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

[clevere-msa]

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

[labibrahman]

related to #5912

[jazzyalex]

good idea. my tool Agent Sessions https://github.com/jazzyalex/agent-sessions could use it

[etraut-openai]

The Codex CLI exposes a JSON-based API surface that we refer to as the App Server. This is what the Codex VS Code Extension (and the recently-announced JetBrains IDE extension) are built on. This API surface exposes many details including the list of active sessions (along with their session IDs, event streams, etc.). If you are building tools or applications on top of Codex, we recommend using this API surface.

[etraut-openai]

In the next release, the thread ID will available in an environment variable named CODEX_THREAD_ID. See this PR for details.