What causes "unable to confirm: %w" in charmbracelet/gum?

Run inside a real terminal or wrap with a pty allocator (`script -qec 'gum confirm ...' /dev/null`).

unable to confirm: %w

Error message

unable to confirm: %w

What it means

gum confirm runs its yes/no prompt as a Bubble Tea program on stderr with the caller's context. If the program's Run returns an error AND the context's error is not `context.DeadlineExceeded`, Run wraps it as `unable to confirm: %w`. Deadline expiry is deliberately treated as a "no" answer rather than an error, so any error surfacing here is an unexpected TUI/TTY failure.

Source

Thrown at confirm/command.go:54

		showOutput:       o.ShowOutput,
		confirmation:     o.Default,
		defaultSelection: o.Default,
		keys:             defaultKeymap(o.Affirmative, o.Negative),
		help:             help.New(),
		showHelp:         o.ShowHelp,
		prompt:           o.Prompt,
		selectedStyle:    o.SelectedStyle.ToLipgloss(),
		unselectedStyle:  o.UnselectedStyle.ToLipgloss(),
		promptStyle:      o.PromptStyle.ToLipgloss(),
		padding:          []int{top, right, bottom, left},
	}
	tm, err := tea.NewProgram(
		m,
		tea.WithOutput(os.Stderr),
		tea.WithContext(ctx),
	).Run()
	if err != nil && ctx.Err() != context.DeadlineExceeded {
		return fmt.Errorf("unable to confirm: %w", err)
	}
	m = tm.(model)

	if o.ShowOutput {
		confirmationText := m.negative
		if m.confirmation {
			confirmationText = m.affirmative
		}
		fmt.Println(m.prompt, confirmationText)
	}

	if m.confirmation {
		return nil
	}

	return exit.ErrExit(1)
}

View on GitHub (pinned to 4d089f9550)

Solutions

Run inside a real terminal or wrap with a pty allocator (`script -qec 'gum confirm ...' /dev/null`).
Inspect the wrapped error to identify renderer vs. I/O cause; check TERM is set to a supported value.
Prefer `--timeout`/context deadlines for automation — those are handled gracefully as a negative answer.
Use `--default` behavior awareness: rely on timeout-as-no in scripts instead of failing hard.

Example fix

// before
gum confirm "Deploy?" > deploy.log 2>&1 // stderr not a TTY -> error
// after
gum confirm "Deploy?" // run interactively, or: script -qec 'gum confirm "Deploy?"' /dev/null

Defensive patterns

Strategy: validation

Validate before calling

[ -t 2 ] || { echo "gum confirm needs a TTY on stderr" >&2; exit 1; }

Try / catch

if ! gum confirm "Deploy?"; then
  rc=$?
  echo "not confirmed (rc=$rc)" >&2
fi

Prevention

Keep stderr attached to the terminal — gum confirm renders on stderr.
In CI, use --timeout or --default instead of relying on interaction.
Wrap with a pty allocator when output must be captured.
Verify TERM in minimal environments (docker exec, ssh without -t).

When it happens

Trigger: Terminal initialization fails (no TTY, bad termios/raw-mode setup), an input/output write fails mid-prompt, or the Bubble Tea program errors for reasons other than the confirmation deadline expiring.

Common situations: Running `gum confirm` where stderr is redirected to a file or pipe; headless CI without a pty; unusual terminal types that break the renderer.

Related errors

AI-assisted analysis of charmbracelet/gum@4d089f9550 (2026-08-31). Data as JSON: /api/errors/1a539c1bf45cf113. Report an issue: GitHub.