TUI does not reflow on window resize when launched via a stdio-proxying wrapper (e.g. 1Password CLI's op run)

Summary

When opencode is launched through a wrapper that proxies the child's stdio — most commonly 1Password CLI's op run, which always pipes stdout/stderr (even with --no-masking) — the TUI silently stops resizing on terminal window resize. Manual kill -WINCH <pid> does nothing either. The TUI renders correctly at startup (correct initial size), but never reflows afterwards. Other TUI apps launched the same way (htop, vim) resize fine in the same terminal.

Reproduction

op run --env-file ~/.config/opencode/qwen.env -- ~/.opencode/bin/opencode

Inside the running opencode TUI, drag a window edge. The TUI does not reflow.

Verify the cause:

# fd 1 and 2 are PIPE, not the TTY
lsof -a -d 1,2 -p $(pgrep -f '\.opencode/bin/opencode' | head -1)

# the host's PTY IS updated correctly on resize — only the app fails to react
stty -f /dev/ttysNNN size

Also affected: any wrapper that pipes stdout/stderr — script -f, asciinema rec, screen recorders, custom proxy launchers.

Why this matters

op run is the documented, recommended pattern for passing 1Password secret references to a child process (1password.dev/cli/secrets-environment-variables). Many opencode users wrap the binary this way to inject API keys without storing them in plaintext .env files. The current bug makes the TUI silently worse than a normal terminal app for that entire population — most users don't notice until they resize the window and discover the layout is stuck.

Expected

The TUI should reflow correctly on window resize regardless of how the parent process set up stdio, as long as the child is connected to a real terminal (typical case: stdin remains a TTY under op run).

Workaround (until upstream fix)

Resolve the secret reference yourself with op read and exec the opencode binary directly, keeping the stdio attached to the terminal:

#!/bin/zsh
set -euo pipefail
# Resolve every op:// reference from your env file with `op read`,
# then exec opencode directly. Do NOT use `op run`.
export DASHSCOPE_API_KEY="$(op read "op://Clawd/Alibaba VibeReen/notesPlain")"
exec "$HOME/.opencode/bin/opencode" "$@"

Verified working in a 1Password-wrapped invocation pattern that previously broke resize.

Tradeoff: this approach loses 1Password's stdout/stderr secret-masking for the child process. Negligible for an interactive TUI that doesn't echo environment variables, but worth noting.

Root cause and proper fix

The bug is in OpenTUI's CliRenderer. The SIGWINCH listener is gated on _usesProcessStdout and the resize handler reads its new dimensions from this.stdout.columns / this.stdout.rows, which are undefined on a pipe. See:

• opentui#1343 — root cause with line citations and proposed fix (fall back to process.stdin for TTY size when stdout isn't a TTY; broaden the SIGWINCH gate)

The opentui fix would resolve this user-facing symptom here too. Filing this issue separately so the user-visible symptom is searchable, and so opencode maintainers can track it as a release-blocker if they want.

Environment

• opencode: 1.18.13 (latest as of 2026-08-04)
• Bun: 1.3.14 standalone (built into the opencode binary)
• OS: macOS 15 (Darwin 25.x), Apple Silicon
• Terminal: Ghostty 1.x; cmux.app — both reproduce
• 1Password CLI: any v2 release with op run

Likely version range

All opencode 1.x versions using the new OpenTUI-based renderer (≥ v1.0.x, post-2025-11). The earlier Go/Bubble Tea TUI had a related bug class (#2428 — "Message layout sometimes not rendered full-width" after resize), so the new renderer's regression on this dimension is worth tracking even if the upstream cause differs.

Related

• opentui#1343 — root cause + fix proposal (canonical technical thread)
• opencode#3328 — historical, similar symptom in the prior opentui era, root-caused at the time to an upstream Bun SIGWINCH bug
• opentui#1187, #1110 — adjacent stale-repaint issues, likely overlap once the SIGWINCH plumbing is fixed