[CODEX-SYNC] deferred: parent rollout has not reached the child fork moment - cc-switch
Quick fix
A cc-switch 3.18.0 Codex sync defect: a finished parent rollout older than the child fork timestamp defers forever. No fix yet — avoid creating forks.
Symptom
Section titled “Symptom”[2026-07-23][18:19:52][WARN][cc_switch_lib::services::session_usage_codex] [CODEX-SYNC] deferred .codex\sessions\2026\05\07\rollout-2026-05-07T09-42-03-019e0019-608d-7372-8189-13b217862438.jsonl: 父 rollout .codex\sessions\2026\05\07\rollout-2026-05-07T09-39-08-019e0016-b5c7-7773-a2b2-0047870b1948.jsonl 尚未写到 child fork 时刻A warning from the Codex usage sync: the parent rollout file has not yet been written up to the child fork moment, so this rollout is deferred.
In the 3.18.0 Codex usage sync, parent rollout signature parsing rejects the parent file when `max_timestamp < child_fork_cutoff`. The caller then calls `mark_deferred(...)` and returns immediately, so the child rollout's token events are never imported and the sync cursor never advances. If the parent session ended long ago and sat idle before a child session forked it, it can never "reach the child fork moment", so the same batch of files is deferred again every minute and real billed usage after the fork can go missing indefinitely. #5626 only fixed duplicate parsing and deliberately kept the timestamp check that triggers this, so the defect remains open on its own.
This cluster also mixes in several "imported/synced but not visible" variants — do not apply their fixes to this warning. Codex history is isolated into `openai` and `custom` buckets by `model_provider`, so official and third-party do not share by default. Some skills sync failures were said to be resolved by changes in v3.16.0, with maintainers asking people to verify on v3.16.2+. "The config is still on the C drive" across machines is the local Tauri Store pointer not migrating with the sync directory. And Claude history shrinking is usually explained by `cleanupPeriodDays: 30` or endpoint/account filtering rather than cc-switch deleting anything.
First confirm this is really your problem: version 3.18.0, the log repeatedly showing `[CODEX-SYNC] deferred ... parent rollout ... has not reached the child fork moment`, and the same file deferred again on every sync.
If confirmed, treat it as a known unfixed defect. #5626 only reduces duplicate parsing and does not lift this timestamp check — do not expect a version containing #5626 to fix it on its own.
While waiting for a dedicated fix, avoid creating new forks. Users found that double-tapping Esc in the TUI to pick an earlier session automatically creates a fork, which then gets marked permanently retryable and carries ongoing IO cost.
Do not edit `%USERPROFILE%\.codex\sessions` to "nudge" the sync. The issues only show that deferred skips child rollout import and cursor updates; none offers a safe way to hand-edit session files.
If what you actually want is shared sessions between official and third-party, treat it separately: providers with the same name can share, while official openai stays isolated from the rest. The current unify is a one-way migrate/restore, and two-way mirroring is only a proposal in #5851, not a released fix.
If part of your skills sync fails, upgrade to v3.16.2 or newer and retest. If it persists, reopen the original issue with the version, config, and reproduction steps as maintainers ask.
Affected Versions
Section titled “Affected Versions”Source Issues
Section titled “Source Issues”This page is distilled from 10 real issues
- #1475win-codex；cc-switch-v3.12.2无法导入当前配置；但是实际配置可以识别到。对话，mcp都可以找出，但是页面如下：
- #2393Claude code的skills同步到桌面版Codex，还有Hermes agent，有的skills会同步不成功
- #2603codex切换账号后暂无对话
- #3149openai官方和自定义的提供商无法共享会话
- #3269该软件的配置数据丢失以及和百度网盘同步空间的数据在两台电脑没完全同步
- #3350关于部分历史会话消失
- #4313用zip导入的skill删除了不会消失，还是会在skills管理中显示出来
- #4794skill同步问题和多处安装问题。
- #56873.18.0 Codex sync permanently defers completed parent when fork occurs after idle gap
- #5851Codex Session Unify: bidirectional sync instead of one-time migrate/restore
- Can official openai and a custom provider share sessions?
- Users found sharing works as long as the provider names match — both called custom, for example — but official openai stays isolated from the others. #5851 explains the current unify is a one-way `openai`→`custom` migrate/restore, with two-way sync still only a proposal.
- I had a lot of history on default, and it all vanished after switching to another provider. Were the sessions deleted?
- That is a different thread. Maintainers classified #2603 as sessions being invisible or unusable after a Codex provider switch, and folded it into #2248 for tracking.
- Some history is missing when I reopen it. Does cc-switch restore or delete it?
- Maintainers investigated and say cc-switch never writes to or deletes `~/.claude/projects` transcripts. The usual causes are Claude Code's default `cleanupPeriodDays: 30` cleanup, or the client filtering by current endpoint/account. Raise `cleanupPeriodDays` and check the on-disk .jsonl with `claude --resume`.
- I synced the directory to a second machine, so why is the config still on the C drive as if freshly installed?
- The CC Switch config directory override is a machine-level Store setting and does not travel with the sync directory. On the second machine, point it at the same sync directory by hand, save, and restart before it reads that directory's database and skills. Comments suggest WebDAV for reliable cross-device use rather than syncing a live SQLite file.
- Can I configure cc-switch on one machine and use it from others over the LAN?
- #2223 only raises the request; the issues reach no conclusion on whether it is supported.
Related problems
Section titled “Related problems”This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.