[Bug] Concurrent Python and TypeScript harness writes can lose accepted changes

[fettpl]

Affected area

Continual harness persistence in the coding agent and Python runtime.

What happened?

The same harness state can be written by Python CRUD and TypeScript refinement without a shared transaction boundary. Python has an mtime-based reload guard, and TypeScript has atomic replacement, but neither closes the interval between read and write across processes.

• Python reload checks mtime before mutation; save truncates and rewrites the state file in place.
• TypeScript save uses temporary-file rename, but does not check an expected revision or hold a cross-process lock.
• Refinement apply rereads state immediately before applying and saving. That reduces the stale window but does not serialize another process.
• Both loaders degrade unreadable/malformed data to empty state, which is useful for keeping the session available but unsafe as an implicit writable replacement for durable knowledge.

Steps to reproduce

Use disposable harness directories only; no real user harness is required.

1. Start with one valid state containing an existing memory.
2. Coordinate two writers targeting that file. Pause each after its final read/mtime check but before save; have them add different IDs.
3. Resume both saves. A last-writer-wins whole-file replacement can discard the other accepted change.
4. Separately pause a Python write after opening with w, read from the other process, and inspect the malformed/empty fallback behavior. Do not use timing sleeps when a deterministic barrier can expose the window.

This is source-verified; the coordinated process fixture was not executed during this read-only audit.

Expected behavior

Distinct accepted mutations survive concurrent writers. A crash or temporarily unreadable file must not silently erase prior harness knowledge.

Acceptance criteria

• Python and TypeScript share one transaction protocol covering reread, mutation validation, and durable replacement.
• Distinct concurrent updates survive; conflicting edits produce a deterministic conflict/retry outcome.
• Python uses atomic replacement rather than truncating the live file.
• Revisions or equivalent compare-and-swap semantics detect stale writes; mtime alone is not the transaction token.
• Malformed state is quarantined/reported or put into a read-only degraded mode, not silently replaced as an empty writable store.
• Lock recovery is owner-aware, and state/history failure handling has an explicit recovery contract.
• Tests cover Python/Python, TypeScript/TypeScript, mixed writers, interrupted writes, conflicting edits, and stale-owner recovery.

Solution design and verification

Choose a shared filesystem transaction protocol or a single host-owned writer; either must preserve local/global scope behavior and keep degraded reads from blocking ordinary agent startup. Use the current atomic TypeScript writer as a starting pattern, add cross-language barriers/fault injection, and document the schema/revision migration. If a daemon command is introduced, apply the repository's protocol/capability compatibility rules.

Additional context

Revalidated from closed #929 / PR #961. Accepted #1380 is the broader crash-safe persistence tracker; this discussion isolates the cross-language harness boundary. Discussion #1765 covers settings/auth/migration storage, not this store. Existing local hardening is acknowledged above.

Please confirm whether this belongs under #1380 and whether maintainers want an implementation. I will wait for an invitation.

Version and environment

Source audit of main@cd10724fe02bbe9a18592737de17c8101710bf73 (package version 0.9.1), 2026-09-03. Reviewed a clean source snapshot on macOS 26.6.2 (25G83), arm64, zsh 5.9 in a non-interactive Codex terminal. Installation method: source snapshot; no installation or live application reproduction was performed. The steps above describe isolated verification, not a claim that a production failure was induced.