›_ Codex Issues
Codex Issues / #26227

Persist side chats as child threads attached to the main thread

Open 💬 6 comments Opened Jun 3, 2026 by winnal
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What problem would this solve?

Side chats are currently one of the best interaction patterns in Codex for long-running work, but they are intentionally ephemeral. That means useful side-chat context disappears when the session/app is closed or the app is updated.

This is painful because side chats are not just a less-visible form of fork. They are tightly tied to the main thread and are especially useful while the main thread is still actively running. In a long-running turn that may take hours, a user can open a side chat immediately to inspect or ask about the current state without interrupting the main task. By contrast, ordinary forking/new-thread workflows feel heavier and do not preserve the same anchored “side of this main thread” interaction model.

The result is that users who rely on side chats have to choose between:

  • keeping the current app/session alive indefinitely to avoid losing side chats, or
  • upgrading/restarting and permanently losing side-chat context, or
  • using full forks/new threads even when the desired workflow is explicitly a side conversation attached to the main thread.

Current behavior / source-backed understanding

From the current source, /side is explicitly implemented as ephemeral:

  • /side is described as “start a side conversation in an ephemeral fork”: codex-rs/tui/src/slash_command.rs.
  • codex-rs/tui/src/app/side.rs describes side conversations as ephemeral forks used for quick side questions.
  • side_fork_config() sets fork_config.ephemeral = true.
  • Side threads are discarded from local app state when switching away/closing.
  • The app-server README documents ephemeral: true as an in-memory temporary thread/fork whose thread.path is null.

Relevant references at the inspected HEAD (10b4080):

I also saw related prior discussion where /side being intentionally ephemeral was treated as the current product stance. This issue is therefore a feature request to add a durable side-chat mode/model, not a claim that the current implementation is accidentally ephemeral.

Suggested behavior

Please support persisted side chats as first-class child conversations attached to the main thread.

Ideally:

  • Side chats survive app updates, app restarts, and session reloads.
  • A main thread shows its associated side chats in context, rather than side chats only existing as temporary renderer/app-server state.
  • Side chats preserve the same lightweight UX and parent-thread anchoring that makes /side useful today.
  • Creating a side chat during an active main-thread turn remains possible.
  • Persisted side chats should be distinguishable from full independent forks: they are side branches of a main thread, not separate top-level conversations unless explicitly promoted.
  • Users should be able to resume/reopen a side chat from the main thread after a restart/update.

Possible implementation shapes:

  • Persist side chats as child threads with parentThreadId / forkedFromId metadata and a rollout path, but keep them grouped under the parent in the UI.
  • Add a “promote side chat to full fork” affordance for users who want to detach one.
  • If full persistence is too heavy by default, offer a setting or per-side-chat action such as “Keep this side chat.”

Why full forks/new threads are not an equivalent replacement

Forks/new threads are useful, but they do not replace side chats ergonomically:

  • Side chats are explicitly tied to the main thread, so they preserve mental locality.
  • Side chats can be opened while the main task is running, without steering or interrupting the main turn.
  • A user may want a lightweight explanation, inspection, or alternate thought path without polluting the main thread.
  • For long-running turns, waiting for the main turn to finish before organizing or forking context can be impractical.

Expected outcome

Users should be able to use side chats as durable context attached to a main thread, without losing them on update/restart and without being forced into heavier full-fork workflows.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 month ago

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

  • #25233

Powered by Codex Action

alik-git · 1 month ago

Agree! +1

GabCores · 1 month ago

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.

justinTM · 11 days ago

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.

sh3nz1h3ng-hash · 4 days ago

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.

atIOCrON · 19 hours ago

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