Problem

Developer undo history persists whole-file snapshots as JSON in <config>/developer_undo/<workspace-hash>.json. FileHistory::persist creates the directory with std::fs::create_dir_all and writes with std::fs::write, without explicitly protecting the directory or file. With an ordinary 022 umask these become 0755 directories and 0644 files on Unix.

If the containing home/config tree is traversable by another local account, that account can read the snapshots, including text a researcher edited and later removed from the working file. Protecting the session database directory in #445 does not protect this separate snapshot location. This finding concerns confidentiality of app-created undo snapshots; it does not assume root access, compromise of the owner account, or any real participant/patient data.

Controlled reproduction

Use only synthetic content in a temporary test profile:

1. Set BIOROUTER_PATH_ROOT to a temporary profile whose ancestors are traversable; retain the ordinary 022 umask.
2. Create a workspace text file containing SYNTHETIC_UNDO_CANARY.
3. Edit that file using Developer text_editor so its prior content is snapshotted.
4. Inspect permissions of <temporary-profile>/config/developer_undo and its JSON snapshot. The current writer supplies no explicit mode, so the expected ordinary result is 0755/0644.
5. In a controlled Linux two-UID fixture, try reading the synthetic JSON as a second unprivileged UID. Access should be denied after remediation.

No existing user snapshot content needs to be read to reproduce or verify the problem.

Recommended remediation, preserving convenience

• Keep automatic undo and the existing tool names/workflow. Make privacy a backend storage property, without routine new confirmation dialogs.
• Create/open the app-owned undo directory through a bound directory handle; require the current owner and protect it as 0700 on Unix. Refuse links and insecure/non-owned destinations.
• Atomically publish new snapshot files with owner-only access (0600) from the first creation, including temporary publication files. Preserve the private access controls on subsequent replacement.
• Secure existing history directory/files before reading or retaining them; do not copy history through a shared temporary folder. Existing legitimate history should remain usable.
• Account for inherited macOS ACLs and Windows protected owner-only DACLs; Unix mode bits alone do not establish ACL parity. Fail closed with an actionable message or private in-memory undo if the filesystem cannot provide the promised protection.
• Keep target-file snapshots/restores through the bounded executor in Anchor file operations to authorized directory handles #452, and retain the latest undo entry when a restore fails.

Acceptance evidence

• Synthetic tests for new storage, migration of pre-existing 0755/0644 history, owner mismatch/link refusal, and normal persistent undo across restart.
• Deterministic root/path-substitution checks for the history store, with no outside canary effects.
• A controlled Linux two-UID test: the owner retains undo; another UID cannot traverse/read snapshots.
• Platform-specific ACL checks for macOS and Windows, with unsupported cases stated explicitly.

Related: #445 (session-store privacy), #452 (directory-handle-backed file operations). This is a distinct storage location discovered while implementing the defensive audit follow-up.