codex exec resume silently starts a new thread when given an ephemeral session id

[aquiles-ai123]

codex exec resume silently starts a new thread when given an ephemeral session id

Summary

If I run codex exec --ephemeral, capture its thread_id, and then pass that id to codex exec resume, Codex does not report that the ephemeral session is unavailable.

Instead, it silently starts a brand-new thread with a different thread_id and no prior context.

That is misleading because the provided session id looks accepted, but the resumed run is not actually attached to that session.

Repro

Create an ephemeral session:

codex exec --ephemeral --skip-git-repo-check --color never --json -C /home/cryptotrading74 \
  "Reply with the single word ok and stop." \
  > /tmp/codex_ephemeral_probe.jsonl

Observed transcript:

{"type":"thread.started","thread_id":"019d1c08-c1b4-70c2-955f-840a5022c017"}
{"type":"item.completed","item":{"id":"item_0","type":"agent_message","text":"ok"}}

Now try to resume that ephemeral session id and ask about the previous reply:

codex exec resume 019d1c08-c1b4-70c2-955f-840a5022c017 --json --skip-git-repo-check \
  "What was your previous one-word reply in this session? Answer with just that word." \
  > /tmp/codex_resume_ephemeral_probe.jsonl

Observed transcript:

{"type":"thread.started","thread_id":"019d1c09-942e-78c3-9a83-06c571abddc8"}
{"type":"item.completed","item":{"id":"item_0","type":"agent_message","text":"None"}}

Two problems are visible:

• the resumed run starts a different thread_id
• it does not have the prior ok context

Control

The normal non-ephemeral path resumes correctly.

Create a regular session:

codex exec --skip-git-repo-check --color never --json -C /home/cryptotrading74 \
  "Reply with the single word zebra and stop." \
  > /tmp/codex_resume_control_seed.jsonl

Observed thread:

{"type":"thread.started","thread_id":"019d1c0a-0137-73f3-bf4a-88c90739150c"}

Resume it:

codex exec resume 019d1c0a-0137-73f3-bf4a-88c90739150c --json --skip-git-repo-check \
  "What was your previous one-word reply in this session? Answer with just that word." \
  > /tmp/codex_resume_control_check.jsonl

Observed transcript:

{"type":"thread.started","thread_id":"019d1c0a-0137-73f3-bf4a-88c90739150c"}
{"type":"item.completed","item":{"id":"item_0","type":"agent_message","text":"zebra"}}

So resume itself works; the broken behavior is specific to passing an ephemeral session id.

Expected behavior

One of these should happen:

• codex exec resume <ephemeral-id> should fail clearly with a "not found / ephemeral sessions are not resumable" style error
• or, if ephemeral sessions are intended to be resumable during the current process lifetime, it should actually resume the same thread and preserve context

Actual behavior

codex exec resume appears to accept the ephemeral session id, but silently starts a new thread with no prior context.

Why this matters

This is easy to misread as a successful resume. Automation or humans can believe they resumed a session when they actually started a fresh one.

Files / artifacts

• /tmp/codex_ephemeral_probe.jsonl
• /tmp/codex_resume_ephemeral_probe.jsonl
• /tmp/codex_resume_control_seed.jsonl
• /tmp/codex_resume_control_check.jsonl

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• codex exec resume accepts nonexistent session ids and starts a new thread instead of failing #15539

Powered by Codex Action

[middleDuckAi]

Repro

• Reproduced the explicit-resume fallback problem on current main.
• This same failure path covers both #15538 and #15539: explicit codex exec resume <id> was silently starting a new thread when the requested target was missing.

Root Cause

• Explicit resume ids were sharing the same fallback path as resume --last.
• I prepared one scoped fix that makes explicit missing targets fail with Session not found: <id> while leaving resume --last behavior unchanged.

Validation

• cargo fmt --all
• cargo test -p codex-exec resolve_resume_target
• cargo test -p codex-exec exec_resume_by_missing_id_fails_without_starting_new_session
• cargo test -p codex-exec exec_resume_by_ephemeral_id_fails_without_starting_new_session

Risk

• Low. The change is intentionally scoped to explicit resume targets and leaves the resume --last path alone.

Maintainer Pickup

gh pr create --repo openai/codex --base main --head middleDuckAi:middleDuck/codex-15538-15539-resume-missing-session --title "$(gh pr view 3 --repo middleDuckAi/codex --json title --jq .title)" --body "$(gh pr view 3 --repo middleDuckAi/codex --json body --jq .body)"

[etraut-openai]

We recently reimplemented "exec" on top of the app server API, and I think we fixed this bug in the process.

[Naiym223]

Still experiencing this.

[etraut-openai]

@Naiym223, if you think you're seeing this, please open a new issue and provide the requested details in the bug report.