{} changed while the changes were being applied; nothing mor

Error message

{} changed while the changes were being applied; nothing more was written. Run `mise bootstrap dotfiles pull` again

What it means

During application, mise re-verifies each file against the planned `before` snapshot right before writing it. If the file changed while earlier steps of the same batch were being written, apply stops mid-batch with this error: the current file and everything after it are left untouched, and the user is told to run `mise bootstrap dotfiles pull` again. This protects an in-flight edit from being overwritten (an undo would otherwise restore the planned version instead of the user's edit).

Source

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

                || live_permissions(&step.path)? != step.before_mode
            {
                bail!(
                    "{} changed before application; nothing was written",
                    display_path(&step.path)
                );
            }
        }
        for directory in &mut directories {
            directory.apply()?;
        }
        for step in &ready {
            // the file may have changed since the plan was made: an edit
            // that landed meanwhile is never overwritten (undo would bring
            // back the planned version, not it)
            if live_object(repo, &step.path)? != step.before
                || live_permissions(&step.path)? != step.before_mode
            {
                bail!(
                    "{} changed while the changes were being applied; nothing more was written. Run `mise bootstrap dotfiles pull` again",
                    display_path(&step.path)
                );
            }
            let pending =
                journal::begin_changes("history", &display_path(&step.path), [step.path.clone()])?;
            touched.push(step.path.clone());
            let affected = display_path(&step.path);
            scope.with_operation(|op| op.affected.push(affected.clone()));
            match &step.pending.object {
                Some((mode, oid)) => {
                    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();

View on GitHub (pinned to afd2eddd3a)

Solutions

Run `mise bootstrap dotfiles pull` again as the message instructs — the new plan incorporates the concurrent change and unapplied steps.
Ensure only one sync process runs at a time (the sync lock serializes, but external editors/tools still race).
Pause editor autosave/watchers or close editors that touch tracked dotfiles while pulling; on network homes, consider pulling when the filesystem is responsive.

Example fix

# before: file changed mid-apply
mise bootstrap dotfiles pull   # partial failure, message says rerun
# after
mise bootstrap dotfiles pull   # retry with a fresh plan

Defensive patterns

Strategy: retry

Validate before calling

# check for active writers on tracked files before a multi-file pull
lsof +D ~/.config 2>/dev/null | head

Try / catch

try {
  await pull();
} catch (e) {
  if (/changed while the changes were being applied/.test(e.message)) {
    return await pull(); // message explicitly says to run pull again
  }
  throw e;
}

Prevention

Quiesce editors, watchers, and other sync tools while pulling multiple files.
Keep the apply window short: fast local filesystems reduce the race window.
Retry pulls after mid-batch failures — unapplied steps are preserved and a fresh plan will include the concurrent change.

When it happens

Trigger: Inside the per-step write loop, `live_object(repo, step.path) != step.before || live_permissions(&step.path) != step.before_mode` — the file changed between planning/last check and this step's write, e.g. while previous steps were being applied.

Common situations: Editor autosave or a watcher rewriting a dotfile while a multi-file pull is in progress; two simultaneous `mise bootstrap dotfiles` invocations racing on the same files; slow filesystem (network home) extending the apply window.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

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