claude agents (FleetView) crashed persistently with "undefined is not an object (evaluating 'e.checks.failed')", self-resolved without clear cause

Bug Description

claude agents (interactive FleetView) crashed on launch with an uncaught TypeError. The crash was persistent — every single attempt to run claude agents failed identically for an extended period (tried repeatedly across multiple terminal apps, after a full reboot, and after killing the daemon — none of which cleared it). It eventually stopped reproducing after ~20-30 minutes of investigation that involved temporarily moving job folders out of ~/.claude/jobs/ and back in — but the exact trigger and exact fix were not conclusively isolated (see Investigation below).

Environment

• Platform: darwin (macOS 25.5.0)
• Terminal: iTerm2 3.6.11, and also reproduced from Terminal.app
• Claude Code version: 2.1.220 (native install)
• Also reproduced on 2.1.218 (older cached binary at ~/.local/share/claude/versions/2.1.218, run directly) — rules out a 2.1.219/2.1.220-specific regression.

Error

ERROR undefined is not an object (evaluating 'e.checks.failed')

/$bunfs/root/src/entrypoints/cli.js:2901:5461

- iEo (/$bunfs/root/src/entrypoints/cli.js:2901:5461)
- <anonymous> (/$bunfs/root/src/entrypoints/cli.js:48200:24225)
- some (native:1:11)
- ifi (/$bunfs/root/src/entrypoints/cli.js:48200:24158)
- <anonymous> (/$bunfs/root/src/entrypoints/cli.js:48209:10741)
- map (native:1:11)
- gpm (/$bunfs/root/src/entrypoints/cli.js:48209:10662)
- no (/$bunfs/root/src/entrypoints/cli.js:2019:21369)
- Ov (/$bunfs/root/src/entrypoints/cli.js:2019:40466)
- j4 (/$bunfs/root/src/entrypoints/cli.js:2019:51400)

Steps to reproduce

Not reliably reproducible on demand — this is a report of a persistent-then-self-resolving crash, not a deterministic repro. Context that may be relevant:

1. Had ~15-20 background jobs in ~/.claude/jobs/ (mix of state: working/blocked/done), several tied to git worktree directories, some still actively running via the daemon.
2. claude agents began crashing with the above error on every attempt.
3. Crash persisted across: retrying multiple times, restarting iTerm2, trying from Terminal.app instead, a full machine reboot (which cleared the daemon and dropped tracked sessions from 23 to 4), and running an older cached binary (2.1.218) directly.
4. While investigating, moved subsets of ~/.claude/jobs/* folders out to a scratch directory and back in several times over ~20-30 minutes, retesting claude agents after each change.
5. At some point during this process the crash stopped reproducing, including when the full original set of job folders was restored. Re-running with configurations that had crashed earlier in the session no longer crashed.

Investigation performed / ruled out

• Not fixed by reboot: full restart cleared the daemon and background job count (23 → 4 tracked sessions) but the crash still reproduced identically afterward, same stack trace and line numbers.
• Not a version regression: reproduced identically on both 2.1.220 (current) and 2.1.218 (cached older binary run directly), so this isn't a 2.1.219/2.1.220-introduced bug.
• Not conclusively tied to one specific job record: bisected by moving job folders in/out of ~/.claude/jobs/ in batches. Removing some batches "fixed" the crash, but re-adding the same batches back afterward did not reproduce the crash — including fully restoring the original full set. This means we cannot point to one corrupted/malformed job file as the definitive cause; if we could reliably reproduce by re-adding a specific folder, we would have identified it, but we couldn't.
• Best working theory (unconfirmed): one or more of the background jobs may have been in a transient mid-update state — e.g. a checks field not yet populated while the job was transitioning between states (working → done) — and FleetView's rendering code doesn't guard against reading it in that window. This would explain both the extended persistence (the job could stay mid-transition for a while) and the eventual self-resolution (once that job's state settled, the field existed and the crash stopped) without any single file being permanently "corrupted."

Related issues (not exact duplicates, but same general area of instability around FleetView/background-agent state):

• #73754 — attaching to a stopped/idle background agent crashes with contradictory "currently running as a background agent" error
• #74750 — attaching to a previous-day background job via claude agents kills the worker (SIGKILL before init / resume-guard respawn loop)

Impact

While crashed, claude agents was completely unusable for an extended period, and any interactive session where a left-arrow/back gesture routes through FleetView also crashed, risking accidental disruption of other active sessions. The only usable workaround during the crash window was claude --resume <session-id> (with --fork-session if the daemon still considered the job "running") from the correct working directory, which reliably reached each session's content without going through FleetView.

Expected behavior

claude agents should never crash the whole process due to one job record's field being transiently absent — at minimum it should skip/gracefully degrade that row rather than throw an uncaught TypeError that makes the entire screen (and by extension, resuming sessions that route through it) unusable.