What causes "{} changed during setup adoption; retry pull" in jdx/mise?

Re-run `mise bootstrap dotfiles pull` — the retry recomputes the plan from the current tree and re-adopts cleanly.

{} changed during setup adoption; retry pull

Error message

{} changed during setup adoption; retry pull

What it means

After writing the whole application batch but before advancing Git (adopting the setup), mise re-reads every written file and compares it against the pending object and desired permissions. If any file drifted during the write phase, Git is not advanced and the error names the changed path, asking for a pull retry — a concurrent edit must never be recorded as an applied setup.

Source

Thrown at src/system/history/sync/apply.rs:548

                    replay::write_path_with_mode(repo, &step.path, mode, oid, step.desired_mode)?
                }
                None => replay::remove(&step.path)?,
            }
            journal::commit_changes(pending);
            let mut next = step.pending.next.clone();
            let oid = step.pending.object.clone();
            next.applied = oid.clone();
            next.acknowledged = oid;
            sync_state.insert(step.pending.branch_path.clone(), next);
        }
        if fresh_adoption || inventory_tree.is_some() {
            // Verify the whole written batch again before advancing Git. A
            // concurrent edit must not become an apparently applied setup.
            for step in &ready {
                if live_object(repo, &step.path)? != step.pending.object
                    || live_permissions(&step.path)? != step.desired_mode
                {
                    bail!(
                        "{} changed during setup adoption; retry pull",
                        display_path(&step.path)
                    );
                }
            }
            for directory in &directories {
                directory.verify_written()?;
            }
            let heads = super::graph::Heads::read(repo)?;
            if heads.local != application_head || heads.remote != status.upstream_commit {
                bail!("setup history changed during adoption; retry pull");
            }
            let remote = heads.remote.as_deref().unwrap();
            super::files::audit_history(repo, remote, &Default::default())?;
            let tree = inventory_tree
                .clone()
                .unwrap_or(repo.output_tree_of(remote)?);
            let candidate = heads

View on GitHub (pinned to afd2eddd3a)

Solutions

Re-run `mise bootstrap dotfiles pull` — the retry recomputes the plan from the current tree and re-adopts cleanly.
Identify and stop the concurrent writer (editors, watchers, second sync processes) before retrying.
If the drift is only permissions, set the expected mode (chmod) or let the retry plan recompute the desired mode, then pull again.

Example fix

# before: drift between write and git advance
mise bootstrap dotfiles pull   # -> "changed during setup adoption; retry pull"
# after
mise bootstrap dotfiles pull   # retry recomputes and adopts

Defensive patterns

Strategy: retry

Validate before calling

# stop background watchers that rewrite dotfiles before pulling
mise bootstrap dotfiles pull --dry-run   # confirm plan, then apply without interference

Try / catch

try {
  await pull();
} catch (e) {
  if (/changed during setup adoption/.test(e.message)) {
    await pauseWatchers();
    return await pull(); // retry recomputes and adopts cleanly
  }
  throw e;
}

Prevention

Pause file watchers/daemons that touch tracked dotfiles during a pull.
Avoid running two sync operations concurrently; the sync lock covers mise only.
After a failed adoption, always retry with a fresh pull instead of manually editing state.

When it happens

Trigger: Post-write verification: `live_object(repo, step.path) != step.pending.object || live_permissions(&step.path) != step.desired_mode` for any step — the file was modified (or its mode changed) after being written but before the history ref advanced.

Common situations: A watcher or editor rewrote a file immediately after mise wrote it; another sync process overwrote the file during the batch; permissions altered by an external chmod or umask-sensitive tool between write and verification.

Understand the failure class

Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/2ef80807aee756b1. Report an issue: GitHub.