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

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