[Feature]: terminal send needs --text-file or stdin — multi-line text cannot be sent reliably today #14915

Translated to English (the template asks for it). The closing note has been narrowed to design context rather than a second request — see the bottom.

Problem or use case

orca terminal send accepts its text only through --text <string>. There is no --text-file, and it does not read stdin. For a coordinator sending structured briefings to agents, that makes multi-line text impossible to send reliably.

$ orca terminal send --help
Usage: orca terminal send [--terminal <handle>] [--text <text>] [--enter] [--interrupt] [--json]

Confirmed in src/cli/specs/core.ts: the command's allowedFlags are terminal, text, enter, interrupt and the globals. Nothing else.

Why --text does not cover it. Tested sending a ~3900-character briefing with headings, lists and code blocks:

• --text-file <path> → invalid_argument; the flag does not exist.
• Passing multi-line content through a shell wrapper on Windows truncates at the first line break. The call reported Sent 88 bytes — the briefing's title and nothing else — and --enter then submitted that fragment, so the agent received a single decontextualised line as if it were the instruction.
• Escaping everything onto one line works, but destroys the readability of the message the human sees in the agent's terminal, and is where quoting mistakes come from.

The workaround in use today is to write the briefing to a file and send a one-line --text saying "read this path and execute". It works, but it adds a step that can fail — the agent may not read it — and it makes the instruction depend on an absolute path on this disk, which survives neither a different machine nor a remote agent.

Proposed solution

Any of these, in order of preference:

1. --text-file <path> — the CLI reads the file and sends its contents as one block. Minimal and trivial.
2. stdin — cat briefing.md | orca terminal send --terminal … --stdin --enter, which composes with everything else.
3. Accept a repeated --text, one per line. Least good, but it unblocks.

Alternatives or additional context

The file-and-pointer workaround above is the alternative, and its failure modes are the reason for filing: it depends on the agent choosing to read the path, and on that path existing on whatever machine the agent runs on.

One piece of design context, not a second request. When the destination pane is busy, send --text … --enter queues the message into a follow-up box rather than delivering it, and an extra --enter queues it again — so the agent receives the same instruction twice when it closes its turn. I saw the two copies side by side.

That is a different defect and I am not asking for it here. It is relevant only because it bears on this feature's design: if send starts accepting large blocks, it is worth deciding deliberately what happens when the target is busy, rather than inheriting the current behaviour at a larger size. If maintainers would like the queueing behaviour and the fact that --json does not distinguish delivered from queued tracked as their own issue, I am happy to file it separately.

Related: #14822 (injected prompts sitting unsubmitted in the composer), #14914 (what happens downstream when a send lands in a composer that is not clean).