Background job files can be stored somewhere other than disk, but nothing switches that on yet.
Job state, sidecar and roster writes have a storage-backend branch with versioned keys; with no backend supplied the filesystem path runs unchanged.
What's wrong with this entry?
Job state.json, the order/stateOrder/group sidecars and the roster orphan-adoption write each gained a branch that goes through a storage backend object instead of the filesystem, using versioned keys, ifAbsent preconditions and size caps. Filesystem behaviour is unchanged when no backend is supplied, and what turns the backend on could not be determined from source.
- covers job state reads and writes, the three sidecar files, and the orphan-adoption seed write
- failures on the backend path emit new warn-level diagnostics rather than throwing
- when no backend object is handed in, the original filesystem path runs untouched
[jobs] v5 state write failed
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.227
Deleting a background job keeps a directory a live session is sitting in
Both mention background
-
v2.1.248
claude logsno longer lets replayed output corrupt your terminalBoth mention background
-
v2.1.248
Job list offers "open" rather than "resume" for a job already attached to a terminal
Both mention background