Slack: injected prompt gets "stuck in the input box" — PTY auto-submit fails after multi-line bracketed paste #695

Version: 0.5.5 (Windows 10, Electron build)
Provider: Claude via subscription — claude --model claude-opus-…[1m] --permission-mode bypassPermissions
Slack mode: Socket Mode, channel C0C0LCFJR71

Summary

When the harness hands a queued prompt to an agent (e.g. a relayed Slack @mention
to the orchestrator), it pastes the text into the Claude Code TUI and sends Enter,
but frequently cannot confirm the submit. The message is parked ("Stuck in the
input box"), the agent stays idle, and the one-by-one send QUEUE jams behind it.
Only a manual Enter in the terminal clears it.

Evidence

From HarnessAgents/hive/log.jsonl — the same 1394-char paste retried every ~33s,
every attempt proof:"none" / outcome:"stuck":

pty-submit … source:"queue" chars:1394 bracketed:true pastes:4 key:"csi-u" presses:4 proof:"none" outcome:"stuck" ms:32600
pty-submit … source:"queue" chars:1394 bracketed:true pastes:4 key:"csi-u" presses:4 proof:"none" outcome:"stuck" ms:32182
pty-submit … source:"queue" chars:1394 bracketed:true pastes:4 key:"csi-u" presses:4 proof:"none" outcome:"stuck" ms:32384

Exactly one attempt in the whole session succeeded, and it looked different:
presses:1 proof:"screen" outcome:"submitted".

Likely cause

The tell is bracketed:true plus the TUI state [Pasted text #N +7 lines]. After a
multi-line bracketed paste, Claude Code's input appears to treat the following Enter
as a newline rather than "submit", so the auto-submit keystroke does not register
and screen-scrape confirmation (proof) comes back empty.

Ruled out

• UI tab focus: switching away from the terminal tab made no difference — a new
  injection still returned outcome:"stuck". PTY writes happen behind the UI, so
  the visible tab is not the cause.
• Agent health: the agent is idle / breaker:"healthy" with context headroom
  (~38%); it simply never receives a submitted prompt.

Reproduction

1. Provider = Claude CLI on a subscription (bypassPermissions), Slack in Socket
   Mode.
2. @mention the bot so the harness queues a multi-line prompt to the orchestrator.
3. Observe the terminal: [Pasted text +N lines] appears, QUEUE shows 1 /
   "Stuck in the input box", agent stays idle. Pressing Enter manually submits it.

Suggested fixes

• Confirm submit against the post-paste TUI state before reporting success; retry
  with an explicit submit sequence if not confirmed.
• Avoid a single multi-line bracketed paste for injected prompts — e.g. commit the
  paste, then send a distinct submit keystroke, or send the prompt in a form the TUI
  submits on Enter.

Secondary transport observations (same Slack subsystem)

These are lower-severity but in the same area:

• too_many_websockets churn (pre-0.5.5): the Socket Mode client logged repeated
  socket: disconnect (too_many_websockets) bursts, with more socket starts than
  stops (11 vs 8) — multiple concurrent connections on one app token
  (multiWindow: true is enabled). Appears resolved after the 0.5.5 restart, but the
  connect/leak pattern is worth hardening to one socket per app token.
• thread_not_found poll spam: the poller logs
  slack poll: replies for a thread failed (thread_not_found) about every 60s for
  stale threads tracked in slack-poll.json. Prune dead threads from the poll set.
• Mention-gate UX (docs): inbound only triggers on isMention (app_mention or
  text containing the bot user id) or an active thread —
  if (!isMention && !isActivatedThread) return { trigger: false, … }. Reasonable by
  design, but a plain channel message is a silent no-op; a one-line hint in the Slack
  setup flow ("the bot only responds when @mentioned or in an active thread") would
  prevent confusion.

Notes

• Related issue: the orchestrator also refuses to post replies that arrive as a
  paste, once submitted (filed separately).
• Screenshot available: the "Stuck in the input box" queue state.