[Bug]: splitting a pane can restore a stale unsent composer draft into the new pane #16695

Operating system: macOS

Orca version: 1.4.188

Summary

Observed (second-hand, twice on 2026-08-27): splitting a new pane in the same tab / same worktree showed yesterday’s unsent prompt in the new pane’s input line. Pressing Enter (or orca terminal send --enter) would submit that old text into the new session.

This session could not reproduce same-session copy of an unsent PTY line on a plain cat pane. The restorer (Orca GUI composer vs the in-pane agent CLI) is not identified. Please treat the split+stale-draft report as a product bug with a partial isolation, not as a proven root cause.

Environment

• Orca desktop 1.4.188
• macOS 26.5.1
• Isolation attempt: throwaway cat pane in this worktree only (created, split, closed; no other panes were sent to)

What we could reproduce here (negative result)

# throwaway pane, not an agent TUI
orca terminal create --worktree current --title scratch --command cat --json
# -> term_src

orca terminal send --terminal term_src --text "UNIQUE_MARKER_NOSEND" --json
# no --enter; marker visible on `orca terminal read --terminal term_src --screen`

orca terminal split --terminal term_src --direction vertical --json
# -> term_new

orca terminal read --terminal term_new --screen --json
# UNIQUE_MARKER_NOSEND was NOT present on the new pane
# it remained only on term_src

orca terminal close --terminal term_new --json
orca terminal close --terminal term_src --json

So: same-session split does not copy a pending PTY line buffer for a non-agent cat pane. That rules out a naive “split clones the kernel input line of any PTY” explanation. It does not rule out Orca’s GUI composer / launch-draft mirroring, or an agent TUI restoring its own unsent input.

What was observed (second-hand; not re-run here)

On 2026-08-27, twice:

1. Same tab, same worktree: Split a new pane.
2. The new pane’s composer/input line already contained an unsent prompt from the previous day.
3. A later send --enter would have submitted that old prompt into the new session.
4. Workaround that worked for the observer: Ctrl-U on the new pane’s input line before sending.

Actor unknown (Orca composer vs in-pane CLI). No other-pane contents were read for this report.

Expected

A newly split pane should start with an empty composer/input line, unless the user explicitly pasted or typed there. Stale drafts, if persisted at all, should be keyed by pane identity, not reused across a new split.

Harm

An orchestrator that splits a pane and immediately terminal send --enters a brief can concatenate or replace that brief with yesterday’s unsent text. The new agent then runs the wrong instructions. The failure is silent if the operator does not inspect the composer first.

Workaround

• After every split, inspect the composer. If it is not empty, Ctrl-U (or otherwise clear) before sending.
• Prefer orca terminal read --screen on the new handle and refuse to send when the composer glyph line is not empty.
• Related in-progress Orca work (not a substitute for fixing restore-on-split): PR #16290 / issue #16289 refuse terminal send --enter when a Claude Code / Codex composer already has a draft. Scope of that PR does not claim Hermes/Grok/plain shells, and it does not by itself stop a stale draft from appearing.

Related public issues (may be the same class; not confirmed)

• Issue #12358 (open): GUI draft-layer text is composited into orca terminal read as if typed. DEL via terminal send does not erase phantoms (so they are not in the PTY). Author suspects the v1.4.163 “mirror multi-line launch drafts into the chat composer” path rematerializing stale drafts. Asks that drafts not be composited into read, and that terminal show --json expose draft state.
• PR #12932: rich input composer (feature; context only).

If #12358’s GUI draft layer is keyed by worktree (or tab) rather than pane, a new split could legally rematerialize a day-old launch/composer draft. That is a hypothesis, not a finding from this isolation.

Caveat

• Isolation used a non-agent cat pane only (safe throwaway). The original observation was an agent TUI pane. This report does not claim the restorer is Orca, and does not claim it is the agent CLI.
• Cross-day restore was not reproduced in this session (would need an agent composer + a persisted draft).
• No screenshots; no raw logs; no internal paths or names.