Terminal gaps for AI agent orchestration workflows (scriptability, output read-back, session persistence)

[anthonykim1]

Been looking at the AI coding agent orchestration space — tools like oh-my-claudecode, oh-my-codex, gajae-code. These are multi-agent orchestrators that spin up parallel agent sessions, coordinate between them, and monitor output. Every single one of them requires tmux and builds on top of it rather than VS Code terminal.

We actually already have a lot of the building blocks — workbench.action.terminal.new with { cwd }, split, renameWithArg, Terminal.sendText(), changeColor/changeIcon, task presentation.group for split layouts. The "launch and manage" side is solid.

What's missing is the other half — reading back, controlling from outside, and surviving a window close:

1. Output read-back — extensions can sendText() into a terminal but can't read what it printed. tmux has capture-pane -p. Without this, an orchestrator can't check if an agent session finished, errored, or is waiting for input. Shell integration's command detection helps for structured commands but most agent CLIs are freeform output.

2. External terminal control — tmux lets any script do tmux send-keys -t session:pane "command" Enter. We don't have a code --send-terminal <name> <command> equivalent. If you want to control a named terminal from a Python script or shell script outside VS Code, you need a running extension or the task system. Something like the existing code --goto / code --diff pattern but for terminal.

3. Persistent/detachable terminals — closing VS Code kills all terminal processes. tmux sessions survive disconnect. For long-running agent sessions (overnight runs, etc.), there's no way to close the editor and come back to running terminals. Could be opt-in per terminal rather than all-or-nothing.

Related issues: #90696 (tmux control mode, has 20 comments going back to 2019), #320044 (remote session persistence)

Not saying we need to replace tmux — lots of people prefer it and will keep using it. But users already inside VS Code shouldn't have to leave to an external multiplexer for these workflows, and extension authors should be able to build orchestration tools natively.

[markolofsen]

This matches what I would split into two contracts rather than one larger terminal API:

1. A live terminal contract: create a named terminal, send input, read bounded output, receive process/exit/waiting events, and attach correlation IDs to commands so an orchestrator can tell which output belongs to which action.
2. A durable session contract: terminal/process identity that survives the VS Code window closing, with an explicit reconnect/snapshot path when the extension or UI comes back.

The important detail is that read-back alone is not enough. If output capture is only a stream, an extension that attaches late cannot distinguish "nothing happened" from "I missed the event." For agent orchestration, I would want:

• snapshot of current named terminals and active commands;
• ordered output/status events from a cursor;
• per-command IDs, exit status, timestamps, and terminal lifecycle events;
• explicit overflow/disconnect/terminal-gone states that tell the client to resync;
• a bounded output API so extensions do not accidentally scrape unlimited terminal history or secrets.

For the external-control side, a CLI shape like code --terminal-send <terminal-id-or-name> --stdin ... would be useful, but I would keep it permissioned and workspace-scoped. Otherwise it becomes a hidden remote-control surface.

I build cmdop, so biased — we handle this at the machine/session layer rather than inside VS Code. The same failure modes show up either way: stable session identity, reconnect after UI/process restart, bounded output replay, and idempotent command completion events matter more than just "can I send text to a terminal?"