{"version":"2.1.277","anchor":"worktree-sync-protocol-downapplied-history-now-branches-on","canonical_anchor":"worktree-sync-protocol-downapplied-history-now-branches-on","heading":"Worktree sync protocol: downApplied history now branches on ack state, adds readsStanding capability","tier":"internal","area":"Git Internals","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277\/e\/worktree-sync-protocol-downapplied-history-now-branches-on","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277","markdown":"### Worktree sync protocol: downApplied history now branches on ack state, adds readsStanding capability\n\nWorktree sync responses now branch on whether the client acknowledged the current commit, and add a readsStanding flag\n\n**Unclear.** The finding does not say what capability `readsStanding` signals to the client or what behavior it unlocks.\n\n**What**\n\nWhen Claude Code syncs a git worktree (a checked-out copy of a repository) between a client and its session, the response now builds its history of applied changes (`downApplied`) differently depending on whether the client has already acknowledged the current worktree commit. If it has, the history folds in downstream applied changes on top of what was already sent; if not, it falls back to just the reversed sent history. The response also now always includes a new `readsStanding` flag set to true, alongside the existing `acceptsHeldParents` flag.\n\n**Why**\n\nThis makes worktree sync responses more accurate for clients that haven't yet caught up to the latest commit, avoiding history that assumes acknowledgment that hasn't actually happened.\n\n- Area: Git Internals\n- Names: `readsStanding`\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}