CLI: add --mode to `t3 thread send` (auto | queue | steer | restart)#30205

Same need here, from a Telegram bridge. A small gateway runs t3 thread send <id> - --wait --json for each incoming chat message. Chat messages often come in quick bursts, so the second and third messages arrive while the first turn is running. Today the gateway holds and merges them itself, but anything that lands after the turn starts becomes a separate queued turn and the user gets two replies. --mode auto would match the phone composer.

Two details that matter for a bridge:

• --wait with steer: waiting on the run the send returns, as the issue proposes, works for us as long as the reply printed (or shown afterwards by thread show) is the final assistant message of that run, including the steered part.
• Pending requests (#26841): if a steer cancels a pending question or approval, auto would hit this every time the agent is waiting on the user. It would help if auto queued instead of steering while the run has a pending request, or if the CLI documented that it doesn't.

Seen on 0.1.7 (macOS, launchd service); threadSendCommand still hard-codes mode: "queue" on main (9e85538535).

Same need from a Google Chat bridge. A small forwarder service passes each Chat message to the T3 thread for that conversation with t3 thread send <id> -. When people reply while the agent is mid-turn, each reply waits as a separate queued turn. The agent finishes its current answer without the new context, then answers each queued message on its own.

t3_thread_send already supports auto, so passing a --mode auto flag through would let the bridge behave like Send now. A default of queue would keep current scripts unchanged.

We have the same Slack use-case!

+1 for this!

Slack support would be very handy!

Same need from a Slack bridge. Two findings from working around it that may help whoever picks this up:

• The MCP workaround is closed to headless scripts too. A script can mint its own MCP session with t3 auth session issue --subject mcp-client --scope orchestration:read --scope orchestration:operate and call t3_thread_send with mode: "auto" at /mcp. That session has no runtimeModeCeiling, though, so clientModeCeiling treats it as approval-required. Against a full-access thread, t3_thread_send (any mode) and t3_queue promote_to_steer are both refused with runtime_mode_escalation_denied ("Child runtime mode full-access is broader than parent mode approval-required"). The only way to raise the ceiling is the OAuth approval flow, and that token lasts 30 days with no refresh. The CLI itself gets around this because it calls issueMcpClientSession({ access: "full-access" }) in-process, so a --mode flag on t3 thread send would close the gap without a new auth path. (An --access option on t3 auth session issue --subject mcp-client would be a second way.)
• What a bridge has to handle once steering works: when a queued message is promoted to steer, its own queued run ends cancelled and the message moves into the active run (inputIntent: "promoted_queued_to_steer", same messageId). A bridge that waits on the runId returned by the original send will report a cancelled run instead of the answer. With --wait --mode auto (or steer), it would help if --wait followed the message to the run that answers it, as the issue proposes, including when the message is promoted later from the UI rather than by the send itself.

+1, with the same need: a Google Chat bridge relays people's replies into the T3 thread that asked them, and it has to use the CLI, so a correction sent mid-turn waits until the turn ends. We'd use --mode auto for every relayed message. Filed #34503 for a T3-wide default so all agent-to-agent messages (not only the CLI) can follow the user's queue/steer choice.