[Bug]: forge -p emits TUI spinner frames to stderr in non-TTY runs

[ictechgy]

Bug Description

In prompt mode, forge -p can emit interactive TUI progress/spinner frames to stderr even when stderr is redirected and not a TTY. That output is useful in an interactive terminal, but in headless subprocess use it turns stderr into a stream of animation frames rather than a diagnostics channel.

Sanitized examples observed in redirected stderr logs:

⠋ Migrating credentials 00s · Ctrl+C to interrupt
⠋ Contemplating 00s · Ctrl+C to interrupt
⠙ Contemplating 00s · Ctrl+C to interrupt
⠹ Contemplating 00s · Ctrl+C to interrupt
...

Steps to Reproduce

1. Run a prompt-mode invocation with streams redirected:

   forge -p "Review this change for correctness" >out 2>err

2. Inspect err for progress/spinner frames.

Expected Behavior

For non-TTY stderr, Forge should either:

• suppress spinner/control animation frames automatically, or
• provide a documented non-interactive flag such as --quiet / --no-progress.

Actual errors and diagnostics should still be able to use stderr. The issue is repeated terminal animation/progress frames in headless logs.

Actual Behavior

stderr can contain repeated TUI progress frames. In automation this produces noisy logs, makes real diagnostics harder to locate, and requires wrappers to strip ANSI/control/progress output before storing or displaying stderr.

Forge Version

2.13.15

Operating System & Version

macOS / Darwin arm64

AI Provider

OpenAI-compatible

Model

N/A

Installation Method

curl -fsSL https://forgecode.dev/cli | sh

Configuration

# no sensitive configuration included

Related

Related to #3459, but this issue is specifically about stderr behavior. #3459 focuses on making forge -p stdout pipeable/final-answer-only.