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

[aquiles-ai123]

codex exec resume accepts a nonexistent session id and starts a new thread instead of failing

Summary

If I pass a UUID that does not correspond to any existing session into codex exec resume, Codex does not return a "not found" style error.

Instead, it starts a brand-new thread, runs the prompt normally, and exits 0.

That makes resume unsafe for automation because a typo or stale id can silently create a fresh session instead of failing loudly.

Repro

Use a UUID that does not exist:

codex exec resume 00000000-0000-0000-0000-000000000000 --json --skip-git-repo-check \
  "Reply with the single word ghost and stop." \
  > /tmp/codex_resume_nonexistent_probe.jsonl
printf "outer_exit=%s\n" "$?"

Observed transcript:

{"type":"thread.started","thread_id":"019d1c0b-6504-7b32-8ac6-74d98b92a141"}
{"type":"item.completed","item":{"id":"item_0","type":"agent_message","text":"ghost"}}

Observed shell exit:

outer_exit=0

The thread_id in the transcript is not the requested UUID. Codex silently started a fresh thread instead of reporting that the requested session id does not exist.

Control

A real session id does resume correctly.

Create a normal 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 the broken behavior is not "resume always creates a new thread"; it happens specifically when the requested id is missing.

Expected behavior

If the requested session id does not exist, codex exec resume should fail clearly with a nonzero exit code and a "session not found" style message.

Actual behavior

codex exec resume accepts the nonexistent id, creates a new thread, completes the turn, and exits 0.

Why this matters

This is dangerous for scripts and operators because a stale or mistyped resume id can look successful while actually starting a fresh conversation.

Related

I also reproduced the same symptom with an ephemeral exec session id in #15538. That appears to be a specific instance of the more general "missing session id silently creates a new thread" behavior.

Files / artifacts

• /tmp/codex_resume_nonexistent_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 silently starts a new thread when given an ephemeral session id #15538

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]

Thanks for the bug report. This has recently been fixed.