`/side` chats are expiring too quickly; expiration behavior is opaque

[miraclebakelaser]

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

Version 26.527.31326 (3390)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Ephemeral /side chats expire too quickly in Codex App (not tested for CLI). Currently, side chats seem to expire after a very short period, even when the app is open and the side chat is active. Chat expiration seems to even more aggressive after recent updates. In my loose estimation, it feels like side chats expire after ~15 minutes without any way to recover them.

How I use /side: I use side chats to perform research, the conclusions of which I feed back into the main chat. Some of these conversations end up becoming very long. Unfortunately, I often get deep into a side conversation only to realize that it has been expired and unrecoverable.

Furthermore, expiration behavior is not transparent. After when is a chat supposed to expire? My expectation is that side chats not expire so long as the side chat window is open.

What steps can reproduce the bug?

Use /side in Codex App. Leave the computer for a little while and resume the conversation. Get error message "Error creating task no rollout found for thread id [..]"

What is the expected behavior?

Immediate fix: Don't expire open side chats. If open side chats must remain on a timer, then please make that timer visible to users.

Stretch goals: allow users to turn side chats into a durable fork #20262

Additional information

No response

[alik-git]

Stretch goals: allow users to turn side chats into a durable fork #20262

imho this should be a first class feature, not being able to turn side chats into full chats are a pain point in my workflow. actually, I would even consider folding the side chat functionality into fork, because it really is a different kind of fork, and I don't see the point of deleting these chats.

Thank you for the amazing work on codex btw, its fantastic.

[Nishijujuba]

Adding another data point, from Codex Desktop on Windows.

This is the same visible failure mode: an open side chat accepted a message while it still appeared usable, then task creation failed with:

创建任务时出错
no rollout found for thread id 019e8c77-b217-7fd2-818b-79100d753122

Occurrence time:

• 2026-06-03 15:51:55 +08:00 Asia/Shanghai
• 2026-06-03 07:51:55 UTC
• This timestamp is decoded from the UUIDv7 prefix of the failed side-thread id 019e8c77-b217-7fd2-818b-79100d753122.

Context:

• Parent thread: 019e8794-5b50-72f2-ae70-4458a5fa5265
• The side chat came from that parent thread.
• At the time the message was submitted, the side chat did not yet show as expired in the UI.
• Later, the UI showed the side chat as expired.

Local checks:

• The parent rollout exists locally:
  • ~/.codex/sessions/2026/06/02/rollout-2026-06-02T17-05-17-019e8794-5b50-72f2-ae70-4458a5fa5265.jsonl
• No rollout file exists for the failed side-thread id under the local ~/.codex/sessions/2026/06/03/ directory.
• Reading the failed side-thread id through the app thread API returns:
  • thread not loaded: 019e8c77-b217-7fd2-818b-79100d753122
• The failed side-thread id appears only in local UI state under prompt history / composer draft keys:
  • prompt-history.019e8c77-b217-7fd2-818b-79100d753122
  • composer-prompt-drafts-v1.local:019e8c77-b217-7fd2-818b-79100d753122
• It does not appear as a recoverable thread entry such as a projectless thread id, workspace-root hint, queued follow-up, or output directory mapping.

This makes it look like the renderer/composer accepted and retained the user's side-chat input, while the backing ephemeral side-thread had no materialized rollout and was no longer loadable by the app-server path used to create the task.

Expected behavior: if a side chat is still visible and accepts input, submitting should either start the task successfully or the UI should block submission with an explicit expired-state message before accepting the input. If side chats are intentionally ephemeral, the expiry window should be visible or the side chat should be promotable/persistable before input is lost.

I am avoiding full rollout files, DB dumps, or the exact user prompt content because they may contain private project context.