Persist side chats as child threads attached to the main thread

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

• #25233

Powered by Codex Action

Agree! +1

My required workflow is not only persisting a single side chat. A parent
thread should be able to own multiple durable side threads.

Each side thread should:

• have a stable ID and title;
• survive app/CLI restarts and updates;
• remain isolated from the main thread's context;
• remain visibly attached to its parent thread;
• be independently resumable;
• optionally be promoted to a normal top-level fork.

The persistence model should support multiple child side threads even if
the first UI implementation only exposes one at a time. A later MVP could
add /side new, /side list, /side switch, and /side promote, similar
to the proposal in #22307.

When the main thread is forked, its side threads should not be silently
merged into or copied into the new fork. They should remain explicit child
branches unless the user chooses to copy or promote them.

This would also fit naturally into the conversation-tree model discussed
in #12450.

threads also seem confused when you ask about side chats:

• side chats can't spawn or message threads
• threads can't find or message side chats
• JSONL session logs don't tie main threads to side chats cleanly

the result is usually just copy-pasting the side chat, its session ID, and asking a new thread to mine JSONLs. but very inefficient. lots of "Hello" messages to side chats to test if they're expired or active -- few/zero config TOML settings for controlling side chats:

• allowing subagents
• thread tools (e.g. inter-session messaging)
• write/manipulate permissions for side chats
• expiry controls
• setting Goals on side chat or main thread

anyone have advice? i know i'm doing it wrong, but these two constraints have me gravitating towards the dangerous side chats:

• main thread needs to stay clean/uninterrupted
• i need the main thread context

so messaging thread for dossier/handoff causes loss of focus, and mining its session logs to reconstruct context in new session is more lossy than side chats.

Adding a real-world Codex Desktop workflow where durable side chats are especially important:

1. Keep a long-running main task active as the execution thread.
2. Open a side chat attached to it to inspect progress, discuss the next step, and make decisions without interrupting or polluting the main task.
3. Once the plan is agreed, use the side chat to coordinate or instruct the main task to continue.
4. Restart the ChatGPT/Codex desktop app.
5. The side-chat transcript is no longer recoverable, and the working relationship between the planning thread and execution thread is lost.

In this workflow, the side chat is not just a disposable question. It is the planning and decision-making context, while the main task is the execution context. Reconstructing that context in a new side chat requires repeating the project state, constraints, and prior decisions, and can cause important constraints to be omitted or later actions to contradict earlier conclusions.

The most important requirement is therefore not only transcript retention, but preservation of the parent/child relationship:

• Side chats should survive app restarts and updates.
• Each side chat should have a durable ID and remain attached to its parent task.
• The parent task should expose an "Associated side chats" / "Reopen side chat" entry.
• Restoring the previously open main-task/side-chat layout would be ideal.
• Closing a side chat should hide or archive it; permanent removal should require an explicit delete action.
• If persistence cannot be the default initially, a per-side-chat "Keep this side chat" action would be a useful minimum.

This would make the "side chat for planning, main task for execution" workflow reliable for long-running, complex, multi-stage work.

+1 100%, very well written argument and 100% needed.

I use side chats a bit differently, and it has become one of the most useful parts of Codex for me.

While an agent is working in the main task, I keep the side chat open as a repo-aware project manager and thinking partner. I use it to discuss progress, decide next steps, prepare prompts for other agents, and delegate work without interrupting the main task.

Because it already understands the repository and the surrounding task context, it works extremely well for this. The only real problem is that the conversation is temporary and eventually disappears.

A way to pin or save a side chat, reopen it later from the project, and optionally promote it to a normal task would make this workflow much more reliable. Keeping a reference to the parent task would also be valuable.

Side chats are already very close to being a lightweight supervisor or orchestration layer for people running several agents in parallel. Persistence would make that use case much more practical.

@alexanderxcmo Yeah, this is pretty much how I use it too.

While the main task is working, I use the side chat to talk through what to do next. Once we've worked out the plan, I ask it to turn the discussion into a better prompt for the main task. That way I don't have to keep going back to the main task to discuss things, and its context stays cleaner.

I also remember that side chats used to be able to send the prompt directly to the main task, so I didn't even have to copy and paste it. At some point that stopped working for me, and now I have to move it over manually, which is a shame.

So for me, a side chat isn't just a temporary chat window. It's more like a project-aware planning assistant. Being able to save it, reopen it later, and send messages directly to the main task again would make this workflow much nicer.

Additional product gap: implementation intent should route back to the parent task

I am seeing a related workflow failure in the macOS Codex app.

Workflow

1. In a main task, I open a side chat to discuss an implementation plan.
2. I refine the plan in that side chat and then ask it to implement the agreed approach.
3. The implementation begins in the side chat's separate thread/fork instead of being dispatched to the original main task.

Why this is a problem

The side chat is useful for lightweight planning, clarification, and choosing an approach. But once implementation is requested, the work needs the original task's context, history, workspace, and ownership.

Starting implementation in the side chat unexpectedly splits one intended task into two threads. The result is duplicated or fragmented context, and I have to manually transfer the decision back to the original task. It is especially confusing because the fork was not an explicit user choice.

This is an unintended thread fork. It is not necessarily a Git worktree or a repository clone; those are separate concepts and should only be created when explicitly selected.

Expected behavior

Please add an explicit parent-task dispatch path:

• A side chat can remain a lightweight planning surface.
• When the user asks to implement a plan formed in that side chat, Codex should offer or default to “Implement in parent task”.
• That action should send the implementation request, including the relevant plan/context, to the original main task.
• The parent task should retain its original workspace and execution history.
• Creating a separate fork/worktree for implementation should require an explicit choice such as “Implement in a separate fork/worktree.”

The current behavior makes a planning conversation behave like an accidental implementation branch, which defeats the purpose of using side chat to keep planning separate from the main execution thread.

Environment

• Codex desktop app: 26.727.51351 (build 6119)
• Platform: macOS (Apple Silicon)
• Observed: August 2026

@alexanderxcmo Yeah, this is pretty much how I use it too. While the main task is working, I use the side chat to talk through what to do next. Once we've worked out the plan, I ask it to turn the discussion into a better prompt for the main task. That way I don't have to keep going back to the main task to discuss things, and its context stays cleaner. I also remember that side chats used to be able to send the prompt directly to the main task, so I didn't even have to copy and paste it. At some point that stopped working for me, and now I have to move it over manually, which is a shame. So for me, a side chat isn't just a temporary chat window. It's more like a project-aware planning assistant. Being able to save it, reopen it later, and send messages directly to the main task again would make this workflow much nicer.

+1 from me. I have the exact same workflow.

The persistence request would be stronger if side chats were modeled as durable branches with explicit state inheritance, rather than only persisted transcripts.

A child-thread record needs at least:

child_thread_id
parent_thread_id
fork_event_id
inherited_context_hash
created_at
last_event_cursor
lifecycle_state: active | archived | promoted | deleted

The important field is fork_event_id: it defines exactly which parent state the side chat inherited. Without that boundary, a restored side chat can appear attached to the current parent while actually reasoning from an older snapshot, and neither side can explain the divergence.

I would keep three artifacts separate:

1. Child transcript — what happened inside the side chat.
2. Branch manifest — parent, fork boundary, lifecycle and current head.
3. Return artifact — explicit decisions/findings the user chooses to send back to the parent, each carrying source child event IDs.

That avoids silently merging side-chat conclusions into the main thread. Promotion to a top-level fork changes the manifest; it should not rewrite transcript lineage.

A compact restore flow could then be:

load branch manifest → verify parent/fork event exists → load child delta → mark parent divergence since fork → resume

This also gives thread tools a reliable lookup surface instead of forcing models to mine JSONL files or send probe messages to discover whether a side chat still exists.

I maintain a small local-first project implementing related provenance primitives—stable project identity, source path/line, content hashes, SQLite state and source-linked context packs: https://github.com/leadingproblemsolver/living-context-engine

It is not a conversation-tree implementation, but the separation between durable records and generated retrieval artifacts may be useful here.

Related: #22707

That request was closed, but if this issue changes side chats into durable child threads with stable IDs and parent relationships, it would remove much of the architectural limitation cited in #22707.

It would be worth considering cross-client visibility as part of the persisted-child-thread model, so an attached side chat could eventually be reopened not only after a Desktop restart but also from Remote Control clients such as ChatGPT on iOS

I hit this as real data loss in Codex Desktop: a substantial side-chat investigation tied to ongoing implementation work disappeared, and there was no persisted thread/session record available to resume or reconstruct it reliably.

Side chats should be treated as normal durable threads with additional lineage metadata—not as disposable UI state. At minimum, each side chat should have:

• its own stable thread ID and persisted transcript;
• a durable link to its parent thread and fork point;
• an entry under the parent for reopening/resuming it;
• normal archive/delete semantics, so closing the panel never deletes history;
• an optional action to promote it to a top-level thread.

The parent link is essential: the value of a side chat is that it inherits the parent context while keeping an investigation or planning path separate. Persistence without that relationship would still lose the workflow.

Totally agree!
Ideally, I hope in the Codex APP (GUI), side chats could be shown as notes waiting to be unfolded, inserted to the main thread when they start.

I opened a separate feature request focused on the missing creation flow:

#40941 — Allow users to create subagents directly from the Subagents panel
https://github.com/openai/codex/issues/40941

The distinction is that #26227 focuses on persisting side chats as child threads, while #40941 proposes a visible + button that lets users start a subagent side chat directly, without first asking the main session to create it.

The key workflow is to keep the subagent prompt and intermediate work isolated from the main context, send only a lightweight existence/status notification to the main session, and hand the completed output back for the main session to review or continue with. This avoids bloating or delaying a large primary task while still keeping the work linked.