Summary

When running forge provider login openai_responses_compatible inside tmux, fast typing/paste in the OPENAI_URL prompt causes deterministic text corruption (suffix-cascade duplication).

Outside tmux, the same input behaves normally.

Environment

• Forge: 1.32.1
• tmux: 3.6a
• OS: macOS (darwin)
• Shells tested in tmux: zsh, bash

Minimal Reproduction

1. Start a clean tmux server (no user config):

   tmux -L repro -f /dev/null new-session

2. Run:

   forge provider login openai_responses_compatible

3. At ? Enter OPENAI_URL:, paste or quickly inject abcd.

Expected

Input remains exactly abcd.

Actual

Input is corrupted as:

? Enter OPENAI_URL: abcdbcdcdd

For long strings/URLs, it becomes a visible suffix-cascade (original + shifted suffixes), e.g. http://... followed by ttp://..., tp://..., etc.

Additional Evidence

• Reproduces with clean tmux (-f /dev/null), so this is not user tmux config specific.
• Toggling tmux options did not resolve: allow-passthrough, xterm-keys, assume-paste-time.
• Changing TERM/TERM_PROGRAM did not resolve.
• Slow per-character typing works; rapid input/paste triggers corruption.

Suspected Area

Potential redraw/cursor accounting issue in Forge interactive prompt rendering under tmux burst input.

Relevant code path:

• crates/forge_select/src/select.rs
• Theme sets prompt_suffix to an ANSI cursor move (cursor::MoveLeft(1)), which may cause non-idempotent redraw behavior in this path.

Why this seems Forge-side (not tmux config)

• Reproduces in clean tmux server with default config.
• Corruption pattern is structured (suffix-cascade), consistent with prompt redraw logic rather than random terminal noise.

If helpful, I can provide a short screen recording and exact command transcript.