{"version":"2.1.248","anchor":"commands-sent-to-a-remote-machine-now-wait-for-a-file-sync-b","canonical_anchor":"commands-sent-to-a-remote-machine-now-wait-for-a-file-sync-b","heading":"Commands sent to a remote machine now wait for a file-sync barrier first","tier":"notice","area":"File Sync","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/commands-sent-to-a-remote-machine-now-wait-for-a-file-sync-b","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Commands sent to a remote machine now wait for a file-sync barrier first\n\nCommands sent to a remote machine wait for your file changes to land, or fail with sync_failed.\n\n**What**\n\nBefore forwarding a tool call to a remote or bridged host, Claude Code pushes your local file changes and asks the peer to take them in. The barrier answers go, go with a note, or hold. On hold the call is never made and comes back as an error with code `sync_failed` plus an explanation of what would clear it.\n\n**Details**\n\n- Not behind a feature flag, but it short-circuits to go when the peer's Claude Code does not advertise the `sync_files` plumbing tool or the transport has no plumbing channel, so only sessions using directory sync with a new enough peer see holds.\n\n**Evidence**\n\n`Not run on ${r}: ${e}, so the command would have acted on stale files. ${r} was not contacted. What clears it: ${t}.`\n\n- Area: File Sync\n- Tier: You'll notice\n- Useful: 4\/5\n- Signal: 4\/5"}