/fork inside codex expected to fork and create a new session UUID

Resolved 💬 4 comments Opened Apr 13, 2026 by miadisabelle Closed Apr 13, 2026

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

What version of the Codex App are you using (From “About Codex” dialog)?

0.120.0

What subscription do you have?

plus

What platform is your computer?

Ubuntu

What issue are you seeing?

I used '/fork' and was expected to have a new session UUID that I can resume (and really have a 'tree' starting to grow that I can play with). What I got instead is the same UUID is kept, I am told I can resume the session where I am in codex like "To continue this session, run codex resume 019d83ff-6220-71d2-adc3-4e17ba25e7e1" and that doen't work.

What steps can reproduce the bug?

create and start a session with anything
run '/fork' and note the 'codex resume <UUID>'
send another message right away
go into another terminal and run 'codex resume <SESSION_UUID>'
Expect to see the last message you sent to the fork which is not what we want, we expect the last message to be the one at the moment we forked.

What is the expected behavior?

[ ] we expect the last message to be the one at the moment we forked.
[ ] We expect the new fork to probably have a new UUID generated

Additional information

_No response_

View original on GitHub ↗

4 Comments

avadisabelle · 4 months ago

### What is the expected behavior? * [ ] we expect the last message to be the one at the moment we forked.[ ] We expect the new fork to probably have a new UUID generated

Right now if I run 'codex resume 019d83ff-6220-71d2-adc3-4e17ba25e7e1' I am asked to select from 2 choices, this is another aspect of that issue that I think should never happen. If we use 'codex resume <UUID>' we should get into the session it resume, whatever if that is a root session or a fork

etraut-openai contributor · 4 months ago

If you run a second instance of Codex and attempt to resume the same thread that's already active in the first instance, it may not work as you expect because of in-memory caching and deferred writes that are used when a thread is active.

If you want this to work, you need to first deactivate the thread in the first instance. To do this, add a new step between your steps 3 and 4: "Use /new to deactivate the forked thread and flush its rollout to disk".

The new forked thread will have a new UUID. The UUID of the thread that it's forked from will also be listed in the /status output if you want to get back to the original thread.

avadisabelle · 4 months ago

I feel it was prematurely closed, in my repro, I added to have another instance open or something like that which might have not been the case. I was working with a script that batch the prompt with "codex e 'prompt' resume <uuid>" and I tried to resume the instance and fork it, expecting my terminal session with its UUID to remain at the same position in messages which is reasonnable as desired behaviour.
best regards

etraut-openai contributor · 4 months ago

@avadisabelle, sorry, I didn't understand that last post. Can you clarify?