The June 26 companion story starts with commit b10f890f, where Kieran Klukas changed Crush's config store so readers see copy-on-write snapshots instead of racing writers during startup and settings changes.
That contribution mattered because the failure mode was ordinary operator life: two sessions, reloads, model settings, Docker MCP config, compact mode, and credential refresh all touch shared state while an agent is still running.
The public trail
The copy-on-write patch added clone isolation and race tests, then replaced narrower reload locking with a single write lock for every operation that produces a new in-memory config. The commit message says the race detector had flagged concurrent startup and settings changes.
A second Klukas commit, de679203, tackled a more human failure: two Crush instances sharing one rotating OAuth login could invalidate each other's refresh token and both end up with authentication failures.
Why this contribution matters
The repair did not hide the problem behind a retry. It added in-process singleflight, a per-provider cross-process refresh lock, disk adoption of a peer's newer token, and tests that simulate two stores racing over the same credential.
Klukas also landed 21a457d5, which validates provider tool-call JSON before storing it so malformed arguments become an explicit tool error instead of a stuck conversation on every resend.
The conversation to open
The constructive question for Crush is whether these shared-state repairs should become a visible release note category for operators running multiple sessions or providers with rotating credentials.
The fairness limit is important: the commits prove source-level repairs and tests, not that every provider, filesystem, or multi-process edge case is closed.