Add resume support to codex proto after removal of experimental_resume

Resolved 💬 11 comments Opened Sep 29, 2025 by Doraemonwei Closed Feb 23, 2026

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

Summary

codex proto no longer has a way to resume an existing session. Before enable-resume (#3537) we could point experimental_resume at a rollout JSONL file, but that option was removed and proto always calls ConversationManager::new_conversation.

Steps to reproduce

Record a session (e.g. via codex exec).
Launch codex proto and feed requests that expect the previous context.

Expected behavior

Provide a supported way (CLI flag or similar) for codex proto to resume a recorded rollout, analogous to codex exec resume and codex resume in the TUI.

Actual behavior

codex proto always starts a fresh conversation, so any cached context is lost and the old rollout cannot be replayed.

Additional context

commit a30e5e40ee44 (enable-resume) removed the experimental_resume config without replacing it for proto.
I’m happy to contribute a patch that adds a resume flag to codex proto if this sounds acceptable.

View original on GitHub ↗

11 Comments

pakrym-oai contributor · 9 months ago

Hi, can you please try codex exec --experimental-json (will soon become the default --json behavior) that returns thread_id in combination with codex exec resume <thread_id>?

tobymarsden · 9 months ago

Seconded -- I think Codex needs to either have codex exec support streaming input via stdin, or allow codex proto to support a --resume <id> flag. (Or both!)

pakrym-oai contributor · 9 months ago

@tobymarsden can you describe your use-case a bit?

tobymarsden · 9 months ago

@pakrym-oai just saw that proto was removed!

We're building a conversational interface with a Typescript SDK. Useful to have streaming input a la Claude Code. I've implemented it with exec in a fork assuming streaming json input will land upstream at some point...

Thanks!

pakrym-oai contributor · 9 months ago

Take a look at @openai/codex-sdk , it has initial support for continuing the conversation.

tobymarsden · 9 months ago

@pakrym-oai thanks! It looks like that will be workable once streaming input is supported in exec; I'll add support to a fork of the official SDK in the meantime

pakrym-oai contributor · 9 months ago

What do you mean by streaming input?

tobymarsden · 9 months ago

@pakrym-oai submitting user messages as JSON via stdin to a running codex exec process, so they can be interleaved in the conversation in the same way they would be via TUI. It's pretty much the only way to use codex in a rich interface outside the TUI.

This is how Claude Code does it, which works well: https://docs.claude.com/en/api/agent-sdk/streaming-vs-single-mode#streaming-input-mode-recommended

This was working via codex proto but I see proto was removed in #4520.

pakrym-oai contributor · 9 months ago

You can accomplish the same using the SDK by calling run on the Thread object multiple times.

tobymarsden · 9 months ago

@pakrym-oai It looks like that would run codex exec sequentially, waiting for task completion each time, which achieves something different from streaming input. Streaming input (previously via codex proto) can interleave new user messages into the existing agent loop, letting user input steer the conversation in close-to-real-time.

I understand why proto is being removed, but I'd love to see this added to exec before proto is retired from a release version, as the UX of a steerable conversation is amazing.

iskng · 7 months ago

Isn't the main difference here that claude code actually interjects the users message during a run while codex queues any message that is sent while running until finished and then starts another run?

If you can't interject like you can in claude code is there any point in streaming input?