this is a potentially destructive operation; pass --confirm

Error message

this is a potentially destructive operation; pass --confirm to proceed

What it means

The `ipfs files chroot` command replaces the MFS root, which discards the current root's contents from the operator's default view, so it refuses to run unless the caller explicitly passes --confirm. The check is a plain boolean read of the confirm option in the command's Run function.

Source

Thrown at core/commands/files.go:1732

  # Reset MFS to empty directory (recovery from corruption)
  $ ipfs files chroot --confirm

  # Restore MFS to a known good directory CID
  $ ipfs files chroot --confirm QmYourBackupCID
`,
	},
	Arguments: []cmds.Argument{
		cmds.StringArg("cid", false, false, "New root CID (defaults to empty directory if not specified)."),
	},
	Options: []cmds.Option{
		cmds.BoolOption(chrootConfirmOptionName, "Confirm this potentially destructive operation."),
	},
	NoRemote: true,
	Extra:    CreateCmdExtras(SetDoesNotUseRepo(true)),
	Run: func(req *cmds.Request, res cmds.ResponseEmitter, env cmds.Environment) error {
		confirm, _ := req.Options[chrootConfirmOptionName].(bool)
		if !confirm {
			return errors.New("this is a potentially destructive operation; pass --confirm to proceed")
		}

		enc, err := cmdenv.GetCidEncoder(req)
		if err != nil {
			return err
		}

		// Determine new root CID
		var newRootCid cid.Cid
		if len(req.Arguments) > 0 {
			var err error
			newRootCid, err = cmdutils.CidFromArg(req.Arguments[0])
			if err != nil {
				return fmt.Errorf("invalid CID %q: %w", req.Arguments[0], err)
			}
		} else {
			// Default to empty directory
			newRootCid = ft.EmptyDirNode().Cid()

View on GitHub (pinned to 329838acdf)

Solutions

Re-run with `--confirm` once you understand the current root will be replaced: `ipfs files chroot --confirm <cid>`.
Record the current root first (`ipfs files stat /`) so you can chroot back later.
In scripts/API clients, set the confirm boolean option to true explicitly.

Example fix

// before
ipfs files chroot bafybei...   # refused
// after
ipfs files chroot --confirm bafybei...

Defensive patterns

Strategy: validation

Validate before calling

ipfs files chroot --confirm "$CID"  # include --confirm; or check: ipfs files stat / | head -1

Try / catch

err := runChroot(args, confirm)
if err != nil && strings.Contains(err.Error(), "--confirm to proceed") {
    return fmt.Errorf("chroot aborted: pass --confirm to replace the MFS root")
}

Prevention

Always pass --confirm in scripts that intend the replacement
Save the current root CID (`files stat /`) before chrooting so it can be restored
Run chroot interactively only; gate it in CI behind explicit approval

When it happens

Trigger: Running `ipfs files chroot <cid>` (or with no arguments, resetting to the empty dir) without `--confirm`; invoking the command from a script or API call that omits the chrootConfirmOptionName option.

Common situations: Copy-pasting an example that omitted --confirm; automation written before the guard was added; users unaware chroot is destructive by design (NoRemote, operates directly on the local repo).

Related errors

AI-assisted analysis of ipfs/kubo@329838acdf (2026-09-03). Data as JSON: /api/errors/6a952ddbac923fd5. Report an issue: GitHub.