terminal send --enter can be swallowed by update-available modal

[eakmanrq]

Reproduction

1. Start an Orca-managed Codex or Claude terminal.
2. Wait for readiness:

   orca terminal wait --terminal <handle> --for tui-idle --timeout-ms 60000 --json

3. While the Orca Update available modal is present, submit a prompt:

   orca terminal send --terminal <handle> --text "Follow the instructions in <document>." --enter --json

4. Inspect the terminal UI or transcript.

The command reports a successful send/accepted byte receipt, but the update-available modal consumes the Enter key. The prompt remains in the agent composer and no instruction-document output appears, so callers cannot distinguish a submitted prompt from bytes that only reached the terminal input path.

Expected behavior

terminal send --enter should either dismiss/handle the modal and submit the prompt, or return a typed receipt indicating that submission did not occur. The receipt should not claim success based only on bytes written when Enter was swallowed.

Workaround

Read the terminal/transcript after the send and, when the exact prompt remains in the composer, issue one bare Enter. Do not paste the full prompt again or redispatch the task.

[manuaudio]

Your second sentence is exactly right and provable from source — the receipt is a write receipt, not a submit receipt. The mechanism you attributed it to, though, I think I can rule out, and there's an in-tree explanation that produces the identical symptom. Checked against upstream/main at a0a654c3a9.

The receipt cannot mean what callers read it as

RuntimeTerminalSend (src/shared/runtime-types.ts:603-608) is the whole vocabulary:

export type RuntimeTerminalSend = {
  handle: string
  accepted: boolean
  bytesWritten: number
  refusedReason?: 'no-agent' | 'permission'
}

and sendTerminal (src/main/runtime/orca-runtime.ts:16671-16675) fills it in immediately after the PTY write returns:

      return {
        handle,
        accepted: true,
        bytesWritten: Buffer.byteLength(payload, 'utf8')
      }

payload comes from buildSendPayload (:36680-36696), which is string concatenation and nothing else:

  let payload = ''
  if (typeof action.text === 'string' && action.text.length > 0) {
    payload += action.text
  }
  if (action.enter) {
    payload += '\r'
  }

So bytesWritten counts the Enter byte while nothing in the path ever looks at the composer. accepted: true means "the bytes went to the pty," full stop. Your framing — callers can't distinguish a submitted prompt from bytes that reached the input path — is precisely what the type permits.

Why I don't think the update modal is the cause

Two things point away from it.

UpdateCard handles exactly one key (src/renderer/src/components/UpdateCard.tsx:448-451):

  const handleKeyDown = (e: React.KeyboardEvent) => {
    if (e.key !== 'Escape') {
      return
    }

It's mounted as an overlay card in App.tsx:2649-2660 with tabIndex={-1} — no Enter handling anywhere in the component. And more decisively, terminal send never becomes a DOM key event: it's an RPC into the main process that calls ptyController.write(ptyId, payload). Renderer key handling isn't on that path, so there's nothing there to swallow it.

I'd expect the modal to be a coincidence of timing rather than the cause. Which matters, because if the fix is scoped to "dismiss the modal first," the real failure will survive it.

What I think is actually happening

The single-write shape is the suspect. --text … --enter sends <text>\r as one payload, one write, no bracketed paste, no delay — and the repo already documents that exact failure mode. src/shared/agent-prompt-injection.ts:10:

// Why: ConPTY renders long bracketed pastes more slowly; an early Enter leaves the task in the agent input buffer.

"Leaves the task in the agent input buffer" is your symptom, written down in the tree.

That comment guards sendTerminalAgentPrompt (orca-runtime.ts:16704), which is the submit-aware path — bracketed paste, a 500 ms delay (1500 ms on Windows), then a separate \r write (writeTerminalAgentPrompt, :17271-17315). It has five call sites, all in orchestration (coordinator.ts:469, orchestration.ts:1313, orchestration-federation.ts:228, orchestration-workers.ts:234). The terminal.send RPC never reaches it, so orca terminal send --enter gets none of the three mitigations.

Your "typed receipt" ask already exists — one layer up

requireAgentStatus: 'sendable' yields the typed refusals in the type above, and sendActiveAgentNote (src/renderer/src/lib/active-agent-note-send.ts:185-252) is the full two-phase pattern: paste with the guard → POST_PASTE_SUBMIT_DELAY_MS → re-check readiness → submit Enter as a second guarded RPC, returning 'partial-submit-failed' (:227, :231, :248) when the text landed but the submit didn't. That status is the receipt you're asking for; it just isn't reachable from the CLI. requireAgentStatus has only those two consumers today — terminal send doesn't set it.

The snag for whoever fixes this

The CLI can't simply pass requireAgentStatus: 'sendable' on its existing single call, because the RPC deliberately refuses that combination (src/main/runtime/rpc/methods/terminal.ts:1286-1295):

      if (params.requireAgentStatus === 'sendable' && hasText && hasSuffix) {
        // Why: guarded sends are two-phase; reject combined payload + submit so a guard flip can't cause partial delivery.

So --text … --enter would have to become two RPCs the way the renderer already does it — which is the design question (does the CLI keep the one-shot shape and gain a truthful receipt, or adopt the two-phase one and gain partial-submit-failed?) rather than something to guess at.

Worth noting your workaround — read back, and if the prompt is still in the composer send a bare Enter — is the manual version of exactly that second phase.

The measurement that would separate the two causes

Reproduce with no update modal present, sending the same prompt via --text … --enter in one call.

• Still lands in the composer → the modal is incidental and this is the single-write/no-delay path, as above.
• Submits reliably without the modal → my read is wrong, the modal really does participate, and I'd want to know how, because the write path I traced doesn't go near renderer key handling.

Also useful: does the prompt contain newlines, and roughly how long is it? The documented failure is length- and timing-sensitive, so that would sharpen it.

What I did not verify

I have no Orca build running here, so I haven't reproduced either variant — the receipt semantics, the missing paste/delay, and the modal's Escape-only handler are read from source and are solid, but which of the two causes is yours is what the no-modal run decides.

[AmethystLiang]

thanks for reporting. looking into it