errInteractiveInputDisabled

errInteractiveInputDisabled

Error message

Can't ask approval for state migration when interactive input is disabled.

Please remove the "-input=false" option and try again.

What it means

`backendMigrateState` returns this (constant `errInteractiveInputDisabled`) when a state migration needs user approval (single-state to/from single-state where both sides already have state, or any case requiring `confirmFunc`) but `m.input` is false and `-force` was not supplied. The message instructs the user to remove `-input=false`.

Source

Thrown at internal/command/meta_backend_migrate.go:450

			confirmFunc = m.backendMigrateEmptyConfirm
		}

	// Both states are non-empty, meaning we need to determine which
	// state should be used and update accordingly.
	case !source.Empty() && !destination.Empty():
		log.Print("[TRACE] backendMigrateState: both source and destination workspaces have states, so might overwrite destination with source")
		confirmFunc = m.backendMigrateNonEmptyConfirm
	}

	if confirmFunc == nil {
		panic("confirmFunc must not be nil")
	}

	if !opts.force {
		// Abort if we can't ask for input.
		if !m.input {
			log.Print("[TRACE] backendMigrateState: can't prompt for input, so aborting migration")
			return errors.New(strings.TrimSpace(errInteractiveInputDisabled))
		}

		// Confirm with the user whether we want to copy state over
		confirm, err := confirmFunc(sourceState, destinationState, opts)
		if err != nil {
			log.Print("[TRACE] backendMigrateState: error reading input, so aborting migration")
			return err
		}
		if !confirm {
			log.Print("[TRACE] backendMigrateState: user cancelled at confirmation prompt, so aborting migration")
			return nil
		}
	}

	// Confirmed! We'll have the statemgr package handle the migration, which
	// includes preserving any lineage/serial information where possible, if
	// both managers support such metadata.
	log.Print("[TRACE] backendMigrateState: migration confirmed, so migrating")

View on GitHub (pinned to d32a084675)

Solutions

Drop `-input=false` (or run in a TTY) so the migration prompt can be answered.
Pass `-force` (with `-migrate-state`) to skip the confirmation when you are sure the destination should be overwritten.
If you did not intend to migrate, align the backend config so init does not detect a migration is needed.

Example fix

# before
terraform init -input=false   # backend changed, both sides have state -> error
# after
terraform init -migrate-state -force   # or remove -input=false

Defensive patterns

Strategy: validation

Validate before calling

// Mirror the guard before triggering a migration:
if !m.input && !opts.force {
    return errors.New(strings.TrimSpace(errInteractiveInputDisabled))
}

Prevention

Use `terraform init -migrate-state -force` for non-interactive migrations.
Avoid changing backend config in the same CI step that runs `-input=false` init.
Keep state migrations deliberate and reviewed, not automated surprises.

When it happens

Trigger: Switching backends (e.g. local -> remote/cloud or remote -> cloud) where both source and destination already contain state, `opts.force` is false, and `m.input` is false.

Common situations: Re-running `terraform init` with `-input=false` after changing the `backend`/`cloud` block in a CI pipeline; migrating state in automation without `-migrate-state` plus a way to auto-confirm.

Related errors

AI-assisted analysis of hashicorp/terraform@d32a084675 (2026-08-11). Data as JSON: /api/errors/97696c9dfd8986af. Report an issue: GitHub.