Keep a thread's model when a message is sent from the composer, and make the desktop composer usable through macOS accessibility

[yarikRefine]

Context

T3 Code 0.1.6, macOS desktop. One "coordinator" Claude thread drives several long-running orchestrator threads. It sends them messages with t3_thread_send.

When that MCP send failed with parent_not_active (the provider switch-back problem in #16565 and #23006), the coordinator fell back to the desktop app. It used macOS accessibility automation to open each thread, type a message and send it. That fallback exposed the two problems below.

1. Sending from the composer silently changes the thread's model

Two threads had run on Codex (gpt-6.1-sol) since they were created. Their composers showed Claude Opus 5.5 in the model picker. Sending a message there moved both threads to Claude Opus 5.5 from that turn on. Nothing warned about it.

For someone who only wants to add a message to a running workflow, a send that changes the thread's provider is surprising. The thread's later turns, cost and tool behaviour all change.

Proposal: one of these.

• The composer opens on the thread's current provider and model.
• Or, when the picker differs from the thread's last run, the composer shows that sending will switch the model and asks for confirmation.

2. The desktop composer is hard to drive through accessibility

Observed with an accessibility client (AXUIElement based):

• Pressing a thread's sidebar tree item reports a failed action, but the thread does open.
• The message text field does not accept text set through accessibility. Only synthesized physical keystrokes work.
• We could not find a Send button among the window's exposed buttons, so sending needed a physical Enter key press.

Proposal: expose the composer field as an editable text element that accepts a value. Expose Send as a labelled button. Make the sidebar item's press action report success when it opens the thread. This also helps screen-reader users, not only automation.

Why it matters

When MCP orchestration tools are unavailable, the desktop app is the only way for an agent, or an assistive-technology user, to message a thread. Today that path needs physical input and can silently change the thread's model.

The CLI (t3 thread send) does work as a fallback. Its existence is not obvious from the MCP error, though. Mentioning it in the parent_not_active message would also help.