Forking kind of works, but it seems to catastrophically merge conversations when forking more than once, even on the latest CLI update of today, at least on my system. Maybe that’s only a bug on my system.
It would be helpful to have a way to robustly reuse context as the basis for a new conversation, whether that’s part of the fork feature or a different one.
Codexometer has a copy function? Explicitly ask codex to write out a handoff with a specific scope and then copy the result, paste it into a new session?
I assume this will make the new session rebuild (from scratch) its memory representation of the actual context that matters ― whatever parts of the codebase which it loads to memory and builds context of in light of the prompt.
/memories turns memory on - new sessions inherit this recording, however created.
It is a separate channel to compaction.
So my theory is if you manually create a hand-off using a sensible prompt, you might not lose a lot with memory on.
Manually creating a hand-off definitely loses the history of tool calls and results (though these are in any case usually truncated).
In any case if you /fork you will take with you both any compaction and start with any memory. If you fork pre-compaction I believe it inherits the whole conversation.
In any case can you clarify what you mean by “catastrophically merge conversations"? What unexpected results are you seeing - can you provide a detailed example?
What do you mean by “forking more than once”? Are you resuming the parent before forking again or are you forking a fork?
Reading this thread, I’m wondering whether the longer-term solution might be slightly different from making conversation forking itself more robust.
Forking is very useful when branching from a particular session, but for long-running projects it may be more useful to have a persistent project-context layer that exists independently of any individual conversation. It could hold the current decisions, requirements, constraints, project state and relevant handoffs, while new Codex sessions would retrieve only the context relevant to their task.
Personally, I would take this a little further. ChatGPT could be the place where ideas, decisions and requirements are developed, while AI continuously maintains a persistent project-context layer from those conversations. That context could then be used to create concrete tasks in a tool such as Linear, which could be delegated to Codex. After the task is completed, Codex or another agent could update the task status, while the resulting code changes and implementation state could feed back into the project context.
In that model, we would not need to keep transferring entire conversation histories between sessions. Different agents would instead consume the same current, selective project context.
This seems somewhat related to the “summarized project-level context layer” mentioned in the linked shared-context feature request, which OpenAI Support also seemed to view as a useful direction.
I’m curious how others see this: for larger projects, do we really need increasingly sophisticated conversation forking, or do we ultimately need persistent project context that can be shared across ChatGPT, Codex and other operational tools?
This is somewhat already a ChatGPT feature by default kind of, in my subscription at least: it knows a ton about your projects and automatically brings in knowledge from past conversations when it makes sense.
That said, the original thread is more about reproducing code-ready context in a code development context.