Allows specifying a SessionID for better embedding of automated workflows.

Open 💬 8 comments Opened Dec 10, 2025 by RonxBulld

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What feature would you like to see?

In my automation workflow, I sometimes need to capture the session ID before resuming in the pipeline backend or during the previous iteration. This used to be inelegant, as I had to capture the session ID from the Codex exec output. Referring to ClaudeCode's --session option, we can specify the session ID from outside the Codex exec startup process. Codex then checks and validates the specified ID to ensure its availability. This is a very elegant and useful feature for automation.

Additional information

_No response_

View original on GitHub ↗

8 Comments

etraut-openai contributor · 7 months ago

If I understand your feature request correctly, I think it's already being tracked in #1780.

RonxBulld · 7 months ago

If I understand your feature request correctly, I think it's already being tracked in #1780.

Thanks for your attention, but these two threads are still different. #1780 essentially captures the Session ID managed internally by Codex from the output of an already started session, and will still output the session ID in non---json mode. This is the method I'm currently using. My idea is to have an external tool manage the session ID, avoiding capturing and parsing the string from the output of codex exec.

etraut-openai contributor · 7 months ago

Thanks for the clarification.

jbonatakis · 5 months ago

I would also like to see something like this implemented. To clarify, when using Claude Code the correct flag to set the session ID is --session-id (ex. claude -p --session-id 550e8400-e29b-41d4-a716-446655440000 "Prompt text"). Rather than parsing the session ID from json output, you can keep your output configured however you want but always retain awareness of the session ID without parsing, as you yourself provided it.

This makes storing the session IDs and later resuming sessions very simple and easy. Right now the workaround with Codex is to parse ~/.codex/sessions which is very possible but is a bit of a hacky workaround that it would be better to avoid.

So something like: codex exec --session-id 550e8400-e29b-41d4-a716-446655440000 "Prompt text"

RonxBulld · 5 months ago

I would also like to see something like this implemented. To clarify, when using Claude Code the correct flag to set the session ID is --session-id (ex. claude -p --session-id 550e8400-e29b-41d4-a716-446655440000 "Prompt text"). Rather than parsing the session ID from json output, you can keep your output configured however you want but always retain awareness of the session ID without parsing, as you yourself provided it. This makes storing the session IDs and later resuming sessions very simple and easy. Right now the workaround with Codex is to parse ~/.codex/sessions which is very possible but is a bit of a hacky workaround that it would be better to avoid. So something like: codex exec --session-id 550e8400-e29b-41d4-a716-446655440000 "Prompt text"

Yes, this is an effective workaround and works well in most cases. It requires ensuring that Codex is not started in parallel, regardless of whether it's in the same working directory.

jbonatakis · 5 months ago

It requires ensuring that Codex is not started in parallel

Personally this breaks my use case. For the application I'm building I need to be able to run multiple instances concurrently and retain the ability to resume any session at a later point.

RonxBulld · 5 months ago

> It requires ensuring that Codex is not started in parallel Personally this breaks my use case. For the application I'm building I need to be able to run multiple instances concurrently and retain the ability to resume any session at a later point.

Does the Codex SDK or PTY meet your needs?

jemdiggity · 3 months ago

+1 I'm building an agent orchestrator and it's helpful for 2 scenarios.
1) helpful in resuming deleted agent tasks.
2) helpful in providing a pre-warmed agent that has the full context of the repo that it's working on.
https://github.com/jemdiggity/kanna