Codex Desktop worktree/fork replay still counted as current-day usage in ccusage 20.0.14 #1337

What happened?

Codex Desktop worktree/fork session replay still appears to be counted as new current-day usage in [email protected].

This looks related to previously closed issues/PRs such as #988, #1175, #1288, #950, and #989, but it is still reproducible for a Codex Desktop worktree/fork session on the latest npm release.

Environment:

• OS: Windows
• Tool: ccusage
• Versions tested: 20.0.13 and 20.0.14
• Source: Codex Desktop local JSONL logs
• Timezone: Asia/Shanghai
• Speed: standard

Actual result for 2026-06-18:

totalTokens: 62,586,180
costUSD:     82.589102
inputTokens: 9,092,122
cacheRead:   53,142,144
output:      351,914
reasoning:   142,539
model:       gpt-5.5

The reported cost jumped suddenly in my local status monitor from about $9.64 to about $73.89 at 2026-06-18 18:12 local time. This jump matched direct ccusage output.

Session-level evidence:

session:      2026/06/18/rollout-2026-06-18T18-12-36-019eda37-cea0-7332-8812-cce69c4c8e35
lastActivity: 2026-06-18 19:19 local
contribution: ~53.13M tokens / ~$68.26

The beginning of that JSONL has a fork chain and a worktree cwd. Sanitized metadata:

session_meta[0].id             = 019eda37-cea0-7332-8812-cce69c4c8e35
session_meta[0].timestamp      = 2026-06-18T10:12:36.024Z
session_meta[0].cwd            = <CODEX_HOME>\worktrees\...\<repo>
session_meta[0].originator     = Codex Desktop
session_meta[0].forked_from_id = 019e813a-287f-7453-bf24-cdf06ff8a903

session_meta[1].id             = 019e813a-287f-7453-bf24-cdf06ff8a903
session_meta[1].timestamp      = 2026-06-01T03:28:57.868Z
session_meta[1].forked_from_id = 019e7eb1-99e6-7113-9c7d-81a1f5d85cc1

session_meta[2].id             = 019e7eb1-99e6-7113-9c7d-81a1f5d85cc1
session_meta[2].timestamp      = 2026-05-31T15:40:34.040Z
session_meta[2].forked_from_id = 019e7e0f-4e4e-7e51-bc45-2dbd6dbc57de

Inside the 2026-06-18T18-12-36... rollout file:

token_count rows total: 427
rows at local minute 2026-06-18 18:12: 395
sum(last_token_usage.total_tokens) in that minute: ~49.30M
sum(last_token_usage.output_tokens) in that minute: ~262.6K

The first few token_count rows are all timestamped within milliseconds of the worktree session creation time:

2026-06-18T10:12:41.192Z last_total=19017  total_total=19017
2026-06-18T10:12:41.192Z last_total=29243  total_total=48260
2026-06-18T10:12:41.193Z last_total=36899  total_total=85159
2026-06-18T10:12:41.193Z last_total=41073  total_total=126232
2026-06-18T10:12:41.194Z last_total=39820  total_total=166052

This pattern looks like copied/replayed parent history being re-emitted at worktree/fork creation time, then attributed to the current day.

I am not attaching the full JSONL because it may contain private conversation/tool output, but I can provide additional sanitized summaries if helpful.

Steps to reproduce

1. Have a Codex Desktop session with existing usage.
2. Create or enter a Codex Desktop worktree/fork session where the new rollout JSONL contains session_meta.payload.forked_from_id and a cwd under .codex/worktrees.
3. Run:

npx --yes ccusage@20.0.14 codex daily --json --timezone Asia/Shanghai --speed standard --since 2026-06-18 --until 2026-06-18

4. Compare with session-level output:

npx --yes ccusage@20.0.14 codex session --json --timezone Asia/Shanghai --speed standard --since 2026-06-18 --until 2026-06-18

5. Observe that the worktree/fork rollout contributes a large current-day total even though most token_count rows are emitted in a sub-second burst right after the worktree session creation time.

Expected behavior

Historical token_count entries replayed into a Codex Desktop worktree/fork session should not be counted as new current-day usage.

Only genuinely new usage after the fork/worktree starts should be counted. The large sub-second replay burst at session creation time should either be skipped, baseline-subtracted, or deduplicated against the parent/fork chain.

Version

20.0.14