Summary

Fixes #216. kiro-cli 2.1.x's TUI v2 fails to repaint after a SIGWINCH from tmux's attach-time resize. CAO created detached sessions at tmux's default 80×24, and cao launch immediately attached the user's terminal — triggering an 80×24 → real-terminal-size resize that kiro handled by blanking the screen and silently dropping all subsequent input.

Reproduction (on latest main, kiro-cli 2.1.1, tmux 3.5a)

10/10 runs fail with the following flow:

1. CAO creates detached pane at default 80×24
2. tmux resize-window -x 220 -y 50 (equivalent to tmux attach-session resizing to user's terminal)
3. Pane goes completely blank — kiro-cli cleared the screen and never repainted
4. tmux send-keys "hello" lands in the buffer but nothing appears on-screen
5. CAO POST /input — status stays idle for 30+ s, never transitions to processing/completed

Fix

Add explicit x=220, y=50 to TmuxClient.create_session()'s new_session(...) call so the pane is born at a realistic size. The attach-time resize is then a no-op or small shrink (e.g. 220×50 → 200×48), which kiro handles correctly.

Why 220×50: wider than nearly any real terminal, so the attach is always a shrink rather than a grow. Shrinks redraw cleanly; grows are what kiro 2.1.x breaks on.

Changes

src/cli_agent_orchestrator/clients/tmux.py

• create_session(): pass x=220, y=50 to server.new_session(...), with an inline comment linking to kiro_cli: TUI v2 input unresponsive when session created headless (80x24 default pane size) #216 explaining why the parameters are load-bearing.

test/clients/test_tmux_client.py

• test_create_session_uses_explicit_dimensions: asserts x=220, y=50 land on the new_session call. Guards against accidental removal during future cleanup.

Why scoped to create_session only

All CAO providers share this session-creation path. None of the other providers tested (claude_code, codex, gemini_cli, copilot_cli, kimi_cli, opencode_cli, q_cli) show any input sensitivity to pane size — only kiro-cli's new TUI has the repaint bug. But since every provider benefits from consistent starting dimensions (no surprise resize on attach), a global change is simpler and safer than a provider-specific override.

Verification

• Unit tests: 1517 passed, 1 skipped (CI invocation)
• tmux-client tests: 52 passed
• black --check src/ test/ clean
• isort --check-only src/ test/ clean
• Live repro: before fix, 10/10 runs fail post-resize; after fix, send_message completes in ~5 s with correct output.

Upstream

The root cause is a kiro-cli 2.1.x bug in its SIGWINCH handler — tmux and all other TUI providers handle grow-resizes correctly. Worth filing at kirodotdev/Kiro with the exact repro above, but we can't block on that fix landing.

Test plan

• Unit suite passes
• Lint + formatters clean
• Reproduces issue kiro_cli: TUI v2 input unresponsive when session created headless (80x24 default pane size) #216 before the fix (10/10)
• Does not reproduce after the fix
• cao launch --agents developer --auto-approve (non-headless) accepts keyboard input on the user's terminal after attach