Menubar v0.9.13 shows "Couldn't load Today" / dataCorrupted on macOS 26.5

[funeconomist]

Environment

• codeburn CLI: 0.9.12
• Menubar: v0.9.13
• macOS: 26.5.1 (Build 25F80)
• Node: v25.3.0
  What happens
  After installing via codeburn menubar, the menubar app launches but
  immediately shows:

Couldn't load Today
decode(DecodingError.dataCorrupted: Data was corrupted. Debug description:
The given data was not valid JSON.. Underlying error: Error Domain=NSCoco...
Clicking Retry does not resolve it.
What I checked

• codeburn today --format json works and outputs valid JSON (~1s)
• codeburn status --format menubar-json works and outputs valid JSON (~1s)
• ~/.cache/codeburn/menubar-status.json was NOT created by the menubar app
  on launch — had to write it manually
• ~/Library/LaunchAgents/com.codeburn.refresh.plist was NOT installed by
  codeburn menubar
• App is not sandboxed, no quarantine attributes
• Killed and relaunched the app — same error persists
  Expected
  Menubar loads today's usage data on launch.
  Suspected cause
  The menubar app may not be successfully running the CLI as a subprocess
  (possibly due to the app's subprocess PATH not including /opt/homebrew/bin),
  and falls back to reading a cache file that doesn't exist yet, producing the
  decode error.

[ozymandiashh]

Dug into this on the Swift side. The DecodingError.dataCorrupted you see comes from the LIVE CLI path, not the cache or PATH:

• In DataClient.fetch (mac/Sources/CodeBurnMenubar/Data/DataClient.swift), a non-zero CLI exit throws nonZeroExit(code:stderr:), and only try JSONDecoder().decode(MenubarPayload.self, from: result.stdout) throws dataCorrupted. So the CLI is being found and is exiting 0, but its stdout is empty or not valid JSON in the GUI-subprocess context (a JSONDecoder on empty Data() yields exactly "The given data was not valid JSON").
• This means the PATH theory likely isn't it: a PATH miss would surface as nonZeroExit (127), not dataCorrupted. CodeburnCLI already probes /opt/homebrew/bin + /usr/local/bin.
• The missing cache file isn't the source either: MenubarStatusCache returns nil for a missing file (it never reaches a decode).
• The missing com.codeburn.refresh.plist is expected — recent builds removed the launchd agent on purpose and refresh in-process (removeLegacyRefreshAgent on launch).
• Output truncation is ruled out (drain limit is 20 MB; a real menubar-json payload is ~40 KB).

So the open question is what the CLI actually writes to stdout when launched as a GUI subprocess (vs your terminal, where it's valid JSON). On macOS 26.5 / Node v25, a likely culprit is a Node warning or banner landing on stdout instead of stderr, or empty stdout. Could you capture, from the failing GUI launch, the raw result.stdout/result.stderr (e.g. a temporary NSLog of both at the decode-failure site, or run the exact argv the app uses with a minimal GUI-style env)? That would pin whether it's empty output, a non-JSON prefix, or something env-specific — and then the fix is straightforward (make the decode failure surface stdout/stderr, and keep stdout JSON-only).

[funeconomist]

Thanks @ozymandiashh — that narrowed it down well. I captured the raw output from the real GUI launch (not a terminal run) by redirecting the app's stored CLI path (~/Library/Application Support/CodeBurn/codeburn-cli-path.v1) to a logging wrapper that records argv/env and tees stdout+stderr, then relaunched the menubar so it called through the wrapper.

What the GUI subprocess actually runs

codeburn status --format menubar-json --provider all --period today --no-optimize

(CWD /, spawned directly — not via a shell)

Raw result from the failing-launch code path

• exit code: 0
• stderr: empty (0 bytes)
• stdout: 23,525 bytes of valid JSON — parses cleanly with a strict parser
  • first bytes: 7b 22 67 65 6e ... → {"generated":... (no BOM, no leading whitespace, no banner)
  • last bytes: ... 7d 7d 0a → ...}}\n (clean close, no trailing junk)

So in my environment the CLI is not emitting empty or non-JSON stdout to the GUI subprocess — stdout is exactly the JSON the decoder expects.

What changed / likely root cause

This lines up with your Node-banner-on-stdout theory. The CLI shebang pins /opt/homebrew/opt/node/bin/node. On the day I filed this I was on Node v25.3.0; my Homebrew node has since been upgraded to v26.3.0, and after that upgrade + a clean relaunch the GUI subprocess now returns valid JSON (exit 0, clean payload, empty stderr) — i.e. the dataCorrupted condition no longer reproduces in the captured output. That's consistent with a v25-specific warning/banner landing on stdout that v26 no longer emits.

Env (relevant subset) from the GUI launch, for reference

• PATH led with /usr/local/bin, included /opt/homebrew/bin and an nvm v25.3.0 bin dir, but the absolute shebang means the pinned /opt/homebrew/opt/node (now v26.3.0) is what actually ran.
• HOME, SHELL=/bin/zsh present; no NODE_OPTIONS/NODE_NO_WARNINGS set.

Suggestion still stands regardless: surfacing stdout/stderr in the dataCorrupted branch of DataClient.fetch would make this self-diagnosing, and guarding that the CLI keeps stdout JSON-only (route any node warnings/banners to stderr) would prevent a regression if a future node version reintroduces a stdout banner.

Happy to re-capture on a specific Node version if that'd help confirm the v25 reproduction.

[ozymandiashh]

Opened #546 with the fix we landed on here.

It makes the failure self-diagnosing rather than guessing: DataClientError.decode now carries a bounded (<= 4 KB) preview of the raw stdout plus the stderr and the total stdout byte count, surfaced through CustomStringConvertible, so the "Couldn't load" detail shows exactly what the CLI wrote instead of an opaque dataCorrupted. If a future Node version reintroduces a stdout banner (the v25 case here), the error text will show the offending bytes directly.

I also confirmed, against the built CLI, that the menubar-json path already writes only the JSON payload to stdout (src/main.ts is a single console.log(JSON.stringify(payload)), stderr empty), so no CLI-side change was needed. The PR adds tests for the preview content and the 4 KB cap.

[iamtoruk]

Resolved. Summary for posterity:

Root cause: a Node v25-specific banner landing on stdout ahead of the JSON the menubar reads, which made the Swift decoder see non-JSON and throw dataCorrupted. @funeconomist's capture confirmed it: on Node v26 the GUI subprocess returns a clean exit 0, empty stderr, and valid JSON, so upgrading Node fixed the actual failure. The CLI's status --format menubar-json writes only JSON.stringify(payload) to stdout, so there was no CLI app-code bug; the pollution was the Node runtime.

Hardening shipped in #547: the menubar's decode failure is now self-diagnosing. Instead of an opaque "not valid JSON", DataClientError.decode now surfaces a bounded stdout snippet, the stdout byte count (so empty stdout is distinct from a non-JSON prefix), and stderr. If a future Node version ever reintroduces a stdout banner, the error will say exactly what landed there.

Thanks @ozymandiashh and @funeconomist for the unusually thorough diagnosis. Closing as resolved.

[funeconomist]

Reopening would be ideal but I can't from my side — leaving this as a comment instead. The actual root cause on my machine is not the Node v25 stdout banner, and it reproduces with byte-clean stdout. Posting a full diagnosis since it's a concrete, fixable bug on both the CLI and app sides.

Root cause: an Int64-overflowing integer in the menubar-json payload

The CLI's stdout is valid JSON and exits 0 — but it contains a token count that exceeds Int64.max, so Swift's JSONDecoder throws dataCorrupted ("The given data was not valid JSON", underlying NSCocoaErrorDomain). A Python/strict JSON parser accepts the payload (arbitrary-precision ints), which is exactly why earlier "stdout is valid JSON" captures looked clean.

The offending field in my payload:

.history.daily[N].inputTokens              = 221360928884514260000   (21 digits)
.history.daily[N].topModels[0].inputTokens = 221360928884514260000
Int64.max                                  =   9223372036854775807   (19 digits)

Where the garbage comes from: Antigravity uint64 underflow

Tracing it back through session-cache.json, the bad values originate in Antigravity conversation logs (~/.gemini/antigravity/conversations/*.pb):

usage.inputTokens = 18446744073709527000
2^64              = 18446744073709551616
=> 18446744073709527000 - 2^64 = -24616

i.e. Antigravity records a small negative token delta that wraps around uint64 to ~1.8e19. codeburn sums ~12 of these for a single day → 2.21e20, which overflows Int64 downstream. Many of my .pb files are affected, so it's systemic, not a one-off.

Why the app shows it as dataCorrupted

I confirmed this is a decode-side overflow (not empty/truncated stdout) by feeding the app a frozen, strict-validated payload with the CLI fully bypassed — it still failed, because the payload itself carried the oversized int. Clamping integers with |n| > 2^53 to 0 before the JSON reaches the app makes it decode and render correctly (all providers retained).

Suggested fixes

1. CLI (codeburn): sanitize token counts at ingest — clamp/reject implausible values (> 2^53, or the ~2^64 - k underflow signature) so the emitted JSON is always Int64-safe. Bonus: surface a --verbose warning when a provider file yields out-of-range token values.
2. App (menubar): decode token fields defensively (e.g. Int64/UInt64/Double, or tolerate/skip an out-of-range history.daily entry) so a single bad number in historical data can't take down the entire "Today" view.

Happy to share a sanitized payload sample or the exact .pb-derived values if useful. The #547 change (surfacing stdout/stderr on decode failure) is still worthwhile, but it won't fix this case since the bytes are "valid JSON" — the failure is integer-range, not syntax.

[funeconomist]

@iamtoruk @ozymandiashh ^

[ozymandiashh]

On it buddy

[ozymandiashh]

Opened #553 for the Antigravity token-count path.

It covers the overflow/dataCorrupted failure mode plus two related correctness cases I found while validating the path:

• unsafe / oversized token counts are clamped before they can reach the menubar payload or Swift decode
• split generator metadata preserves output cost when response/thinking fields are partial
• Antigravity SQLite cache fingerprints include -wal / -shm sidecars, so WAL-mode writes do not get hidden by a stale .db stat

Validation in the PR body includes the focused provider/cache/menubar tests, TypeScript, build, and Swift build.

[ozymandiashh]

Update: #553 is now green and mergeable.

I tightened the fix after an extra pass over the cache path: WAL/SHM sidecar changes are now included at the session-cache fingerprint layer too, not only inside the Antigravity parser. That means a WAL-only SQLite write cannot be skipped by the global “unchanged file” check before the provider parser runs.

Current local/GitHub validation:

• 133 focused tests passing across Antigravity, session-cache, daily-cache, and menubar-json
• TypeScript check passing
• Full build passing
• Swift menubar build passing
• GitHub checks green