Summary
Description
When launching an interactive agent (e.g. Claude Code), the terminal accepts keyboard input immediately after the tmux session is attached, even though the agent's TUI has not finished initializing.
If the user starts typing immediately after the terminal opens, the first few keystrokes are rendered above the actual input field (in the output area) instead of inside the prompt. The text becomes uneditable and appears "stuck" until the agent finishes rendering. Subsequent input behaves normally.
This appears to be a timing race between terminal attachment and agent readiness rather than a rendering issue.
Steps to Reproduce
- Launch an interactive TUI agent (e.g. Claude Code).
- As soon as the terminal becomes visible, immediately start typing.
- Observe where the first word is rendered.
Expected Behavior
Input should only be accepted once the agent is ready to receive interactive input, or early keystrokes should be buffered until the agent reaches that state.
The first typed characters should always appear inside the active input box.
Actual Behavior
- The first word is rendered in the terminal output region instead of the input box.
- The misplaced text cannot be edited.
- After the agent finishes initializing, all subsequent typing behaves normally.
Impact
- Confusing first-time user experience.
- Makes it appear as though the terminal is broken or input is lost.
- No actual data loss occurs, but users often need to delete and retype the initial input.
Root Cause
The terminal enables input as soon as the tmux attach stream is established. However, an attached terminal does not necessarily mean the agent's interactive TUI is ready.
This creates a short window where input is forwarded before the agent has mounted its input component.
Possible Improvement
Consider delaying input until the agent reports an interactive state (for example, waiting_input) when supported by the adapter.
For agents that cannot expose readiness, a small configurable grace period after attachment could reduce the likelihood of this race.
Notes
- This is most visible with full-screen TUI agents such as Claude Code, Codex, and similar interfaces.
- Other line-based agents may experience the same timing race, although the symptom is typically much less noticeable.
- No input bytes appear to be lost; the issue is primarily one of input timing and presentation.
Priority
P2 (Minor)
This does not block functionality or cause data loss, but it is reproducible, confusing, and impacts the first interaction with newly launched agents.
Attached screenshot demonstrates the first typed characters rendering outside the intended input field.
Summary
Description
When launching an interactive agent (e.g. Claude Code), the terminal accepts keyboard input immediately after the tmux session is attached, even though the agent's TUI has not finished initializing.
If the user starts typing immediately after the terminal opens, the first few keystrokes are rendered above the actual input field (in the output area) instead of inside the prompt. The text becomes uneditable and appears "stuck" until the agent finishes rendering. Subsequent input behaves normally.
This appears to be a timing race between terminal attachment and agent readiness rather than a rendering issue.
Steps to Reproduce
Expected Behavior
Input should only be accepted once the agent is ready to receive interactive input, or early keystrokes should be buffered until the agent reaches that state.
The first typed characters should always appear inside the active input box.
Actual Behavior
Impact
Root Cause
The terminal enables input as soon as the tmux attach stream is established. However, an attached terminal does not necessarily mean the agent's interactive TUI is ready.
This creates a short window where input is forwarded before the agent has mounted its input component.
Possible Improvement
Consider delaying input until the agent reports an interactive state (for example,
waiting_input) when supported by the adapter.For agents that cannot expose readiness, a small configurable grace period after attachment could reduce the likelihood of this race.
Notes
Priority
P2 (Minor)
This does not block functionality or cause data loss, but it is reproducible, confusing, and impacts the first interaction with newly launched agents.
Attached screenshot demonstrates the first typed characters rendering outside the intended input field.