TL;DR: Engineers maintaining long-running AI workflows can use this history to reconstruct completed work and resume interrupted tasks from saved evidence. While working on the coding project, I ran into a recovery problem: stopped runs and sessions needed clear records, turn identities, and checkpoints to show what had completed and where to continue.
Record a run so its result can be checked
On December 29, 2025, Pyash added a structured run “newspaper”: an ordered record of a program run. It captured run boundaries, requested actions, outcomes, tool activity, and artifacts—saved files or other outputs linked to the action that produced them. The goal was concrete: give an operator an inspectable record alongside the run’s final message. The next day, the runner gained an --again path and a companion replay command. On January 1, saved outputs gained content-addressed artifact identities—hash-based labels tied to the bytes themselves, so a changed file can be distinguished from its earlier version.
These steps answer a specific recovery question: does the saved output still match what the run recorded? Pyash’s replay check compares recorded artifact hashes with the current artifact bytes. The run specification defines an append-only event order and records each artifact’s locator, producer, and hash. Its later identity rules also validate links among command requests, results, approvals, and artifacts. A hash mismatch shows that saved bytes changed after capture; an incomplete identity graph points to a missing or conflicting record. Replay validation checks recorded evidence; a separate quality review decides whether the result solves the task. The replay change added tests for both a matching-hash success and a hash mismatch after an output changed. The January artifact change also preserved earlier bytes when a file at the same path was rewritten, giving each version its own content-addressed snapshot. See the run-newspaper commit, again-mode commit, and content-addressed-artifact commit. See also the run-recording and artifact specification.
Give each conversation turn an identity
In January and February 2026, the same record-keeping approach moved into Pyash agent sessions. Newspapers became automatic for mind runs, Pyash’s agent-turn runner, then the first agent-session context implementation introduced typed records for user requests, assistant responses, and checkpoints. Each successful turn could be reconstructed as a linked unit. An incomplete turn remained available in the audit record while the resumed prompt used completed turns and accepted evidence.
A turn identity lets the system answer, “Which request does this saved response belong to?” Idempotency is the rule that one logical request keeps one identity across retries. When a completed request returns, Pyash can reuse its saved response under the original identity, keeping one logical turn in the ledger. The ledger connects the user input, agent reply, and successful checkpoint through the same turn ID; a verifier can accept the exact turn it checked.
The request hash uses a small canonicalization algorithm. It removes timestamp fields, sorts object keys, serializes the normalized request, then calculates a SHA-256 hash. SHA-256 is a standard way to turn data into a fixed-length fingerprint. Sorting keys means equivalent maps keep the same fingerprint when their fields appear in a different order; excluding timestamps keeps routine time changes out of the request identity.
request → remove timestamps → sort keys → serialize → SHA-256 fingerprint
The hash and turn ID serve related but distinct jobs: the hash fingerprints request content, while the turn ID links the records for a particular session turn. Session replay reconstructs past conversation; workflow resumption, described next, decides which active work can advance. The session-context work began in February, then hardened session replay and connected verifier acceptance to the replayed turn. The session-replay code implements the canonical request hash. The agent specification documents how completed turns enter resumed context.
Turn long-running work into resumable steps
On August 7, I set the next requirement in a Pyash work session: make long-running backlog work safe to resume after crashes or blocks. I prioritized idempotency, human resumption of blocked tasks, scheduling, quota awareness, and clear operator status. I also set the scope: this stage would use a durable supervisor and backlog runner, with multi-worker execution and automatic merging held for later. That request led to two related changes that day: a durable supervisor cycle and a resumable work backlog runner.
The next additions filled in the recovery path. An August 24 change made headquarters approval—Pyash’s human decision step—resumable from the decision bound to a task checkpoint. An August 29 change compacted review-loop context, preserving the original work request and the latest accepted evidence as a new review began. A checkpoint is a saved description of the work state: its task, phase, accepted evidence, and identity. This lets a restart find the named step and rebuild context from the original request and latest accepted evidence.
Timeouts exposed another edge. A September recovery review found implementation turns reaching the old fixed 900-second limit while still making progress. The policy changed to a 900-second inactivity timeout, reset by progress through the Codex App Server, the interface that streams remote turn activity to Pyash, plus an 1,800-second hard maximum. Checkpoints retained partial output, turn identity, Git commit (revision), changed files, status, and a diff, a line-by-line view of the changes. If a remote turn’s outcome was ambiguous, the saved checkpoint marked it for reconciliation: comparing the recorded state with what the remote service actually did before continuing. The project’s completion report recorded 49 of 49 focused reliability checks and 130 of 130 checks in its portable test:ci continuous-integration lane. On September 12, a further change let a paused task whose status had grown stale continue after its state was reconciled. The supervisor and backlog runner were followed by approval resumption, bounded review context, timeout recovery, and stale-continuation handling.
The distinction matters in practice: replay checks the integrity of completed records; resumption reconciles the current checkpoint and advances an unfinished task. A saved history can show what happened, while a checkpoint names the work that is ready to continue.
Reuse the pattern in batch jobs and coding sessions
By October, Pyash applied checkpoint round trips to multi-stage work. One source-to-very-long-instruction-word (VLIW) translation workflow used durable stage outputs and checkpoints so a later stage could continue from recorded intermediate results. The example shows how the same recovery pattern fits a batch pipeline: give each phase a bounded input and output, then record where the next phase should begin. The project added both a checkpoint replay test and durable translation checkpoints. The checkpoint round-trip and translation pipeline work document that application.
The same question became immediate in November, when a saved coding session failed to replay. After I opened a second Saddle (Pyash’s interactive coding session), the first began reporting a conflict between an assistant response and its checkpoint. A follow-up inspection traced the conflict to quoted shell text: a literal dollar-and-backtick sequence was interpreted as JavaScript replacement syntax while the session parser restored the text. The response and checkpoint had matched in storage; parsing changed their text differently during replay.
The repair treated quoted text literally, and a regression test covered the exact class of text that caused the problem. The request was to resume the existing biography session. A later change added resumption of the latest Saddle session after an idle gap. On November 11, I described the next desired step as a persistent, selectable terminal that could fork its own context and resume through Saddle session selection. This remains the design frontier at the end of the source history. The November replay repair and idle-gap session resumption connect parser correctness to the larger recovery design.
Keep evidence verifiable and storage bounded
Once run and session records became useful for recovery, they needed a clear storage lifetime. November changes recorded mutable artifact revisions, tied artifacts to retained newspapers, added safe cleanup, and set a 30-day maximum age for newspapers and artifacts. A combined 500 MiB newspaper cap also bounds stored run records. Cleanup previews its plan first; applying deletion requires an explicit operator action. A retained newspaper keeps its referenced artifacts available, while unreferenced expired data can be collected after the reference scan.
The maintenance path revealed one more practical limit. On November 11, I reported that artifact-retention validation could exhaust the Node.js heap, the memory available to a JavaScript process; the bridge catalog returned 954 rows where the test expected 956, and a newspaper-identity test failed in the full suite after passing alone. A commit later that morning introduced a shared test runner that divides quiz files into bounded batches and selects concurrency from available CPU and memory. It also makes an oversized newspaper scan an explicit incomplete scan, preserving the safety check around artifact deletion. The change gives the validation workload a memory budget and makes the scan limitation visible. The retention series added safe cleanup, pinned artifacts to retained newspapers, included root newspapers in the storage cap, set the 30-day policy, and added memory-bounded test batches.
A recovery pattern readers can apply
For a system you maintain, choose a realistic interruption boundary, such as a process stopping after an external service responds but before the response is saved. Name the states an operator will see—queued, running, awaiting approval, complete, or paused for review—and identify what authorizes each transition. On restart, compare the saved operation identity with the current external state and route ambiguous actions through reconciliation. Continue from a named phase after its checkpoint and request identity agree.
Then make the maintenance path explicit: set age and size limits, preview cleanup, and preserve evidence still referenced by retained records. Run recovery checks in bounded batches so a full regression run stays within the host’s memory budget. A compact status view can expose the current phase, last verified outcome, unresolved external action, and safe next step. That gives an operator a clear decision path at the exact point where a restart could repeat work or skip an unfinished step.
