What causes "failed to add {}" in jdx/mise?

Run `mise bootstrap dotfiles add ` explicitly and inspect its output to see why the entry is not registered.

failed to add {}

Error message

failed to add {}

What it means

`mise bootstrap dotfiles edit <TARGET>` opens the managed source for a dotfile. If the target is not yet managed, the command first runs an implicit `dotfiles add` for it, reloads the config, and re-resolves the target's source. When even after that successful-looking add the source still cannot be resolved, mise throws "failed to add <target>" because the internal invariant 'after add, the target must be resolvable' was violated.

Source

Thrown at src/cli/dotfiles/edit.rs:97

        DotfilesAdd {
            targets: vec![self.target.clone()],
            changed: false,
            mode: self.mode.clone(),
            source: self.source.clone(),
            global: true,
            local: false,
            path: None,
            dry_run: false,
            no_apply: true,
            force: false,
            yes: true,
        }
        .run()
        .await?;

        config = Config::reset().await?;
        let Some(path) = source_for_target(&config, &target, &self.target)? else {
            bail!("failed to add {}", self.target);
        };
        open_or_create(&path)?;
        crate::cli::editor::open_in_editor(&path)?;
        if self.apply {
            apply_target(&self.target).await?;
        }
        Ok(())
    }
}

fn source_for_target(
    config: &Config,
    target: &std::path::Path,
    raw: &str,
) -> Result<Option<PathBuf>> {
    for req in system::files::files_from_config(config)? {
        if system::files::matches_target(&req.target, &req.target_raw, &[raw.to_string()]) {
            return Ok(Some(req.source));

View on GitHub (pinned to afd2eddd3a)

Solutions

Run `mise bootstrap dotfiles add <target>` explicitly and inspect its output to see why the entry is not registered.
Check the global config ([dotfiles] section) for an entry for the target after the failed run; if missing, add it manually.
Re-run the edit with `--yes` and an explicit `--source`/`--mode` so the implicit add has full information.
Report the case as a bug if add succeeds but the target still does not resolve — this is an internal invariant violation.

Example fix

// before (shell)
mise bootstrap dotfiles edit ~/.zshrc   # failed to add ~/.zshrc
// after
mise bootstrap dotfiles add ~/.zshrc --yes
mise bootstrap dotfiles edit ~/.zshrc

Defensive patterns

Strategy: validation

Validate before calling

# resolve the managed source before opening an editor
if ! mise bootstrap dotfiles paths | grep -qx "$target"; then
  mise bootstrap dotfiles add "$target" --yes || exit 1
fi

Prevention

Explicitly run `dotfiles add` instead of relying on the implicit add inside `edit`.
Verify with `dotfiles paths` that the target is managed before editing.

When it happens

Trigger: Running `mise bootstrap dotfiles edit <target>` where the target is unmanaged, the implicit `DotfilesAdd` run reports success but `source_for_target` still returns None afterwards (e.g. the add wrote to a config file that does not actually register the target, or the target string resolves to a different path on re-resolution).

Common situations: Adding a dotfile whose config entry lands in a file that is later overridden by another config layer; typos or symlinks that make the resolved target differ between the add and the re-lookup; concurrent modification of the global config during the edit command.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors

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