Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-1373GitHub issuePublicReceived

Codex usage is counted again after forking or cloning a Pi session

Reported by Duro02 · filed Aug 27, 2026Closed upstream on 2026-10-04 by the bot omarchybot; the closing comment says it was fixed by PR #14049. GitHub close reason: completed.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
Not yet mapped to any requirement or component.
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

Codex usage is counted again after forking or cloning a Pi sessionrevision 1 · captured 2026-09-28 21:24 UTC via poll

System details

Lenovo ThinkBook 14 G3 ACL, AMD Ryzen, Omarchy 4.0.1-1, Pi 0.84.3, pi-subagents 0.56.0, openai-codex provider

What's wrong?

After a Pi session is forked or cloned, the Codex usage shown in Omarchy's Agents panel includes the inherited historical usage from both the parent session file and the forked session file.

Creating the fork copies existing Pi message entries, including their already-recorded usage metadata, into a new session file. Those copied records do not represent new Codex responses. If work then continues in the fork, only the newly generated responses and their newly reported usage should be additional usage.

This can significantly inflate the local Prompt, Token, and Session statistics when multiple subagents use forked context.

Steps to reproduce

  1. Start a Pi session using the openai-codex provider.
  2. Exchange enough messages to produce recorded token usage.
  3. Fork or clone the session using Pi, or launch a subagent with context: "fork".
  4. Refresh the Omarchy Agents panel.
  5. Compare the reported local usage before and after the fork.

Expected behavior

Usage metadata attached to messages copied from the parent should be counted only once. New assistant responses generated inside the fork should still add their newly reported usage normally.

Actual behavior

The inherited assistant-message records are counted again for every forked session file.

On my machine, three forked sessions contained parent-derived historical usage totaling:

  • 15,716,982 tokens
  • 87,744,714 tokens
  • 87,744,714 tokens

This caused approximately 191,206,410 tokens of local usage to be counted more than once.

I verified these as inherited copies by following each session header's parentSession path and comparing the copied message IDs, timestamps, content, model, and usage data with the declared parent session.

Technical observation

Pi forked-session headers contain a parentSession field. Inherited message entries retain their original IDs, timestamps, contents, and usage records.

The current collector builds its deduplication key using both the file path and message ID:

message_key = path + ":" + str(entry.get("id") or "")

Because every fork has a different file path, inherited copies are treated as separate usage records. This is only a diagnostic observation; the appropriate deduplication strategy is left to the maintainers.

View raw text
### System details

Lenovo ThinkBook 14 G3 ACL, AMD Ryzen, Omarchy 4.0.1-1, Pi 0.84.3, pi-subagents 0.56.0, `openai-codex` provider

### What's wrong?

After a Pi session is forked or cloned, the Codex usage shown in Omarchy's Agents panel includes the inherited historical usage from both the parent session file and the forked session file.

Creating the fork copies existing Pi message entries, including their already-recorded usage metadata, into a new session file. Those copied records do not represent new Codex responses. If work then continues in the fork, only the newly generated responses and their newly reported usage should be additional usage.

This can significantly inflate the local Prompt, Token, and Session statistics when multiple subagents use forked context.

#### Steps to reproduce

1. Start a Pi session using the `openai-codex` provider.
2. Exchange enough messages to produce recorded token usage.
3. Fork or clone the session using Pi, or launch a subagent with `context: "fork"`.
4. Refresh the Omarchy Agents panel.
5. Compare the reported local usage before and after the fork.

#### Expected behavior

Usage metadata attached to messages copied from the parent should be counted only once. New assistant responses generated inside the fork should still add their newly reported usage normally.

#### Actual behavior

The inherited assistant-message records are counted again for every forked session file.

On my machine, three forked sessions contained parent-derived historical usage totaling:

- `15,716,982` tokens
- `87,744,714` tokens
- `87,744,714` tokens

This caused approximately `191,206,410` tokens of local usage to be counted more than once.

I verified these as inherited copies by following each session header's `parentSession` path and comparing the copied message IDs, timestamps, content, model, and usage data with the declared parent session.

#### Technical observation

Pi forked-session headers contain a `parentSession` field. Inherited message entries retain their original IDs, timestamps, contents, and usage records.

The current collector builds its deduplication key using both the file path and message ID:

```python
message_key = path + ":" + str(entry.get("id") or "")
```

Because every fork has a different file path, inherited copies are treated as separate usage records. This is only a diagnostic observation; the appropriate deduplication strategy is left to the maintainers.

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

No decision has been recorded yet.