[Bug] tmux >= 3.7 renders literal ^[[200~/^[[201~ in every delivered message (vis(3) paste sanitization vs hand-crafted bracketed-paste markers)

[chaogebaba]

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.

[haofeif]

@chaogebaba thank you for raising the issue ? would you mind raising the PR for this ?

[chaogebaba]

@chaogebaba thank you for raising the issue ? would you mind raising the PR for this ?

fable 5 fired this issue. i believe just throw it to fable 5 and it will fix it . haha

[call-me-ram]

Confirmed — the hand-crafted \x1b[200~ / \x1b[201~ markers pasted with paste-buffer -r in clients/tmux.py are exactly what tmux 3.7's vis(3) sanitization now neutralizes, and agreed that -S is the wrong fix (it reopens the injection surface 3.7 closed). Your -p approach is the right direction.

One thing the fix has to handle: the unconditional wrap was deliberate — the code comments note -p only emits the markers when the pane has DECSET 2004 active, and some providers (e.g. Kiro CLI) rely on the wrap for multi-line submit behavior. So this needs per-provider verification (paste/enter behavior on kiro_cli, q_cli, claude_code) rather than a bare flag swap.

Since you've validated the patch in your fork, we'll take it from here and land -p plus regression coverage — or if you'd rather send the PR yourself, it's very welcome.

[haofeif]

@call-me-ram mind raising a PR on this ?