High CPU (80–134%) on 0.60.4 and sustained disk writes (~121 KB/s, 8.6 GB/day) on 0.56.3

[ravsau]

Summary

CodexBar 0.60.4 used 82–134% CPU and ~900 MB RSS about 20 minutes after launch. Separately, macOS logged two disk writes resource reports against 0.56.3 (~121 KB/s sustained, 8.6 GB in ~20 h).

Environment

• CodexBar 0.60.4 (installed app; the resource reports are from 0.56.3 (134))
• macOS 26.3 (25D125), Apple Silicon, 16 cores, 128 GB RAM
• Refresh frequency: 5 minutes
• openAIWebAccessEnabled = 1, openAIWebBatterySaverEnabled = 0
• tokenCostUsageEnabled = 1, providerStorageFootprintsEnabled = 1
• Selected menu provider: codex

CPU / memory (0.60.4)

Measured with ps and top on 2026-09-22, process up for ~20 min:

  PID    RSS  %CPU  ELAPSED  COMM
76028 909120  82.1           CodexBar      (ps -m)
76028        134.2    20:06  CodexBar      (ps -r, a few seconds later)
76028          29.9   307M+  CodexBar      (top -l 2, second sample)

It was the top CPU user on the machine, above WindowServer. I did not capture a sample before the app was quit.

Disk writes (0.56.3)

Two reports in /Library/Logs/DiagnosticReports/:

Report	Writes	Duration	Rate
CodexBar_2026-09-17-175619	2163 MB	17738 s	121.95 KB/s
CodexBar_2026-09-19-111115	8601 MB	70900 s	121.32 KB/s

Both reports show the same heaviest stack: a dispatch lane worker going into OS_dispatch_queue.sync / asyncAndWait → _dispatch_lane_barrier_sync_invoke_and_complete (CodexBar frames unsymbolicated: CodexBar + 12567116 → +12150240 → +12089892 → +12145332 → +12024280 → +23103028 → +23642716). The steady ~10.5 MB per step suggests a cache or snapshot being rewritten on each refresh, not appended to.

Possibly related

• 0.55.1 (130): sustained ~92% CPU + 2.2 GB RSS within 35 min of launch, and ~468 orphaned WebKit.WebContent processes spawned overnight (~1 per 30–90s); orphans survive app quit and SIGKILL #3247: sustained ~92% CPU + 2.2 GB RSS soon after launch (0.55.1)
• Memory grows to ~2.6 GB RSS while idle (0.56.1) #3323: memory grows to ~2.6 GB RSS while idle (0.56.1)
• Spend Dashboard no-progress pause auto-restarts, loops at 100% CPU #3316: Spend Dashboard no-progress pause loops at 100% CPU
• Background Chromium cookie gate re-runs a full app-bundle code-signature validation on every refresh: ~11.6% of a core at idle, 190-217% CPU bursts every 60s #3837 / fix(keychain): keep completed signature validations fresh #3838 and Codex scan load re-decodes the entire cost cache on every refresh, even when the store is unchanged #3840: fixes for idle CPU from signature validation and cost cache re-decoding, merged after 0.60.4

I will update to 0.64.1 and report back whether the CPU use and disk writes remain.

[clawsweeper]

Codex review: this still needs some work. Reviewed September 22, 2026, 5:49 PM ET / 21:49 UTC.

Summary
Keep open: the measured resource use is concrete, but neither symptom is established as resolved or attributable to one existing report. The cited recent optimizations are not in v0.64.1, and this repository’s onboarding policy prohibits automatic closure.

Reproducibility: no. high-confidence current-main reproduction is established: the report measures older releases without a CPU profile or symbolicated write stack, and its enabled background workloads have several possible owners.

Next step
Await the promised current-version measurements; if symptoms recur, capture an Activity Monitor sample and redacted write diagnostics with build identity, then isolate Track Costs and OpenAI web extras separately without deleting caches.

Review details

Best possible solution:

Keep unchanged background refreshes inexpensive while preserving history, and repair only the CPU or write path identified by a current-build profile.

Do we have a high-confidence way to reproduce the issue?

No high-confidence current-main reproduction is established: the report measures older releases without a CPU profile or symbolicated write stack, and its enabled background workloads have several possible owners.

Is this the best way to solve the issue?

Unclear: recent optimizations address specific nearby mechanisms, but a current-build profile and write-target attribution are needed before choosing a narrow repair.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The CPU and disk-write observations come from different versions and lack evidence identifying their production owners; assuming a single cache-rewrite defect could lead to the wrong repair.

Codex review notes: model internal, reasoning medium; reviewed against c3b79b4c3b60.

Label changes

Label changes:

• add P2: Measured background resource consumption warrants investigation, but current-release persistence and the responsible path remain unconfirmed.
• add impact:other: The reported impact is excessive CPU, memory, and disk activity rather than established data loss or process failure.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:needs-info: Current issue advisory state selects this label.

Label justifications:

• P2: Measured background resource consumption warrants investigation, but current-release persistence and the responsible path remain unconfirmed.
• impact:other: The reported impact is excessive CPU, memory, and disk activity rather than established data loss or process failure.

Evidence reviewed

What I checked:

• Concrete measurements, unresolved attribution: The report records CPU samples on 0.60.4 and two disk-write diagnostics on 0.56.3. It explicitly lacks a CPU sample, provides unsymbolicated disk-write frames, and promises a follow-up after updating. These are separate observations, not proof of a shared cache-rewrite cause.
• Current scan reuse and regression coverage: loadCodexScan reuses a decoded baseline while its database stamp matches and issues a fresh receipt. Tests/CodexBarTests/CostUsageStoreReadWorkTests+RepeatedScanLoad.swift checks zero snapshot reads and row decodes on a repeated unchanged load, plus invalidation cases. This addresses the mechanism reported at Codex scan load re-decodes the entire cost cache on every refresh, even when the store is unchanged #3840, without establishing resolution of this reporter’s resource use. (Sources/CodexBarCore/Vendored/CostUsage/CostUsageStore+CodexBaseline.swift:67, c3b79b4c3b60)
• Release boundary: Current CHANGELOG.md places scan-baseline reuse and concurrent signature-validation improvements under 0.64.2 — Unreleased, above the 0.64.1 section. The latest-release API identifies v0.64.1, published at 2026-09-22T08:29:31Z. The scan optimization commit is dated 2026-09-22T11:33:39-07:00; no local tag contains it. Updating to v0.64.1 therefore does not exercise this optimization. (CHANGELOG.md:3, 631611948171)
• Signature validation has a deliberately limited cache: Current validation shares concurrent requests and caches confirmed rejections, but completed successful validations run again on the next operation. The merged follow-up fix(keychain): keep completed signature validations fresh #3838 preserves sealed-resource freshness; it does not justify claiming all recurring signature-validation CPU has disappeared. (Sources/CodexBarCore/KeychainAccessPreflight+ValidationMemo.swift:66, c3b79b4c3b60)
• Existing disk-write safeguards: The scanner calls the cost-store save path with skipIdenticalContent enabled; matching content avoids rewriting usage rows while retaining required metadata and budget handling. Separately, merged Avoid rewriting unchanged plan history files #2878 avoids byte-identical plan-history replacements. Neither mechanism can be connected to the reported unsymbolicated frames yet. (Sources/CodexBarCore/Vendored/CostUsage/CostUsageStore+CodexCache.swift:225, c3b79b4c3b60)
• Discussion distinguishes several remaining problems: Human discussion on 0.55.1 (130): sustained ~92% CPU + 2.2 GB RSS within 35 min of launch, and ~468 orphaned WebKit.WebContent processes spawned overnight (~1 per 30–90s); orphans survive app quit and SIGKILL #3247 separates cost scanning, Claude cache decoding, and uncertain WebKit attribution. On Memory grows to ~2.6 GB RSS while idle (0.56.1) #3323, steipete explicitly distinguishes landed allocation reductions from unresolved multi-hour RSS growth. Discussion on Spend Dashboard no-progress pause auto-restarts, loops at 100% CPU #3316 confirms the restart fix while retaining separate accounting concerns. These threads do not establish one canonical root cause for this report.

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Nikolai Berezovskii: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

PR #3906 (now landed on main) fixes a reproducible source of Codex cost-cache write amplification. When one file or scan metadata changed, the save path rewrote state for every retained file. A synthetic regression measured 83 row writes per save with 16 files before the fix, versus 8 for a single-file change and 3 for a metadata-only change afterward. All cache round-trip checks and 227 focused tests pass. These are SQLite counters, not a measurement of your reported disk throughput or CPU usage, so this issue should remain open pending matching evidence.

Please capture 30–60 seconds of sudo fs_usage -w -f filesys CodexBar codexbar and a 10-second sample <CodexBar-PID> 10 -file codexbar-sample.txt while the problem is occurring. Include the current CodexBar version, enabled providers, refresh interval, whether local cost history and verbose file logging are enabled, and whether the app or a CLI process is busy. Redact personal paths/account details while retaining cache filenames and stack symbols. Thank you for reporting the measurements.

[steipete]

PR #3909 (now landed on main) fixes one reproducible Claude write path: unchanged forced rescans and repeated saves replaced both complete JSON artifacts. Synthetic forced scans wrote 2,954 bytes for 2 rows or 54,102 bytes for 128 rows, separately for regular and history caches. After the fix, all 24 measured unchanged refreshes replaced zero files and wrote zero JSON payload bytes. Changed usage still persists; 229 focused tests, make check, and CI passed.

Ordinary unchanged refreshes already wrote zero bytes before this patch, including refreshes that bypass the debounce. Changed transcripts still rewrite complete JSON files, so this does not fully resolve the reported daily volume. Existing artifacts may be rewritten once for deterministic key ordering. Real cache contents were not inspected.

The separate Codex SQLite store already attempts truncating checkpoints after saves through retention enforcement. A synthetic checkpointed WAL retained and reused its allocated size, so the observed 345 MB WAL alone is not evidence of missing checkpointing. I recommend keeping this issue open for investigation of full-cache rewrites during changing workloads.

[steipete]

The Cursor investigation reproduced repeated HTTP 403 cost requests at ordinary refresh boundaries. #3924 (now landed on main) suppresses those repeated attempts. The synthetic fixture provides no CPU profile, so it does not establish the cause of this issue’s CPU bursts; this issue should remain open pending separate evidence.

[djbclark]

I hit this on 0.67.0 and was able to capture the sample that was missing from the original report. Opening #4053 with a fix for what I believe is at least a large part of this.

Root cause: the Claude cost cache artifact is fully re-decoded on every scan.

sample over a 5s window, while the app sat at ~139% CPU with the main thread completely idle:

• 888 / 892 samples on com.steipete.codexbar.cost-usage-store were inside a blocking dispatch_sync — this is the same OS_dispatch_queue.sync / asyncAndWait / _dispatch_lane_barrier_sync_invoke_and_complete lane your two disk-write reports fingered
• 786 of those were inside JSONDecoder.decode, dominated by _arrayForceCast / swift_dynamicCast / _DictionaryCodingKey, i.e. Swift's slow keyed-decode path
• the cost-usage-scan queue (150 samples) was just blocked behind it

The artifact is ~/Library/Caches/CodexBar/cost-usage/claude-history-v6.json. On this machine it is 9.3 MB holding ~24k ClaudeUsageRow values. Measured directly:

• raw JSONSerialization parse of those bytes: 190 ms
• Codable field-by-field decode of the same bytes: seconds (~25x overhead, ~410k field decodes)

Scans re-run whenever any Claude transcript changes, which with several Claude sessions running is near-continuous — so that decode repeats indefinitely.

Your inference in the original report was right, with one correction: the steady ~10.5 MB per step is this artifact, but it is being re-read and re-decoded each refresh rather than only rewritten (identical-content writes are already skipped by #3909).

#4053 memoizes the decoded artifact against its identity/size/mtime stamp, so an unchanged file is never re-decoded while any rewrite still invalidates the entry. On this machine:

	before	after
steady-state CPU	~139%	0–2.7%
RSS	~617 MB	~100 MB
cost-usage queues in sample	saturated	absent

System load average fell from 292 to 7.4 over the same period.

Worth noting this is a distinct instance from the cost-cache re-decode fixed in #3840 — that one did not cover the Claude/Vertex JSON artifact path in CostUsageClaudeCacheIO. Given the RSS figures in #3247 and #3323, those may share this cause too, since each redundant decode allocates the whole object graph.

[djbclark]

Investigated on this machine — the periodic high CPU is not from launchd, jobber, or hermes. The only related launch agent is com.djbclark.aiuse (hourly aiuse -q --json, managed from ~/ops/site-djbclark); it is unrelated.

Cause

CodexBar 0.67.0 (cask) runs an all-history Codex cost refresh about every 5 minutes. With CostReportingPeriod.allTime the scan window starts at Date.distantPast, and the priority-metadata merge on main enumerates every calendar day (~739k) per refresh, formatting day keys with String(format:) and Calendar.dateComponents.

On this machine the live cache shows:

• scanSinceDay: 0001-12-30
• turnIDsByDay: 739,526 entries (all empty arrays)
• priority payload: 15.7 MB base64 in SQLite
• sample CodexBar 3: 942/942 samples on serial com.steipete.codexbar.cost-usage-scan inside the day-key formatting loop

While sampled, the running cask held ~100% CPU on that queue.

Fix in flight

#4045 replaces calendar enumeration with recorded-day reconciliation and adds a tested 0.68.0 predecessor-hash adoption path so the dense cache upgrades without a rebuild. #4053 (Claude artifact memoization) merges the same adoption/test work.

No change needed in ~/ops for CodexBar itself — the cask is installed via Homebrew; ops only manages the separate aiuse agent.

I'll relaunch from a fixed build once #4045/#4053 land; happy to verify post-fix sample after upgrade.

[djbclark]

Update after ~2h on the fixed local build (branch head, packaged from fix-claude-artifact-redecode):

The live cost cache compacted as expected:

• Priority turnIDsByDay: 739,526 empty entries → 0
• Priority payload: 15.7 MB → 1.1 KB
• usage_rows: 10,085 restored after rescan
• CPU: ~1.5% steady (was ~100% on 0.67.0 cask)

Fix is in #4045 / #4053; waiting on upstream merge for a released cask.

[steipete]

Thanks @djbclark, the sample capture was exactly the missing piece. #4053 is now merged on main: decoded Claude cost-cache artifacts are reused across scans when the file is byte-identical (path, device/inode, size, nanosecond mtime), so the ~24k-row claude-history JSON is no longer re-decoded on every scan. Schema, time-zone, window, filter, and pricing validation still run on each reuse, and forced rescans still reparse. It ships in the next release (0.68.1).

Keeping this open for the rest: a follow-up is looking at the remaining full decode/encode and rewrite paths when transcripts change, plus the idle memory growth reported alongside this.