go-delve/delve · error

Prompt for input failed.

Error message

Prompt for input failed.

What it means

Delve's terminal REPL loop calls promptForInput (a readline-style prompt) to read the next command. If that call fails with anything other than io.EOF, Run returns exit code 1 with 'Prompt for input failed.' This is a terminal I/O failure - stdin is not usable interactively - not a debugger command failure.

Source

Thrown at pkg/terminal/terminal.go:433

	// Ensure that the target process is neither running nor recording by
	// making a blocking call.
	_, _ = t.client.GetState()

	for {
		locs = nil

		prompt := defaultPrompt
		if t.conf != nil && t.conf.Prompt != "" {
			prompt = t.expandPrompt(t.conf.Prompt)
		}

		cmdstr, err := t.promptForInput(prompt)
		if err != nil {
			if err == io.EOF {
				fmt.Fprintln(t.stdout, "exit")
				return t.handleExit()
			}
			return 1, errors.New("Prompt for input failed.\n")
		}
		t.stdout.Echo(prompt + cmdstr + "\n")

		if strings.TrimSpace(cmdstr) == "" {
			cmdstr = lastCmd
		}

		lastCmd = cmdstr

		if err := t.cmds.Call(cmdstr, t); err != nil {
			if _, ok := err.(ExitRequestError); ok {
				return t.handleExit()
			}
			// The type information gets lost in serialization / de-serialization,
			// so we do a string compare on the error message to see if the process
			// has exited, or if the command actually failed.
			if strings.Contains(err.Error(), "exited") {
				fmt.Fprintln(os.Stderr, err.Error())

View on GitHub (pinned to a23773e6c3)

Solutions

1. Run dlv with an attached TTY: use `docker run -t`, `script -qec`, or run in a real terminal instead of a pipe
2. If commands come from a script, use dlv's init file (--init) or batch mode rather than piping into the interactive prompt
3. Check that stdin is open and readable in your environment (e.g. `dlv < /dev/tty`)
4. For non-interactive use, prefer `dlv exec ... --continue` or the DAP/RPC headless server instead of the terminal

Example fix

// before (CI script)
dlv debug ./app < /dev/null

// after
dlv debug ./app --init=./cmds.init --continue

// Go caller driving terminal programmatically
cmd, isatty := isTerminal(os.Stdin.Fd())
if !isatty {
    // run headless/RPC instead of interactive terminal
    _ = cmd
}
# shell: only start interactive dlv when a TTY exists
[ -t 0 ] && dlv debug ./app || dlv debug ./app --init=cmds.init --continue

// Go: check stdin usability before entering interactive mode
func stdinIsTTY() bool {
    fi, err := os.Stdin.Stat()
    return err == nil && (fi.Mode()&os.ModeCharDevice) != 0
}

// Wrap terminal Run and treat exit-code 1 + this message as a non-TTY environment problem
code, err := term.Run()
if code == 1 && err != nil && strings.Contains(err.Error(), "Prompt for input failed") {
    log.Println("stdin is not interactive; use --init, headless mode, or attach a TTY")
    os.Exit(code)
}

When it happens

Trigger: Running dlv in an environment with no usable TTY on stdin (stdin closed or redirected from /dev/null, CI pipelines without stdin, non-interactive backgrounds), a missing/failed terminal initialization, or a readline error other than EOF while the prompt loop is active (e.g. in tests like TestBreakpointSave that drive the terminal programmatically).

Common situations: CI jobs running `dlv` without a pty; docker exec without -t; scripts piping commands into dlv but keeping the interactive prompt configured; environments where the terminal library cannot allocate a reader (e.g. dumb terminals or closed file descriptors); automated tests that closed stdin before the loop ran.

Related errors

• %s is not a terminal
• command not available
• unknown config parameter
• not documented
• you must specify a thread

AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31). Data as JSON: /api/errors/ca7c0e13fca5f1a9. Report an issue: GitHub.