jdx/mise · error

[dotfiles]."{}/{}": block content may not contain its own ma

Error message

[dotfiles]."{}/{}": block content may not contain its own marker lines

What it means

Block edits delimit their managed content with marker lines (">>> mise:<id> >>>" and "<<< mise:<id> <<<", optionally commented). If the block content itself contains a line matching its own markers, the written file could not be parsed back on reapply. desired_content refuses up front during check/apply/diff instead of corrupting the file.

Source

Thrown at src/system/edits.rs:490

            &raw,
            config.bootstrap_tera_ctx(&req.origin.config),
        )
        .map_err(|err| {
            eyre::eyre!(
                "[dotfiles].\"{}/{}\": failed to render template: {err}",
                req.path_raw,
                req.id
            )
        })?
    } else {
        raw
    };
    let content = content.trim_end_matches('\n').to_string();
    // a block containing its own marker lines would write a file that can't
    // be parsed back — refuse up front instead of corrupting on reapply
    for pat in [format!(">>> mise:{id} >>>"), format!("<<< mise:{id} <<<")] {
        if content.lines().any(|l| is_marker_line(l, &pat, comment)) {
            bail!(
                "[dotfiles].\"{}/{}\": block content may not contain its own marker lines",
                req.path_raw,
                req.id
            );
        }
    }
    Ok(Some(content))
}

/// Current state of one edit on this machine.
///
/// Note: comparing a template block against existing markers requires
/// rendering it, so this can run the template engine — including `exec()` —
/// from `mise bootstrap dotfiles status`. That's the same trust model as `[env]`
/// templates. Rendering only happens once every render-free outcome (symlink
/// target, missing file, absent or corrupted markers) has been ruled out,
/// and `--dry-run` skips template rendering entirely (see [`apply`]).
pub(crate) fn check(config: &Config, req: &EditRequest) -> Result<FileState> {

View on GitHub (pinned to afd2eddd3a)

Solutions

  1. Remove the marker lines from the block content.
  2. Change the entry's id so the marker pattern no longer matches the content.
  3. If the target file legitimately contains similar text, manage it with a `line` entry or a different comment/id combination.

Example fix

// before (content contains its own marker)
[[dotfiles]]
id = "snippet"
path = "~/.zshrc"
block = """>>> mise:snippet >>>
alias gs='git status'"""

// after
[[dotfiles]]
id = "snippet"
path = "~/.zshrc"
block = "alias gs='git status'"
Defensive patterns

Strategy: validation

Validate before calling

for l in block_content.lines() {
    assert!(!l.contains(&format!(">>> mise:{id} >>>")) && !l.contains(&format!("<<< mise:{id} <<<")),
        "entry {id}: block content may not contain its own marker lines");
}

Prevention

When it happens

Trigger: The rendered block content of a [dotfiles] entry includes a line that matches the marker pattern for that entry's id — e.g. the content literally contains ">>> mise:myid >>>" or "<<< mise:myid <<<", possibly produced via templating.

Common situations: Managing a config file that itself contains mise edit markers for the same id (nesting attempt); templated content that emits marker-like lines; id collisions after renaming.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors


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