[jackeyfaker77]

Summary

Write/Edit can currently proceed after another writer changes a file during the gap before execution. This PR captures transient preconditions before T1 and checks the file descriptor's identity, byte count and content hash before mutation. A detected change rejects the operation without overwriting the changed bytes.

The scope has been narrowed following #6130 and the retirement of the old reconciliation roadmap. This revision removes this PR's persisted recovery evidence, Core contracts/exports, dispatch binding, conversation-copy rebinding and recovery-roadmap additions. It does not reintroduce a bundle writer, recovery registry or reconciler. T1/T2 schemas and the current unknown-outcome / no-auto-replay policy stay unchanged.

• Retain the existing permission boundary, workspace/parent/target identity checks, private argument snapshot, per-target lock and execute/cancel cleanup ownership.
• Compute UTF-8/size eligibility from the private input snapshot before file observation; preparation requests carry only kind, target and eligibility, without replacement text. Ineligible inputs still pass preparation permission checks. The prepared handle exposes only execute/cancel.
• Prepare only bounded pre-state metadata; no expected-after hash or predicted result/diff. Edit matching and result construction run during execution, preserving actionable edit_conflict errors.
• Use filesystem worker protocol v15 to reject older workers that cannot honor the transient guard. This is separate from the Host compatibility epoch inherited from main.
• Apply to eligible durable Write/Edit preparation paths. Unsupported observations keep ordinary execution; a failed established guard never falls back to an unguarded mutation.

Boundaries and cost

This protects changes after preparation, not changes since the model's earlier Read. Eligible pre-state files are regular UTF-8 files up to 1 MiB; mutation input strings are bounded to 1 MiB each. The process-local lock does not exclude external writers, and checking then writing is not an atomic cross-process compare-and-swap. Both tools remain never_auto_retry.

Worker-backed preparation still adds a second subprocess. A Windows / Node 24.20.0 filesystem-executor microbenchmark (Write/Edit, 4 KiB and 256 KiB, two warm-ups; 7 worker or 21 local samples per case) measured these ranges of case medians:

Variant	Worker latency	Local latency	Worker processes/call
Main (2b0e4a25) ordinary execution	377–422 ms	2.37–3.75 ms	1
Original evidence implementation (c28bda560)	700–811 ms	5.38–6.77 ms	2
Narrowed guard before this follow-up (c41ca330f)	630–690 ms	4.67–8.05 ms	2

Baseline comparisons used isolated snapshots of the relevant source modules with shared dependencies, not separate clean builds. The harness launched unbundled worker-entry modules through an injected adapter; it did not exercise the production bundled worker/client path. The table predates the payload optimization; no new latency improvement is claimed for it. These are local microbenchmarks without SQLite/T1 or native OS sandbox enforcement, not production latency estimates. Narrowing removes unused persistence and duplicate computation but does not eliminate preparation overhead or improve every measured case.

Validation

Current revision: 7b801b468, following the reviewed narrowing at c41ca330f (which includes main at 2b0e4a25).

• Full root build, typecheck, lint and format checks passed; desktop/UI Knip and ASF headers passed.
• 65/65 tests passed across the content-guard, ToolRuntime settlement and durable-boundary suites. Coverage includes real worker subprocesses, changed content/inodes/parents, missing targets, T1 failure, cancellation/cleanup, result parity, private snapshot isolation and old protocol rejection.
• Independent Codex review found a guarded Edit error-classification regression. Added real worker missing/ambiguous-match tests, verified they failed before the fix, then preserved edit_conflict and its original message. Re-review independently passed the worker and lifecycle checks and found no remaining P0–P2 issue. This is automated review, not human approval.
• Payload follow-up: independent Codex review found no P0–P2 issue; it independently passed all 24 guard tests and 11 client preparation/permission tests (one additional Linux-specific test skipped). Eligibility remains separate from authorization, and private guard copying remains intact. A separate 12-subprocess probe of the actual built worker bundle passed, covering v15 preparation, ineligible fallback, v14/old-payload rejection, stale content and matching execution; no native OS sandbox was used.
• Broader worker/builtin suites: 49 passed, 9 failed, 1 Linux-only skip. All nine failures also reproduce with the relevant latest-main source modules on this Windows host: symlink privileges and POSIX/Linux path/descriptor assumptions. No assertions or permission checks were weakened.
• Windows workflow source-closure/inventory tests passed 6/6; Windows skip inventory passed. Artifact budget tests passed 7/7 (242 packaged dependency instances).
• Renderer architecture checker fixtures: 166 passed, 1 failed, 1 skipped. The failing canonical-entry fixture assumes /fixture/... paths; its test and plugin are identical to main. The actual architecture check passed with --base upstream/main --strict-base.
• This is not a full monorepo test run or native Windows/macOS/Linux sandbox qualification. Post-push CI remains authoritative for its covered environments.

AI use

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

OpenAI Codex assisted with implementation, tests, documentation, measurements, review and this description. Affected commits retain Generated-by: OpenAI Codex trailers.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

The second checkbox remains unchecked because of the baseline Windows failures described above.

Does this PR entail a change in behavior?

• Yes — described above
• No

[Astro-Han]

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.

I reviewed the complete 20-file change at 04d2b7d6c3f324e43f25dca3466ab6fa87f07375: versioned file evidence and decoding, Write/Edit preparation and execution, worker permissions/protocol, the existing T1 transaction, cancellation/locking and conversation-copy rebinding. One P2 remains: the new unconditional cleanup at packages/runtime/src/tool-runtime.ts:1922 breaks the existing successful Client Capability settlement contract and causes this PR's CI failure. The inline comment identifies the failing assertion and comparison.

The pre-dispatch evidence premise is observable, not just an issue proposal. In 18 independent child-process controls, terminating the actual Runtime process after committed T1 or before T2 left the operation prepared after SQLite reopen/rebuild. The file respectively remained unchanged or contained the expected new content. This head retained the bound before/expected-after fingerprints; removing preparation from the same builtin tool retained those file effects and operation states but no trusted file evidence. Seventy-two rehashed cross-identity substitutions were rejected, and historical events without the optional field remained readable. These observations demonstrate evidence persistence, not successful automatic recovery.

Scope and cost need a maintainer decision: the recovery registry, observer/reconciler, scan and Host recovery lifecycle are still absent. Worker-backed writes add a preparation process before execution, plus bounded hashing and result construction; production performance was not measured. Write/Edit retain never_auto_retry. The first contract covers regular UTF-8 files with before/after sizes up to 1 MiB and result JSON up to 256 KiB; unsupported observations retain ordinary execution without recovery eligibility. The in-process lock and descriptor checks are not cross-process CAS. The immediate change is therefore evidence production and guarded normal execution, not complete production file recovery.

The producer, execution guard, T1 binding and copy rebinding form one coherent contract: separating them would either persist a prediction that execution does not check or make copied events fail their identity validation. Keeping future recovery registration, reconciliation and lifecycle work separate is appropriate. Write and Edit could be stacked separately for review size, but I did not find an unrelated feature that must be split out of this patch. Whether to land this foundation before its recovery consumer remains a product/design choice, not approval implied by passing tests.

Validation: fresh dependency installation and root clean build; 307 passing tests across 19 complete Runtime/Core files covering file operations, durable boundaries, crash windows, copy and permissions. The complete settlement test file adds 13 passes and one failure, reproducing CI's extra cancel after successful admission; substituting the exact main ToolRuntime module in memory makes the same unchanged file pass all 14 tests. The other dependencies remain at this PR head, so that comparison isolates the changed module rather than claiming a full main-suite run. Core/Runtime/Host typechecks, 16-file Biome check, diff check and protocol guard passed. The independent crash probe used actual SIGKILL and the real local bypass executor/SQLite authority, not a simulated exception. Existing tests also exercised real one-shot workers and copy rebinding. Native Linux sandbox execution could not run locally because bubblewrap is absent; native macOS/Windows, the complete monorepo suite and a recovery consumer were not locally validated.

The internal filesystem worker protocol moves from 11 to 12; Runtime Host epoch remains 220 with no Host protocol change. The merge with current main 6c63fa05 is clean. Exact-head Windows packaging, recovery and W0 evidence checks and dependency audit succeeded, but CI 38395346636 failed on the settlement assertion above. This is a PR-caused failure, not one of the documented Windows baseline cleanup failures. Neither passing checks nor this review imply feature approval.

[Astro-Han]

[P2] Close the settlement-contract regression introduced by cleanup

This unconditional cancel() now runs after a prepared Client Capability has executed successfully, not only when admission/T1 fails. Exact-head CI run 38395346636 fails the unchanged prepares Bypass Client Capability work before T1 and admits only after T1 test: actual order is ['prepare', 'T1', 'admit', 'cancel'], while its established success contract expects ['prepare', 'T1', 'admit'].

The complete test file reproduces this locally (13 pass, 1 fail); loading the exact 6c63fa05 ToolRuntime module in memory with the same test and other dependencies makes all 14 pass. This isolates the PR-caused CI failure. The production broker treats cancellation of an already-retired invocation as a no-op, so this evidence does not establish that completed production invocations are actually cancelled. Filesystem preparation needs reliable resource release, but its new cleanup must either be scoped appropriately or explicitly reconciled with the existing prepared-tool success contract and tests before this head is ready.

[Astro-Han]

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.

At a0f156ff9b3a65dfeec33f30df955c1c3515d0bb, the previous P2 settlement-order finding is fixed. No additional P0–P3 issue was established in this increment.

The change transfers cleanup ownership to the prepared executor immediately before calling its execute method (packages/runtime/src/tool-runtime.ts:1648–1658). Runtime therefore cancels only preparations that never entered execution. The unchanged Client Capability success test again observes prepare → T1 → admit, without an extra cancel. Loading the exact 04d2b7d6 ToolRuntime into the same test still reproduces the old extra-cancel failure; the rest of the dependencies remain at the new head in this comparison.

The failure and cancellation paths also retain cleanup:

• A preparation cancelled after T1 publication fails, or when T1 itself fails, does not execute.
• Once execution starts, its executor releases its own resources on success, execution failure or abort; Runtime does not cancel that completed/executing object again.
• Twelve independent real Write/Edit checks cover success, T1 failure, publication failure, execution failure, abort before execution and abort during execution. Each check uses the actual filesystem preparation and SQLite commit paths, verifies the expected file contents and durable success/error/aborted outcome, then performs another prepared Write on the same target to prove that the real lock was released. The failure and abort timing are controlled test seams, not live provider incidents.

The original 18-process crash/reopen checks also pass: owned child processes are killed after committed T1 or before T2, and SQLite rebuild retains the expected evidence and operation state. The preparation-removal controls retain the same file effects but lack trusted evidence; 72 rehashed cross-identity substitutions are rejected and legacy events remain readable. These checks still do not exercise a Host recovery reconciler, native mount sandbox or cross-process compare-and-swap.

The increment contains two commits: the cleanup change and a validation-rerun commit with no source changes. The net diff affects Runtime and its settlement tests (+75/−4), with no rebase, new evidence format, or additional feature scope. A fresh dependency installation and normal clean build succeeded. Eight complete Runtime/Host test files passed 145 tests with no skips, including all 16 settlement tests and the existing Host broker/coordinator tests. Runtime and Host type checks, scoped Biome, whitespace checks and the protocol guard passed. This is not a full-monorepo, native-platform or live-provider validation.

Epoch 220 and the existing worker protocol 12 are unchanged from the preceding head; no storage-schema change was added. The head merges cleanly with fetched main 6c63fa057ed97916b77db3ff002a13636d6a564a; that synthetic merge was not separately built. At the final check, CI and audit were queued, Windows packaging was running, and the recovery and sandbox evidence checks had succeeded. This does not mean all checks are complete. The earlier feature-scope caveats remain: this PR produces evidence and guards execution, but does not implement recovery reconciliation; feature adoption and merging remain human decisions.

[Astro-Han]

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.

At 2b3eff5a3931289f128c3e7555fdc45cea3f48d8, I found no new P0–P2 issue in the changes since a0f156ff. The earlier cleanup-ownership fix remains intact.

The merge with main 331340ab preserves all five original author commits. Its only textual conflict was the filesystem-worker version: both parents independently used v12 for different contracts. packages/runtime/src/filesystem-worker/protocol.ts:30 now uses v13 for the combined prepared Write/Edit and chat-image contract. Request and response schemas require that version, and the real client rejects a v12 response before accepting its result (client.ts:752). The separate Host compatibility epoch is 222, inherited from main; its guard reports no Host protocol change against the merge parent.

I verified the built worker through 16 actual subprocesses. Four v12 mutation requests were rejected without changing the file. For both Write and Edit, v13 preparation left the file unchanged, matching guarded execution succeeded, and an externally changed file caused execution to fail without overwriting those external bytes. Chat image reads preserved the exact bytes of a 2560×1 PNG; ordinary reads still refused that image, and oversized/invalid images retained their typed errors.

The cleanup transfer in tool-runtime.ts:1655 is unchanged. Twelve real Write/Edit scenarios again passed through filesystem preparation and SQLite persistence, covering success, T1 failure, publication failure, executor failure and cancellation before/during execution. Each case then acquired the same target's lock for another prepared Write. These use controlled failure timing; they do not test native OS sandbox enforcement or a recovery reconciler.

The two subsequent commits only add marked@18.0.11 to the packaged dependency ledger and correct the AppShell token count from 7285 to 7280. Both ledger files are byte-identical to their counterparts in #6129. These two lines duplicate/overlap that PR; rebase after #6129 lands to reconcile them.

Validation: the normal clean root build and Host type check passed before those ledger-only commits; production sources, tests, dependencies and the lockfile are unchanged by them. On the final head, all 151 focused tests and both subprocess/filesystem probes passed again. Full formatting, whitespace, strict renderer architecture (168 checker tests), artifact budget (7 tests; 242 package instances), Windows skip inventory and the epoch guard passed. This is not a full-monorepo, native Windows/macOS/Linux-sandbox or live-provider validation, and I did not rerun the earlier crash/reopen campaign.

At the final snapshot, CI, Windows packaging and sandbox evidence were still running; audit and Windows recovery had succeeded. The current head is therefore not yet all green. This remains an evidence-producing feature, not recovery reconciliation; feature adoption and merging remain human decisions.

[Astro-Han]

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.Incremental review: 2b3eff5a..50565abd, a merge of main at d14cec57 plus one test-only commit. I found no P0–P2 issue, and CI test passes on this head.

• Merge: the only hand resolution is the AppShell nonTriviaTokens value in renderer-architecture.json, which takes main's 7276. That correctly drops the CI-ledger lines this PR had duplicated from #6129. The Write/Edit evidence code is unchanged.
• 50565abd: eventually() in event-wait-manager.test.ts now polls on a 5 s wall-clock deadline with 5 ms sleeps, instead of 100 rounds of setImmediate. The injected observation clock stays fixed, so the timeout and Retry-After assertions stay exact. The new self-test checks that delayed host work completes without advancing that clock or firing its timers. This is a reasonable fix for a flaky test.

P3 (scope): event-wait-manager.test.ts belongs to the event-wait feature from #6113, not to Write/Edit evidence. If this is a flake on main, a small separate PR would let it land independently of this feature.

[jackeyfaker77]

Thanks @Astro-Han for the review. I’ll move the event-wait test fix into a separate PR against main, run the tests and an independent agent review, then remove it from #6089 so this PR stays focused on Write/Edit evidence. I’ll link the separate PR here once it is ready.

[Astro-Han]

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.Incremental review: 50565abd..c28bda56. The event-wait test change is reverted here and moved to its own PR, #6140. This resolves my scope P3. No other change. I found no P0–P2 issue, and CI test passes.

[jackeyfaker77]

With #6130 now merged, I plan to narrow this PR to execution-time file-content consistency checks, aligning it with the current recovery contract.
I’ll remove the persisted Write/Edit recovery evidence, dispatch-identity binding, and conversation-copy rebinding. The remaining checks would use transient state to reject a Write/Edit if the target’s content or identity changes between preparation and execution, before truncating or overwriting it.
This would not provide crash reconciliation, automatic replay, or protection against all concurrent writes. Existing T1/T2 and unknown-outcome handling would remain unchanged. The additional preparation and I/O costs would still need measurement to justify the narrower feature.

[Astro-Han]

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.

Review at c41ca330f129f9e1836e16bd81216a76fc715d24. I found no new P0–P2 issue. I read the complete 17-file diff against main 2b0e4a25, the merge's additional resolutions and the removal of the earlier persisted-evidence path. The current implementation captures transient preconditions before T1 and checks the file descriptor's identity, length and content digest before mutation (file-mutation-guard.ts:215). Core contracts, storage, conversation copying, dependency manifests and the lockfile are byte-identical to current main. The previous concern about landing persisted recovery evidence before its consumer is addressed by removing that evidence, dispatch binding and copy rebinding. T1/T2 retain main's schemas and never_auto_retry behavior.

The narrower correctness premise is independently observable. Through the actual ToolRuntime, builtin Write/Edit, local filesystem executor and SQLite T1/T2, I changed an existing file on the same inode immediately after T1 committed. Both tools rejected execution and preserved before external\n, recording an ordinary error outcome. Loading only the actual main builtin-tools module instead makes Write replace that content and Edit change it to after external\n. This comparison isolates the missing preparation step while retaining the current dependencies and Runtime; it is not a full main-suite comparison. No model or native OS sandbox was used in these checks.

All 219 tests across 12 complete Runtime files passed, including real worker guard/error cases, read-only permission rejection, directory/target replacement, private argument isolation, unsupported observations, settlement and durable-boundary behavior, copy, locking and mutation outcomes. A separate 18-subprocess check of the built worker bundle rejected v12/v13 requests before mutation, preserved external bytes on stale guards, accepted matching guards and retained the chat-image read contract. Guarded missing/ambiguous Edit matches retain edit_conflict and the ordinary error message. Twelve actual prepared Write/Edit lifecycle scenarios also passed with SQLite outcomes and same-target lock reacquisition after success, T1/publication/executor failure and cancellation. The earlier successful Client Capability cleanup contract remains intact.

The normal root clean build passed after a fresh dependency installation and dependency patches. Runtime/Core/Host and five Desktop TypeScript configurations, Biome on 14 changed code files, ASF headers, six Windows workflow/inventory tests, Windows skip inventory, strict renderer architecture with 168 checker tests, artifact budget (242 package instances) and whitespace checks passed. The internal filesystem worker protocol is 14; the separate Host epoch remains 227, and its guard reports no Host protocol change. This head already includes current main and is mergeable.

The documented limits remain material: protection starts at preparation, regular UTF-8 pre-state/input strings are bounded to 1 MiB, unsupported observations use ordinary execution, and the final check/write still has a cross-process race. Worker-backed calls retain the extra preparation subprocess. I did not independently reproduce the author's Windows latency measurements, rerun the complete monorepo suite or qualify native Linux/macOS/Windows sandbox enforcement. Earlier crash/reopen evidence tests no longer describe this implementation and were not reused as acceptance evidence.

At this snapshot, exact-head CI test is still running; Windows packaging, Windows recovery and W0 protocol checks succeeded. Final CI still needs to complete before treating this head as all green.

[jackeyfaker77]

I will make a small follow-up to reduce overhead within the current transient-guard design:

• Check mutation input eligibility before file observation, so ineligible inputs do not incur an unnecessary content read/hash.
• Stop sending complete Write/Edit replacement strings in preparation requests; determine eligibility from the executor's private argument snapshot and keep the request limited to the preparation metadata.
• Keep the guard private to the prepared executor and remove the unused outward-facing guard interface and unnecessary result copying.

This will retain the two-process worker design, pre-T1 permission checks, directory/target/content validation, private execution arguments, locking/cancellation ownership and ordinary fallback for unsupported observations. It will not add a worker pool or change recovery behavior. I will run the affected tests and an independent automated review before pushing the follow-up.

One clarification about the existing latency figures: the microbenchmark used unbundled worker-entry modules and an injected worker adapter, not the production bundled worker/client and native sandbox path. Those measurements demonstrate overhead in that harness; they are not released-application latency estimates. These small changes do not claim to eliminate the extra process-start cost.

[Astro-Han]

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.

Incremental review at 7b801b4680e58688f944ea7f16629837b20b4192, following c41ca330. I read all nine changed files and found no new P0–P2 issue. Input eligibility is now computed from the private argument snapshot before content observation; preparation transports only kind, target and eligibility. The guard stays inside the prepared executor, and removing the Write-only wrappers/result clone preserves the shared execution path. Builtin tools, ToolRuntime, the permission client, dependencies and storage are unchanged by this commit.

All 224 tests across the same 12 complete Runtime files passed. The new cases cover the exact UTF-8 byte boundary and invalid surrogate inputs, ordinary execution for oversized inputs, private caller/backend-object isolation, metadata-only request shapes, write permission checks even when eligibility is false, rejected legacy wire versions and actionable Edit errors. The strict v15 schema rejects preparation payloads containing replacement text. The internal worker protocol advances from 14 to 15; the separate Host epoch is unchanged.

I also reran 20 actual built-worker subprocesses, including v12/v13/v14 rejection before mutation, matching/stale guards and chat-image behavior; all passed. Twelve real prepared Write/Edit lifecycle scenarios passed with SQLite outcomes and same-target lock reacquisition. The actual ToolRuntime/SQLite check again preserves externally changed bytes for both tools after T1; loading only main's builtin module instead applies the writes to those bytes. These checks confirm the retained execution protection and cleanup. They do not measure production latency or native sandbox enforcement.

Fresh dependency installation/patching, the normal clean root build:test, Runtime/Core/Host type checking, Biome on eight changed code files, ASF headers, six Windows workflow/inventory tests and whitespace checks passed. A static merge with main ca4ac75c9d157bb49bd7d0feae975f2574a7ca55 is clean and passes the Host epoch guard at 227; that merged tree was not separately built. The documented extra preparation process, 1 MiB eligibility limits, ordinary fallback and cross-process check/write race remain.

Exact-head CI test and Windows packaging are still running; Windows recovery and W0 checks succeeded. The preceding commit's green CI does not cover this new head. I did not repeat the full monorepo suite, native OS sandbox qualification or performance measurements for this increment.