tui: allow forcing synchronized output (DECSET 2026) inside tmux
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 65/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- typescript
- 領域
- cli
調査の方向性
まず、issueで説明されているTUIレンダラーの設定とターミナルセッションモードの解決方法を読み、その後、レンダラーのオプションがユーザーにどのように公開されているかをたどってください。ユーザーがauto、always、neverを選択でき、選択したモードがtmux内の同期出力マーカーを制御できれば完了です。issueにはマーカーを確認するためのキャプチャコマンドが記載されています。
索引モデルが issue の本文から書いたものです。
説明
Summary
When opencode runs inside tmux, the TUI never wraps frames in synchronized
output (CSI ? 2026 h/l), so tmux redraws partial frames and animations (e.g.
the tab indicator) visibly stutter. The renderer already supports a
synchronizedOutput mode (auto / always / never), but opencode does not
expose it, and auto deliberately disables it whenever a multiplexer is
detected. Please make this configurable so users on tmux ≥ 3.7 can opt in.
Environment
- opencode version: 2.2.3 (latest)
- OS: Linux 7.0.0-38-generic (Ubuntu 26.04, x86_64)
- Terminal: Windows Terminal over SSH → tmux 3.8;
TERM=tmux-256color,TERM_PROGRAM=tmux,COLORTERM=truecolor - Shell: /bin/bash
- Install/channel: latest (standalone binary,
~/.opencode/bin/opencode) - Active plugins: none found in config
Reproduction
- Run the TUI inside tmux 3.7+ (
tmux new-session -A -s oc opencode). - Record the pane output:
tmux pipe-pane -t <pane> -o 'cat > /tmp/pane.bin'. - Trigger an animated area (the working indicator / tab animation) and keep it running for ~10 s.
- Count synchronized-output markers in the capture:
python3 -c "d=open('/tmp/pane.bin','rb').read(); print(d.count(b'\x1b[?2026h'))"
Expected Behavior
With a terminal that advertises synchronized output support, the TUI batches
each frame in CSI ? 2026 h … CSI ? 2026 l, so the multiplexer draws complete
frames and animations are smooth. Ideally this can be controlled from config,
e.g. sync/synchronized_output with auto (default), always, never.
Actual Behavior
Inside tmux the count is 0 synchronized frames, while the same TUI outside
tmux emits frames in pairs. 10-second captures on the same machine:
| Run | Capture size | ?2026h / ?2026l |
|---|---|---|
| inside tmux 3.8 | 71,051 B | 0 / 0 |
inside tmux, TMUX unset |
70,986 B | 127 / 127 |
inside tmux, TMUX unset (10 s) |
243,015 B | 250 / 250 |
The rendering still happens (dozens of KB per second, thousands of cursor
positioning sequences), it is simply not batched, which shows up as uneven
animation pacing.
The tmux side is capable: tmux 3.8 answers DECRQM 2026 with ?2026;2$y and
tracks DECSET 2026 from applications (it responds ?2026;1$y while a
synchronized update is open).
Additional Context
The gating is in the renderer setup, not in tmux: the TUI process passes
hostMultiplexer: ... && !!(process.env.TMUX || process.env.STY || process.env.ZELLIJ)
into the terminal session, and the session resolves the mode as
s.synchronizedOutput ?? "auto". The native flags already exist
(OT_TERMINAL_SYNC_ALWAYS, OT_TERMINAL_SYNC_NEVER, OT_TERMINAL_HOST_MULTIPLEXER),
and the terminal setup accepts "auto" | "always" | "never" — but the TUI
renderer options never set synchronizedOutput, so auto always wins and a
multiplexer disables batching.
Why "auto" for multiplexers made sense historically: tmux older than 3.7 ignores
?2026h/l, so batching had no effect. Since 3.7 tmux responds to DECRQM 2026
and supports DECSET 2026 from applications, and 3.8 additionally fixed redraw
issues around synchronized updates (flicker with alternate-screen applications,
scrollbars, tabs, status lines).
Workaround currently in use: launch the TUI with TMUX removed from its
environment (env -u TMUX -u TMUX_PANE opencode). That flips hostMultiplexer
off, batching starts (250 frames / 10 s), and animations become smooth — but it
also disables all intentional multiplexer-aware behaviour, which is why a
first-class option would be preferable.
Relevant versions: opencode 2.2.3, tmux 3.8 (statically built), Ubuntu 26.04.
- 主要言語
- TypeScript
- スター
- 221k
- フォーク
- 29.6k
- 平均マージ
- 7時間 19分
- マージ済み PR（30日）
- 504
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
anomalyco/opencode のほかの issue
-
core: OpenRouter BYOK sessions record cost = 0 since v2.2.0 (ignores cost_details.upstream_inference_cost)対応中かも @tneemo が 1 日前に担当しました。 オープンreproduced
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
anomalyco/opencode#60558 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
anomalyco/opencode#60541 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
anomalyco/opencode#60529 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
anomalyco/opencode#60469 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
TUI permission prompt for MCP tools doesn't show the call arguments対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
anomalyco/opencode#60350 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
anomalyco/opencode の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
Northeastern-Electric-Racing/FinishLine#4660 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
excaliburjs/Excalibur#3895 ·
メンテナーはふだん 3 日以内に返信
-
infer_audio_type only recognises one MPEG Layer III frame header, so most MP3 files are rejected対応中かも @Steve-20-ai が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
Earn report crashes with "RangeError: Invalid time value" when a report row has an unparsable timestamp対応中かも @Gurkaran18 が今日担当しました。 オープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
joinmarket-webui/jam#1588 ·
メンテナーはふだん 3 日以内に返信
-
BeOS .json missingオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
mihaip/infinite-mac#475 ·