Continuing a sidebar conversation in a new task fails with "no rollout found"

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

• #36060

Powered by Codex Action

I reproduced the same issue on Codex Desktop 26.721.81911 on Windows and traced the app-server sequence. This appears to be a persistence/routing bug involving a temporary child thread, rather than an endpoint or authentication failure.

Reproduction thread IDs from this run:

• Source: 019fb98a-6a97-7af1-b186-169f06f1c64d
• Forked child: 019fb98a-bf4f-7871-87d1-51a41c8ca097

Observed sequence:

1. thread/start for the source thread succeeded (errorCode=null).
2. The first thread/fork succeeded and returned the child ID above.
3. thread/inject_items succeeded.
4. A turn on the child thread started and completed successfully.
5. A subsequent thread/fork from that child failed twice with:

errorCode=-32600
no rollout found for thread id 019fb98a-bf4f-7871-87d1-51a41c8ca097

The forked child had no corresponding rollout JSONL, session_index.jsonl entry, or state_5.sqlite thread row. It looks like the child was routed as a temporary IAB/browser-use conversation, but the desktop UI later treated it as a normal forkable thread.

The successful child turn connected to the official endpoint:

wss://chatgpt.com/backend-api/codex/responses

The log reported ChatGPT auth mode and no OPENAI_API_KEY environment authentication. I also reproduced this after deleting the config and allowing the official app to generate a fresh one; the captured fresh config contained no custom model_provider, openai_base_url, or custom provider section.

Relevant local log sequence was around 2026-07-31T18:58:04Z–18:58:52Z:

• source thread/start succeeds
• first thread/fork succeeds
• child turn succeeds
• second and third thread/fork attempts return no rollout found

This suggests the fix may need either:

• persisting the temporary child as a normal rollout before allowing another continuation/fork, or
• preventing the UI from calling thread/fork on a non-persisted temporary child and using the correct route/fallback instead.

Thanks for looking into this.

My intended workflow was to take the temporary child conversation in the sidebar, click “Continue in a new task”, and then choose either “Use this workspace” or “Use a new worktree” to continue the conversation.

I tested both UI options, and both fail with the same “no rollout found for thread id” error.

The two implementation approaches you mentioned both sound reasonable from a user perspective: either persist the temporary child as a normal rollout before allowing another continuation/fork, or avoid calling thread/fork on a non-persisted temporary child and use the appropriate route or fallback. In either case, I would expect both UI options to create a working continuation task.

I was using Codex App 26.721.41059 on Windows. I have not yet tested a newer version. If one of these fixes has already shipped, could you let me know which version I should try?

Thanks. I tested this again on Windows with the current installed Codex App build 26.727.6591, and the issue is still reproducible.

The same workflow still fails when trying to create/continue another task from the temporary child conversation. The UI shows 创建聊天未成功 / “Failed to create chat”. Therefore, updating from 26.721.41059 or 26.721.81911 to 26.727.6591 does not resolve the issue based on this test.

I have not found a newer Windows app build available to test at this time. The issue remains open and I have not seen confirmation that a fix has shipped yet.

When continuing a sidebar conversation fails with no rollout found, it typically means the session index points to a missing or relocated .jsonl rollout file.

You can inspect the entire local session inventory and check whether the rollout file exists on disk under another path using Codex Rescue:

npx --yes codex-rescue sessions

Or run doctor on the latest session:

npx --yes codex-rescue doctor --latest

It operates strictly read-only and local-first. If you try it, the finding codes or session list output would be very helpful.

When continuing a sidebar conversation fails with no rollout found, it typically means the session index points to a missing or relocated .jsonl rollout file. You can inspect the entire local session inventory and check whether the rollout file exists on disk under another path using Codex Rescue: npx --yes codex-rescue sessions Or run doctor on the latest session: npx --yes codex-rescue doctor --latest It operates strictly read-only and local-first. If you try it, the finding codes or session list output would be very helpful.

npx --yes codex-rescue sessions
codex-rescue: platform package codex-rescue-win32-x64 is not installed. This Alpha5 prerelease expects npm to install the matching optional dependency.

Thanks for trying this earlier @CuSO41108. The Windows launcher failure you hit was on the Rescue side and is fixed in the current Alpha6 field-fix release (0.1.0-alpha.6-3).

If you're willing to retry, these read-only commands should now launch normally on Windows:

npx --yes codex-rescue --version
npx --yes codex-rescue sessions
npx --yes codex-rescue doctor --latest

One correction to my earlier wording as well: no rollout found does not by itself prove that a rollout JSONL was deleted or relocated. A temporary child may never have been durably persisted at all, or there may be index/path divergence. Rescue now keeps those cases separate instead of assuming missing data.

Sanitized finding codes/output are enough.

@CuSO41108

Thanks for the field report — that launch failure is fixed in the just-released 0.1.0-alpha.7.

The root cause was a platform-package name mismatch: the launcher was looking for codex-rescue-win32-x64, but the published Windows binary package is codex-rescue-windows-x64. The launcher now resolves codex-rescue-windows-x64 first (with the old name kept as a fallback), and codex-rescue-windows-x64@0.1.0-alpha.7 is published on npm.

To verify on your machine:

npx --yes codex-rescue@0.1.0-alpha.7 sessions
npx --yes codex-rescue@0.1.0-alpha.7 doctor --latest

Both should now launch on Windows x64 instead of erroring with "platform package ... is not installed". Still strictly read-only and local-first. If it still misbehaves for you, the finding codes or the exact error would be very helpful.

The old optional-package naming failure is retired in Vetto: the npm package contains its native Windows binary directly, and Windows build/test/clippy are green.

Migration update: active Codex Rescue development has moved to Vetto: https://github.com/shleder/vetto. The standalone shleder/codex-rescue repository remains public as compatibility history. User installation is now npm install --global @shleddy/vetto@next, with recovery under vetto rescue. The boundary remains read-only/copy-only and does not modify session JSONL or vendor SQLite. The newest diagnostic changes are merged into Vetto main and will be included in a later npm alpha; no source install is requested.