charmbracelet/gum · error

failed to write rune: %w

Error message

failed to write rune: %w

What it means

Returned by internal/stdin.Read when b.WriteRune(r) fails while accumulating runes from stdin in multi-line (default) mode. Like the line variant, strings.Builder only fails on memory exhaustion, so this wraps an out-of-memory condition. The error is wrapped with %w.

Source

Thrown at internal/stdin/stdin.go:68

	if options.singleLine {
		line, _, err := reader.ReadLine()
		if err != nil {
			return "", fmt.Errorf("failed to read line: %w", err)
		}
		_, err = b.Write(line)
		if err != nil {
			return "", fmt.Errorf("failed to write: %w", err)
		}
	}

	for !options.singleLine {
		r, _, err := reader.ReadRune()
		if err != nil && err == io.EOF {
			break
		}
		_, err = b.WriteRune(r)
		if err != nil {
			return "", fmt.Errorf("failed to write rune: %w", err)
		}
	}

	s := strings.TrimSpace(b.String())
	if options.ansiStrip {
		return ansi.Strip(s), nil
	}
	return s, nil
}

// IsEmpty returns whether stdin is empty.
func IsEmpty() bool {
	stat, err := os.Stdin.Stat()
	if err != nil {
		return true
	}

	if stat.Mode()&os.ModeNamedPipe == 0 && stat.Size() == 0 {

View on GitHub (pinned to 4d089f9550)

Solutions

1. Increase container/process memory limits
2. Bound the size of the input stream before piping (e.g. head -c)
3. Ensure the upstream producer terminates instead of streaming indefinitely
4. Process the stream incrementally in your own code instead of buffering all of stdin

Example fix

// before
cat huge.log | gum pager
// after
head -c 10000000 huge.log | gum pager  # bound the input size

info, _ := os.Stdin.Stat()
if info.Size() > maxInputBytes { return fmt.Errorf("stdin input exceeds %d bytes", maxInputBytes) }

func inputWithinLimit(r io.Reader, max int64) bool {
    n, _ := io.Copy(io.Discard, io.LimitReader(r, max+1))
    return n <= max
}

out, err := stdin.Read()
if err != nil {
    return fmt.Errorf("stdin buffer failed (OOM?): %w", err)
}

When it happens

Trigger: Calling Read in default (non-singleLine) mode where WriteRune returns an error — practically only when the runtime cannot allocate memory for the growing buffer.

Common situations: Piping an enormous stream into the tool in a memory-limited container; runaway upstream producer flooding stdin; low-memory hosts.

Related errors

• failed to write: %w
• no input provided, see `gum style --help`
• stdin is empty
• failed to read line: %w
• unable to read stdin

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