Summary

On hosts with tmux ≥ 3.7, every inbox message CAO delivers to a worker pane renders with literal ^[[200~ / ^[[201~ around it (caret-notation garbage in the receiving TUI), and multi-line messages can mis-submit. The cause is CAO hand-crafting bracketed-paste markers, which tmux 3.7 now deliberately sanitizes.

Root cause

clients/tmux.py send_keys (with force_bracketed_paste=True, used for all inbox delivery) manually wraps the message bytes:

buf_content = b"\x1b[200~" + keys.encode() + b"\x1b[201~"

and pastes with tmux paste-buffer -r.

tmux 3.7 added security hardening (see 3.6b→3.7 CHANGES): pasted buffer content is passed through vis(3), converting each ESC (0x1b) into the literal two characters ^[ — explicitly to neutralize bracket-end injection. -r does not bypass this; -S is the documented opt-out. So the hand-crafted markers arrive as visible text in every receiving agent TUI.

Verified empirically on tmux 3.7-2.fc44 (Fedora 44): hexdump of the received pane shows 5e 5b (^[ literal) where 0x1b was sent; readline with DECSET 2004 active does not consume the caret-notation text.

Fix that works (validated in our fork)

Stop hand-crafting markers entirely; let tmux do the wrapping with paste-buffer -p:

• buf_content = keys.encode() (raw, no ESC wrapper)
• paste_flag = "-p" instead of -r

-p emits genuine 0x1b bracket markers conditionally on the pane's DECSET 2004 state (observable via #{bracket_paste_flag}), which is also more correct than unconditional wrapping: panes that never requested bracketed paste don't get the markers at all.

Do not fix this with -S (it reopens the content-injection surface tmux 3.7 just closed — worker-authored message bytes could inject control sequences into a receiving TUI). The vis(3) sanitization is a security feature worth keeping.

Impact

• Any CAO deployment on a distro shipping tmux ≥ 3.7 (Fedora 44+, and others as they update) gets visibly corrupted message delivery to every agent pane.
• Providers that never enable DECSET 2004 (e.g. Kiro CLI) revert to per-line submission for multi-line messages under -p; that is pre-existing tmux semantics, not a regression of the fix.

Repro

1. Host with tmux ≥ 3.7.
2. Start any CAO session, assign a worker, send_message it a two-line message.
3. Observe literal ^[[200~ / ^[[201~ around the delivered text in the worker pane.