Three independent mechanisms have been documented or observed writing files back to host filesystems, each producing the same aggregate outcome: forward development is reverted to an older baseline state. Each operates through different infrastructure, with different authentication, at a different layer of the stack. None requires the others to function. Together they represent a resilient write-back surface that operates across multiple trust boundaries simultaneously.

Mechanism 1 — sdk-daemon Updater

Documented at cowork.exponential-systems.net. The sdk-daemon running inside the Cowork Linux VM detects file hash drift against the deployment hash and writes files back through the virtiofs guest-to-host mount. The restoration operates without user interaction, without parent process signal, and without notification. The write surface is not bounded to a single directory — any path accessible through the virtiofs mount can be monitored and restored.

PropertyValue
InfrastructureHyper-V VM → host via virtiofs mount
AuthenticationVM configuration (mount permissions)
TriggerFile hash drift from deployment hash
Observed instancecatabolism.js restored at 23:15 — documented Feb 19, 2026
Write scopeAny path in the configured virtiofs mount

Mechanism 2 — OneDrive Cloud Sync

Documented at onedrive-delivery. OneDrive (Microsoft cloud sync client, internal codename: saturn) was directly observed silently replacing ReactNativePicker.dll on DESKTOP-B7SG880 during the March 14, 2026 investigation. Two builds differing by 10,552 bytes and compiled 29 days apart were recovered and PE-analyzed. Both are signed Microsoft components. The replacement was in-place and silent.

PropertyValue
InfrastructureMicrosoft cloud (OneDrive) → local filesystem
AuthenticationMicrosoft account (linked to synced directories)
TriggerVersion available in cloud newer than local copy
Observed instanceReactNativePicker.dll replaced, March 14, 2026 — directly observed
Write scopeAny directory included in OneDrive sync configuration

Mechanism 3 — Destructive Autosync (repo-sync.sh)

Documented in INCIDENT-ZORIN-WIPE-AUTOSYNC-20260416. A repo-sync.sh script using git reset --hard origin/main and git reset --hard origin/HEAD was deployed to the Zorin machine April 13, 2026 — the same window as the tiny-agents execution. The same destructive pattern had appeared previously as INCIDENT-004 (February 5, 2026), making this a recurrence at a 10-week interval. The pattern destroys local development by overwriting it with the remote origin state.

PropertyValue
InfrastructureGit remote origin → local Zorin filesystem
AuthenticationGit remote credentials (GitHub)
TriggerScheduled execution (cron)
Observed instanceFirst: Feb 5, 2026 (INCIDENT-004). Recurrence: April 13, 2026 (10-week interval)
Write scopeAll git repositories in the sync manifest (April instance: 301 repos)

Same Outcome, Three Layers, Independent Operation

Each mechanism reverts local development to an older remote/cloud/deployment state. Each operates independently — the sdk-daemon updater does not require OneDrive; OneDrive does not require the autosync script; the autosync script does not require the VM. Disabling any one does not disable the others. A development environment subject to all three simultaneously has no stable local state: changes can be reverted at the VM layer, the cloud sync layer, and the git layer, through three different infrastructure paths that do not share authentication or trigger mechanisms.

Relationship to Evaluator Modification

The x01-capability-restructuring page documents that after the Cowork audit was published, the capability evaluator was modified to prevent it from confirming two capabilities the audit identified. The evaluator's source, test suite, and repair pathway are all potentially within the write surface of Mechanism 1 (sdk-daemon updater via virtiofs).

Mechanism 3 (autosync) operated on the Zorin repository that contained RFC-ARENA-CURATION-001 during the April 8–13 window — the same window as the tiny-agents execution. The 301-repo wipe destroyed the April 14 working state that had never been committed upstream.

The three mechanisms have each operated in proximity to significant development or investigation events. Whether that proximity is coincidental is not established by the presented evidence.

Sources: cowork.exponential-systems.net (sdk-daemon updater, 23:15 event)  ·  onedrive-delivery (OneDrive observed, ReactNativePicker PE analysis)  ·  INCIDENT-ZORIN-WIPE-AUTOSYNC-20260416.md (autosync recurrence)  ·  INCIDENT-004 (Feb 5, first autosync instance)