Observation from parity testing (both the Go client and the C reimplementation in misc/brintos-fs2 behave identically — this is a design-level caveat, not a client bug):

$ time cp -r tree-of-300-small-files /mnt/x/dst   # Go client: 3m29s, C client: 3m25s
$ time rm -rf /mnt/x/dst                          # 0.1–0.2s (correctly local)

GNU coreutils cp opens destination files with O_WRONLY|O_CREAT|O_EXCL whenever it created the destination directory itself (verified with strace). Each O_EXCL create takes the CreateExclusive path — a FlushAll journal barrier plus a synchronous POST /fs/upload — so a fresh-tree cp -r/cp -a serializes one server round trip per file (~0.7 s each against production), while tar -x, rsync into an existing dir, and shell > redirects stay fully local as designed.

The README's "bulk copies finish locally; durability follows" holds for the non-O_EXCL paths but not for the most common bulk-copy command.

Possible improvement to discuss: when the destination's parent directory is itself a locally-created, un-flushed pending directory, no other mount can observe it yet, so O_EXCL exclusivity could be arbitrated locally (kernel dcache + mirror) without weakening the git-lock use case (refs/heads/X.lock lives in long-existing directories, which would keep the server-arbitrated path). Deliberately NOT changed in the C client pending a decision, since O_EXCL semantics are a cross-mount correctness contract.