jdx/mise · error

edits: cannot unapply these entries: {}

Error message

edits: cannot unapply these entries:
{}

What it means

plan_unapply builds the list of operations needed to remove managed edits from files. Requests that cannot be unapplied (e.g. target is a symlink, per SYMLINK_REASON) are collected into `problems`; if any exist, mise aborts before touching anything and tells the user to fix those entries manually.

Source

Thrown at src/system/edits.rs:944

            },
            EditOp::Line { line, .. } if lines.contains(&line.as_str()) => {
                if !opts.force {
                    problems.push(format!(
                        "  \"{}\" ({}): line edits have no ownership marker; use --force to remove the line",
                        req.path_raw,
                        req.describe_op()
                    ));
                } else if seen_lines.insert((req.path.clone(), line.clone())) {
                    // Two ids with the same line converge to one applied line
                    // and therefore produce one unapply action.
                    todo.push(UnapplyPlan { req, text });
                }
            }
            EditOp::Line { .. } => {}
        }
    }
    if !problems.is_empty() {
        bail!(
            "edits: cannot unapply these entries:\n{}",
            problems.join("\n")
        );
    }
    Ok(todo)
}

/// Ensure template functions or another concurrent actor did not invalidate
/// any edit ownership checks performed during planning.
pub(crate) fn validate_unapply(todo: &[UnapplyPlan<'_>]) -> Result<()> {
    let mut checked = indexmap::IndexSet::new();
    let mut problems = vec![];
    for plan in todo {
        if !checked.insert(plan.req.path.clone()) {
            continue;
        }
        let result = if plan.req.path.is_symlink() {
            Err(eyre::eyre!("{SYMLINK_REASON}"))

View on GitHub (pinned to afd2eddd3a)

Solutions

1. Inspect the listed entries; the usual cause is a target that is now a symlink.
2. Manually remove the managed block/lines from the symlink's real target file.
3. Or restore the target to a regular file so mise can unapply it.
4. Re-run the unapply command; planning will succeed once no problems remain.

Example fix

// before: ~/.zshrc is a symlink; `mise edits unapply` refuses
// fix manually:
sed -i '/# mise:begin <id>/,/# mise:end <id>/d' ~/dotfiles/zshrc

// after: entry removed from config and block deleted by hand

# ensure no unapply target is a symlink
for f in $(mise edits list-targets); do
  [ -L "$f" ] && echo "cannot unapply symlink: $f"
done

When it happens

Trigger: Running an unapply flow (`mise edits unapply` / removing a managed edit) where plan_unapply encounters a request whose precheck fails — classically a target that is a symlink — so no safe unapply plan can be produced for it.

Common situations: The user removes an [edits] entry from mise.toml expecting mise to clean the file, but the target became a symlink since the edit was applied (another dotfile manager took over), so unapply refuses.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• edits: cannot diff these entries, fix them manually: {}
• target changed after unapply planning
• edits: "{}": {reason}, fix the file manually
• [dotfiles]."{}": mode symlink-each requires a directory sour
• files: cannot unapply these entries:\n{}

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