# What else changed

Differences beyond the PR's stop-timeout behavior are present in the recordings: generated identities and clocks, provider wording/usage/timing, cross-thread event interleaving, runtime diagnostic ordering, and cleanup transitions. These are disclosed below; the normalized and raw diffs preserve all payload/content differences. No additional product outcome regression was observed in the required fixtures. This is a bounded runtime observation, not a claim about all possible providers or hangs.

- R1: before remains running attempt 1 and later start stays pending/0 for more than 160s. After records five stop failures about 30s per attempt, persisted backoffs 100/200/400/800ms, terminal failed/5, and only then later real start, assistant reply, completed run and checkpoints. The extra provider/session/message/run/checkpoint events exist only after because that work unblocked. Before's subsequent SIGTERM cleanup requeues the stop and cancels unfinished work; it is separate from live behavior.
- R2: actual process loss and startup reconciliation occur on both sides. Both replay-safe stop rows requeue with 0ms delay, retain count 1, then claim attempt 2; both pre-crash process-bound pending starts cancel. Before stays running/2 for more than 130s. After attempts 2–5 time out with remaining backoffs 200/400/800ms, fail/5 and release only the new post-restart message, with real completed reply/run/checkpoints. Recovery warning counters and timestamps differ according to reached state. Before's final SIGTERM cleanup requeue/cancellation is separate from live behavior.
- R3: genuine stop succeeds on attempt 1 on both sides; claim-to-success is 63ms before, 54ms after. Both app-owned children have real running provider turns and both subsequent parent messages complete. The initial parent commentary differs: before “I’ll make the single requested local request and return the response verbatim.”; after “I’ll make the single requested request and return the raw response.” Provider tool-call/native-item identities, streaming payloads, token usage, timings and parent/child event ordering differ. Both finish with EVIDENCE_R3_NEXT, and all persisted event-type counts match between sides. No retry/timeout or product outcome difference appears.
- R4: before stays running/1 beyond 65s. After attempt 1 times out, 100ms backoff persists, attempt 2 succeeds after 25.009s, and later real start/reply/run/checkpoint follows stop success. No third attempt occurs. The extra provider/session/message/run/checkpoint events are downstream of unblocking. Before's SIGTERM cleanup is explicitly separate.
- R5: both retain EVIDENCE_R5_ORIGINAL_EXECUTOR_FAILURE after the 5s injected error, persist 100ms backoff, clear last_error on claim 2 and succeed on attempt 2 before releasing later real message. No Timed out cause replaces the original error. Actual execution/provider latency, diagnostic stack locations, IDs and timestamps differ; final behavior is preserved.
- R7 (labelled harness): both cancel the active stop at attempt 1 through the actual outbox service, interrupt the executor, clear cancellation registration and release the synthetic successor. Both remain cancelled/1 beyond 35s with no timeout retry. Recorded cancellation/settlement scheduling and clocks/IDs differ; no additional outcome difference appears. No actual provider reply is claimed.
- R8 (labelled harness): both keep non-stop checkpoint.capture running/1 beyond 35s and initial lease expiry, with later synthetic start pending/0. Both settle checkpoint then successor only after explicit gate release, without timeout/retry/reclaim. Recorded clocks and scheduling differ; no additional outcome difference appears. No actual checkpoint implementation behavior or provider reply is claimed.
- Across every pair: source commit/blob/hash and injection patch context reflect the requested before/after code; per-side checkout/home/project/output paths and UTC stamps differ. Random RPC command/message/task/provider-native/checkpoint IDs, bootstrap-derived nonsecret state, server/recorder/harness PIDs, lease owners, HTTP ports, git synthetic-commit identifiers, provider usage and telemetry counters, fiber numbers and source-stack line offsets can differ. Absolute dates/UUIDs/PIDs/ports/fibers/source hashes are normalized for the companion diff; statuses, attempts, errors, event content and ordering remain. Captured durations/backoffs remain in timing tables. Raw diffs retain every byte difference, including normalized-away identities.
- Startup diagnostics on both revisions include native resource telemetry sidecar unavailable and Codex rate-limit reads requiring first-party ChatGPT authentication. Their ordering/repetition depends on each observation window; neither prevents provider execution. Background/runtime activity and provider-event interleaving are not asserted to have deterministic order.
- Every before/after row uses the same driver version within that pair. R1 retains the inherited static hostname label in its original manifest; measured fs-37 is explicitly corrected in environment.txt and transcript headers. Later rows measure hostname. This provenance correction is unrelated to the source change.

R0/R6 have no minimum runtime capture: immutable source inventory confirms eligibility/bypass and durable-cancellation short-circuit before execution. The optional R6 harness was not run. The fixtures do not demonstrate recovery from synchronous JS blockage, uninterruptible work or hanging finalizers; source inventory records those limits.