Codex: a prompt sent through the input route is pasted but never submitted (Enter folded into the paste burst) #627

TmuxManager.sendInput() types the text of a text+Enter pair with send-keys -l and presses Enter 50 ms later (src/tmux-manager.ts:3780). Codex gets no bracketed-paste markers that way, so it detects a paste from the character burst itself, and an Enter that arrives inside that burst window becomes a newline in the paste. The prompt stays in the composer, the input route has already answered, and nothing else happens.

Every plain prompt that goes through writeViaMux() takes this path: POST /api/sessions/:id/input (and with it codeman agent send and the agent skill) and cron in typed mode.

Measured

codex-cli 0.162.1, tmux 3.5a, a throwaway pane on its own tmux socket, text sent the way sendInput() sends it (text, 50 ms, Enter), checked 3 s later:

The 1506 in the placeholder is the 1505 characters plus the Enter.

SubmitVerifier covers the short case: the stuck line still starts with the prompt, so its 2 s check presses Enter again. I pressed that Enter by hand on the stuck pane and the prompt went out. It can't rescue the long one. The composer shows [Pasted Content 1506 chars] instead of the prompt's head, promptStillInComposer() returns false, and nobody presses Enter again.

On my fork this showed up as messages to Codex workers that were typed but never sent. The sender got accepted, the worker stayed idle.

Fix

Put the text in with set-buffer + paste-buffer -p -d, then Enter as before. tmux only adds the markers when the pane asked for bracketed paste, so a CLI without it gets the same bytes as today. The paste has been running on my fork since 2026-09-25 with claude, codex and opencode workers. PR follows.