hashicorp/terraform · warning

Error asking for confirmation: %s

Error message

Error asking for confirmation: %s

What it means

Emitted by the internal confirm() helper when UIInput().Input() returns an error while prompting the user for a yes/no confirmation. Terraform retries the prompt up to two times, and this error surfaces only when the input reader itself fails (not when the user types something unrecognized). It wraps the I/O error verbatim.

Source

Thrown at internal/command/meta.go:666

	return args
}

// uiHook returns the UiHook to use with the context.
func (m *Meta) uiHook() *views.UiHook {
	return views.NewUiHook(m.View)
}

// confirm asks a yes/no confirmation.
func (m *Meta) confirm(opts *terraform.InputOpts) (bool, error) {
	if !m.Input() {
		return false, errors.New("input is disabled")
	}

	for i := 0; i < 2; i++ {
		v, err := m.UIInput().Input(context.Background(), opts)
		if err != nil {
			return false, fmt.Errorf(
				"Error asking for confirmation: %s", err)
		}

		switch strings.ToLower(v) {
		case "no":
			return false, nil
		case "yes":
			return true, nil
		}
	}
	return false, nil
}

// showDiagnostics displays error and warning messages in the UI.
//
// "Diagnostics" here means the Diagnostics type from the tfdiag package,
// though as a convenience this function accepts anything that could be
// passed to the "Append" method on that type, converting it to Diagnostics

View on GitHub (pinned to c9def3e214)

Solutions

1. Add -auto-approve (apply) or the appropriate non-interactive flag so no confirmation prompt is issued.
2. Ensure stdin remains open and connected when interactive prompts are expected, or feed the answer via a pipe/heredoc.
3. Set -input=false in CI to get deterministic behavior instead of a broken-pipe error.

Example fix

// before: CI with closed stdin
terraform apply
// after
terraform apply -auto-approve
# or
terraform apply -input=false

// Ensure interactivity is consistent before relying on confirm()
if m.Input() && !isTerminal(os.Stdin) {
    // stdin not a TTY but input enabled → likely broken-pipe risk
    return errors.New("input enabled but stdin is not a TTY; use -input=false or -auto-approve")
}

When it happens

Trigger: The confirm() method is called (e.g. before a destructive apply or state replacement) and the underlying UIInput reader — typically stdin or a non-interactive adapter — returns an error such as EOF, broken pipe, or a closed TTY.

Common situations: Running Terraform non-interactively in CI without -auto-approve, so stdin is closed and the prompt reader hits EOF; piping input that closes prematurely; a terminal emulator crash; input disabled via -input=false but confirm() still invoked (note: -input=false returns a separate 'input is disabled' error).

Related errors

• error asking for approval: %w
• Error asking %s: %v
• Error asking %s: %v
• Failed to select workspace: %s
• Error asking for input to configure backend %q: %s

AI-assisted analysis of hashicorp/terraform@c9def3e214 (2026-08-07). Data as JSON: /api/errors/c26af555aefbb4af. Report an issue: GitHub.