v4.11.0 — Cloud-sync data_dir guard

Cloud-sync data_dir guard

Preflight now detects when paths.data_dir lives under a cloud-sync folder and aborts startup with an actionable error before ChromaDB opens — preventing the native crash + auto-repair wipe loop that silently destroyed corpora on OneDrive/iCloud/Dropbox/etc. installs.

Added

• Preflight check that detects known cloud-sync providers (OneDrive incl. tenant variants like OneDrive - Contoso, iCloud Drive incl. com~apple~CloudDocs, Dropbox, Google Drive, Box, pCloud, MEGAsync, Nextcloud/ownCloud, Sync/Syncthing) and aborts with EX_CONFIG (78) + fix message before Chroma loads.
• Opt-in paths.allow_cloud_sync flag (default false) in config.example.yaml for users who understand the risk — demotes the abort to a warning and continues.
• Runnable self-check: python -m mcp_server.preflight → 13 asserts across supported providers + negative cases.

Changed

• paths.data_dir under cloud sync is now a startup error by default. Existing installs under Documents/ + OneDrive-synced M365, iCloud-synced macOS ~/Documents, Dropbox/Google-Drive-synced homes, etc., must either move data_dir to a local path (recommended) or set paths.allow_cloud_sync: true to acknowledge the risk.

Why

Cloud sync opens handles on live files to upload them, racing with ChromaDB's HNSW mmap writes and SQLite WAL/SHM. That triggers native access violations (0xC0000005 on Windows, SIGBUS on *nix). The 3-strike preflight probe failure path then invokes _backup_active_index() and moves the live index into data/backups/auto-repair-*, forcing a full reindex and effectively wiping the corpus. Reproduced empirically on Windows 11 + OneDrive + ~5.9k docs: crash → auto-repair wipe → 20 min reindex loop.

Migration

• Recommended: move paths.data_dir to a local path (%LOCALAPPDATA%\knowledge-rag\data on Windows, ~/.local/share/knowledge-rag/data on Linux/macOS).
• Fast fallback: add paths.allow_cloud_sync: true to config.yaml if you accept the corruption risk.

Full diff: v4.10.0...v4.11.0