feat: report disk capacity on crash telemetry events

[RyanGroch]

Adds last_known_disk_total_mb, last_known_disk_used_mb and last_known_disk_available_mb to app:crash_detected and renderer:crash_detected, so we can see whether crashes line up with a full disk.

The performance monitor already saves a snapshot every 30s that the next launch attaches to both crash events, so this is one statfs call added to that snapshot.

It measures the user data volume, not the apps folder. The same tick already reads and writes user-settings.json there, so the statfs adds no blocking the main thread did not already have; the apps folder is user-configurable and could be a network mount. For a default install they are the same volume.

Used and available are both reported because they are not interchangeable: every platform holds some space back from ordinary writes, so total minus used overstates the room the user really had. Available is the one to threshold on.

If the statfs fails the fields are omitted rather than reported as zero, and they are optional in the schema so older snapshots still parse. Measuring how much disk Dyad itself uses is out of scope, since that needs a recursive walk of every app directory.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: eddd8f6066

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[cubic-dev-ai]

All reported issues were addressed across 7 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[dyad-assistant]

Claude review: 2 inline finding(s).

[dyad-assistant]

🔍 Dyadbot Code Review Summary

Verdict: 🤔 NOT SURE - Potential issues
Recommendation: ready

Small, well-scoped telemetry addition. The core helper (src/utils/disk_usage.ts) is correct: Math.round is monotonic so usedMB <= totalMB and availableMB <= totalMB always hold, the blocks - bfree vs bavail split is the right way to expose the platform reserve, and returning null on failure keeps zeros out of PostHog. The optional zod fields are wired into StoredUserSettingsSchema via LastKnownPerformanceSchema, so the new keys survive the validation parse in writeSettings instead of being silently stripped, and older snapshots still parse.

The statfsSync placement is sound: it sits after the cpuUsagePercent === null early return, so it does not run on the two initialization ticks, and writeSettings already does writeFileSync/copyFileSync/renameSync against the same volume on every tick — the PR's claim that this adds no new main-thread blocking checks out. The ...(diskUsage && {...}) spread matches the existing processWorkingSetsMB idiom and is a no-op when null. No IPC surface, no renderer exposure, and no new filesystem access reachable from the renderer.

Two things worth a reviewer's attention, neither blocking. I was not able to execute the test suite in this environment, so the notes below are from static reading of the diff and surrounding code.

Issues Summary

Severity	File	Issue
🟡 MEDIUM	e2e-tests/performance_monitor.spec.ts:151	E2E test hard-asserts disk fields the production code treats as optional
🟡 MEDIUM	src/utils/performance_monitor.ts:238	Disk telemetry measures the user data volume, not the apps volume

🟢 Low Priority Notes (4 items)

• Duplicated BYTES_PER_MB - performance_monitor.ts:18 already defines the same constant that disk_usage.ts re-declares. Minor, but the two can drift. (src/utils/disk_usage.ts)
• Failures are swallowed without any log - getDiskUsageMB catches and returns null with no logger call, so a platform-wide statfs regression would make the fields quietly disappear from telemetry with nothing in the logs explaining why. This matches the existing getProcessWorkingSetsMB convention, so it is consistent, but a logger.debug when diskUsage === null would be cheap insurance for a diagnostics-only feature. (src/utils/disk_usage.ts)
• Schema round-trip pin test not extended - src/lib/schemas.test.ts exists specifically to pin that "the lastKnownPerformance shape written by the performance monitor survives the validation parse in writeSettings". The three new fields are not added to that fixture, so the newest and least-proven fields lack the coverage that test was written to provide. The unit test in crash_telemetry_fields.test.ts covers the PostHog mapping but not the zod round trip. (src/lib/schemas.ts)
• Force-close dialog still shows only memory and CPU - ForceCloseDialog.tsx renders a curated subset of the snapshot, so omitting disk is consistent with how heap and peak fields are handled. Still, a nearly-full disk is arguably the one crash cause an end user could actually act on, and diskAvailableMB is already in the snapshot the dialog receives. Worth considering as a follow-up. (src/utils/performance_monitor.ts)

---

Generated by Dyadbot persona-based code review

[dyad-assistant]

Claude review: 1 inline finding(s).

[dyad-assistant]

🔍 Dyadbot Code Review Summary

Verdict: 🤔 NOT SURE - Potential issues
Recommendation: ready

Small, well-scoped telemetry addition: one statfs call folded into the existing 30s performance snapshot, three optional fields threaded through the settings schema and the shared crash-event flattener, plus unit and e2e coverage. The diff is complete (not truncated) and I reviewed it against the surrounding code in src/utils/performance_monitor.ts, src/utils/crash_telemetry_fields.ts, src/main/settings.ts and src/components/ForceCloseDialog.tsx.

Correctness looks sound: the fields are optional() so older snapshots and the renderer-crash record still parse, the spread is conditional so a failed statfs omits rather than zeroes, getDiskUsageMB is called after the CPU-null early return so it never runs on a tick that discards its result, and the new fields are plain scalars so the "no object-valued properties" contract in crashPerformanceEventFields still holds. No IPC surface, schema/migration, UI primitive, or agent-tool behavior is touched, and no DyadError path is involved — the failure mode is a silently-omitted optional field, not a user-facing error.

The one thing worth noting before this data gets analyzed is that the used/available distinction the PR is built on is a Unix property and does not hold uniformly on Windows.

Issues Summary

Severity	File	Issue
🟡 MEDIUM	src/utils/disk_usage.ts:26	Available-vs-used distinction does not hold on Windows

🟢 Low Priority Notes (5 items)

• Duplicated constant - BYTES_PER_MB is now defined in both src/utils/disk_usage.ts:3 and src/utils/performance_monitor.ts:18. Harmless, but the new module could export it or import the existing one. (src/utils/disk_usage.ts)
• Main-process-only module in a shared folder - disk_usage.ts imports node:fs and sits in src/utils/, next to renderer-reachable modules like crash_telemetry_fields.ts. Nothing imports it from the renderer today; a short "main process only" note (or moving it under src/main/) would keep a future accidental import from breaking the renderer bundle. (src/utils/disk_usage.ts)
• Mock shape is coupled to the import style - vi.mock("node:fs", () => ({ default: { statfsSync: vi.fn() } })) supplies no named exports, so switching disk_usage.ts to import { statfsSync } from "node:fs" would fail with a confusing undefined error rather than a clear mock miss. (src/utils/disk_usage.test.ts)
• Sync syscall on the main thread - statfsSync runs on the main process every 30s. The PR's reasoning holds for a default install (the same tick already writes user-settings.json to that volume synchronously), but on a redirected or network-backed user-data directory the call can block; fs.statfs/promises.statfs is available if this ever surfaces in freeze reports. (src/utils/performance_monitor.ts)
• Disk state is not surfaced in the force-close dialog - ForceCloseDialog renders this same snapshot to users under "Last Known State" and now has disk figures available but doesn't show them. A "disk nearly full" line would let a user self-diagnose the exact scenario this telemetry is meant to detect. Out of scope for a telemetry-only PR, but the surface already exists. (src/components/ForceCloseDialog.tsx)

---

Generated by Dyadbot persona-based code review

[wwwillchen]

thanks! one minor comment, otherwise lgtm

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b48bcc5173

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[dyad-assistant]

Claude review: 1 inline finding(s).

[dyad-assistant]

🔍 Dyadbot Code Review Summary

Verdict: 🤔 NOT SURE - Potential issues
Recommendation: ready

Small, additive telemetry change: one statfs per 30s performance tick, three new optional fields on LastKnownPerformanceSchema, and three new scalar properties on the shared crash event field builder. I traced the full path and it holds together:

• crashPerformanceEventFields is the single source for both app:crash_detected (src/main.ts:815) and renderer:crash_detected (src/main.ts:1068), so both events pick the fields up.
• The renderer-crash record round-trips through parseRendererCrashPerformance → LastKnownPerformanceSchema (src/main/settings.ts:307), which the PR extends, so the fields survive the persist/reload hop rather than being silently stripped.
• writeSettings shallow-merges at the top level (src/main/settings.ts:391), so lastKnownPerformance is replaced wholesale each tick — a failed statfs genuinely omits the fields instead of leaving stale ones behind.
• The E2E settings snapshot helper already ignores lastKnownPerformance (e2e-tests/helpers/page-objects/components/Settings.ts:125), and ForceCloseDialog enumerates its fields explicitly, so nothing downstream breaks on the new keys.
• fs.statfsSync is fine on Electron 40 (Node 22) across all shipped platforms, and blocks/bfree/bavail are all in bsize units on each, so the arithmetic is right. Reporting used and available separately is the correct call, as the description argues.
• Mocking node:fs with a default-only factory while leaving electron-log real matches existing precedent in the repo (src/ipc/handlers/chat_stream_handlers.test.ts), since node_modules deps are externalized and unaffected by the mock.

One MEDIUM issue, on the failure path. Nothing blocks merge.

Note on confidence: the diff is complete (not truncated), but I could not execute the test suite in this environment, so the assessment is static analysis plus cross-referencing the surrounding code.

Issues Summary

Severity	File	Issue
🟡 MEDIUM	src/utils/disk_usage.ts:32	Error-level log on every 30s tick can flood the crash log tail

🟢 Low Priority Notes (4 items)

• Duplicated BYTES_PER_MB - The same 1024 * 1024 constant is now defined in both performance_monitor.ts:18 and the new module; the latter could import it or the pair could move to a shared spot. (src/utils/disk_usage.ts)
• _mb fields are actually MiB - Math.round(bytes / (1024*1024)) makes a "512 GB" drive report as 476000 in last_known_disk_total_mb. This matches the existing convention for memoryUsageMB and friends, so it's consistent — just worth knowing when reading the PostHog numbers, since a naive decimal reading is off by ~7%. (src/utils/disk_usage.ts)
• E2E assertion is coupled to host filesystem state - expect(diskUsedMB).toBeGreaterThan(0) holds because userDataDir lives under os.tmpdir() on a real disk on the current runners, but it would fail if a runner ever mounted os.tmpdir() on a near-empty tmpfs where used blocks round to 0. A toBeGreaterThanOrEqual(0) would test the same regression (field presence, which toMatchObject already pins) without the host coupling. (e2e-tests/performance_monitor.spec.ts)
• Disk figures are not surfaced in the force-close dialog - "Your disk was full" is the single most actionable thing in this snapshot for a user, yet the dialog still shows only memory and CPU. Out of scope for a telemetry-only PR, but a natural follow-up; it would need the local ForceClosePerformanceData interface in ForceCloseDialog.tsx:18 extended, since that interface hand-duplicates the schema. (src/components/ForceCloseDialog.tsx)

---

Generated by Dyadbot persona-based code review

[dyad-assistant]

Claude review: 1 inline finding(s).

[dyad-assistant]

🔍 Dyadbot Code Review Summary

Verdict: 🤔 NOT SURE - Potential issues
Recommendation: ready

Small, well-scoped, well-tested telemetry addition: one statfs per 30s heartbeat, three optional schema fields, three flat PostHog properties. The diff is complete (not truncated) and I verified the surrounding code rather than relying on the diff alone. No HIGH issues; one MEDIUM worth noting, which does not block merge.

Things I checked and found correct:

• The blocking-I/O argument in the description holds. getSettingsFilePath() is path.join(getUserDataPath(), SETTINGS_FILE) (src/main/settings.ts:113), and the same tick already does readSettingsForWrite + writeFileSync + copyFileSync + renameSync on that exact volume. The added statfsSync targets a filesystem the main thread was already blocking on.
• Placement. getDiskUsageMB is called after the cpuUsagePercent === null early return, so the first tick (which discards its snapshot) does not pay for the syscall.
• No stale-field risk. writeSettings merges shallowly ({ ...existing, ...settings }), so lastKnownPerformance is replaced wholesale each tick. When statfs fails after previously succeeding, the old disk figures are dropped rather than silently re-reported as current — which is what the conditional-spread omission pattern depends on.
• Field naming and undefined handling in crash_telemetry_fields.ts match the existing last_known_* fields exactly, and the new negative test asserts omission rather than a zero.
• fs.statfsSync is available on Electron 40 (Node 22+) on all three shipped platforms.
• No telemetry field allowlist or docs file elsewhere in the repo needs a parallel update — crash_telemetry_fields.ts is the only place these property names appear.

Issues Summary

Severity	File	Issue
🟡 MEDIUM	src/utils/disk_usage.ts:31	Degenerate statfs results reported as real 0 MB disk figures

🟢 Low Priority Notes (3 items)

• "The user data volume is the system volume" is not always true - The comment states this as fact, but userData sits under $XDG_CONFIG_HOME/~/Library on Linux and macOS, which is commonly a separate partition and, with Windows folder redirection or a network home directory, can be a remote mount. The conclusion the comment supports (measure userData, not the apps folder) is still the right call, and the blocking argument survives either way since settings are already written there synchronously — only the stated reason is overbroad. (src/utils/performance_monitor.ts)
• diskUsedMB asserted > 0 in the E2E test - The E2E user data dir lives under os.tmpdir(). On a distro where /tmp is tmpfs, used bytes can round below 1 MB and the assertion fails for reasons unrelated to the code under test. In practice the app writes enough into that directory during the 35s wait to stay above the threshold, so this is unlikely to bite CI; toBeGreaterThanOrEqual(0) would carry the same regression-catching value as the toMatchObject presence check that precedes it, with no environment coupling. (e2e-tests/performance_monitor.spec.ts)
• Disk figures are not surfaced to the user anywhere - A full disk is one of the few crash causes a user can actually act on, but neither ForceCloseDialog (which already renders memory and CPU from the same snapshot) nor getSystemDebugInfo (which feeds GitHub issue bodies) shows disk capacity. That is consistent with how heap and peak metrics are already handled and is reasonably out of scope for a telemetry-only PR, but it is the obvious follow-up once the data confirms the correlation. (src/components/ForceCloseDialog.tsx)

Confidence note: the two unit tests that call vi.resetModules() and re-import the module depend on Vitest preserving the vi.mock factory result across a module-registry reset (so the top-level statfsSync handle stays bound to the freshly imported module). node_modules is not installed in this checkout, so I could not run the suite to confirm; that behaviour matches Vitest's documented "resetModules does not reset the mocks registry", and if it did not hold both tests would still pass, so this is not raised as a finding.

---

Generated by Dyadbot persona-based code review

[dyad-assistant]

Claude review: 2 inline finding(s).

[dyad-assistant]

🔍 Dyadbot Code Review Summary

Verdict: 🤔 NOT SURE - Potential issues
Recommendation: ready

The change is small, well-scoped, and correct in its core arithmetic. getDiskUsageMB converts blocks with the filesystem's own bsize, distinguishes allocated blocks (blocks - bfree) from user-writable space (bavail), and returns null on failure so capturePerformanceMetrics omits the fields via the same ...(x && {...}) spread pattern already used for processWorkingSetsMB. The schema additions are optional, so older snapshots still parse, and crashPerformanceEventFields stays flat and scalar-only, satisfying the existing "no nested JSON" test. getUserDataPath() is safe at the call site (startPerformanceMonitoring runs after app ready), and the sync statfs is added to a tick that already performs a synchronous settings write to the same volume, so it introduces no new class of main-thread blocking. fs.statfsSync is available on all three platforms under Electron 40, and the unit test's block-math fixtures check out (1 GiB / 768 MB / 128 MB, and the 1 KiB-block case). No IPC surface, no database schema, and no renderer data fetching is touched, so the Electron boundary and TanStack Query conventions are unaffected. The diff is complete and untruncated.

Two non-blocking concerns are below. Neither is a merge blocker.

Issues Summary

Severity	File	Issue
🟡 MEDIUM	e2e-tests/performance_monitor.spec.ts:159	E2E assertion on diskUsedMB > 0 can fail on a tmpfs temp dir
🟡 MEDIUM	src/utils/disk_usage.ts:32	Unthrottled error log repeats every 30s on a persistent failure

🟢 Low Priority Notes (3 items)

• Force-close dialog does not surface the new disk figures - The "Last Known State" dialog already shows process and system metrics, and a nearly full disk is the one condition in this snapshot a user could actually act on. Adding disk to telemetry but not to the dialog is a defensible scope choice, but worth a follow-up. (src/utils/performance_monitor.ts)
• No sanity clamp on the reported values - availableMB is passed through verbatim. On filesystems that report f_bavail as a signed value which has gone negative (free space consumed past the reserve), the value surfaced by Node can be nonsensically large, which would both skew the telemetry and trip the new diskAvailableMB <= diskTotalMB E2E assertion. I have low confidence this occurs on macOS/Linux/Windows as shipped, so this is a note rather than a finding. (src/utils/disk_usage.ts)
• node:fs mock only provides a default export - vi.mock("node:fs", () => ({ default: { statfsSync: vi.fn() } })) works today because disk_usage.ts uses a default import, but the mock will fail opaquely if the module ever switches to a named import. (src/utils/disk_usage.test.ts)

---

Generated by Dyadbot persona-based code review

[github-actions]

🎭 Playwright Test Results

❌ Some tests failed

OS	Passed	Failed	Flaky	Skipped
🍎 macOS	450	0	4	159
🪟 Windows	448	1	2	159

Summary: 898 passed, 1 failed, 6 flaky, 318 skipped

Failed Tests

🪟 Windows

• editor_commit_menu.spec.ts > editor commit menu commits multiple staged files at once
  • Error: expect(locator).toBeHidden() failed

⚠️ Flaky Tests

🍎 macOS

• chat_completion_notifications.spec.ts > notification auto-closes when user focuses chat (passed after 1 retry)
• smart_context_balanced.spec.ts > smart context balanced - simple (passed after 1 retry)
• themes_management.spec.ts > themes management - AI generator from website URL (passed after 1 retry)
• turbo_edits_v2.spec.ts > turbo edits v2 - search-replace fallback (passed after 1 retry)

🪟 Windows

• app_screenshot.spec.ts > captures an app screenshot after the first generated commit (passed after 1 retry)
• coolify_deploy.spec.ts > connects to an instance and saves where the app deploys (passed after 1 retry)

---

📊 View full report