[Bug]: Thread interaction and runtime modes do not sync between desktop clients #5278

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Run the current T3 Code Desktop Nightly on macOS and Windows.
2. Connect both desktop clients to the same remote T3 Code environment.
3. Open the same existing server-backed thread on both clients.
4. On the macOS client, switch the interaction mode from Build to Plan without sending a message.
5. Observe the same thread on Windows.
6. Repeat with the access/runtime mode, for example by switching from Full access to Approval required.
7. The same behavior can be observed in the opposite direction.

Expected behavior

Build/Plan and access/runtime mode are properties of the active thread. Changing either mode on one connected client should persist the new thread state immediately and propagate it to every client viewing that thread. Sending a prompt or reopening the thread should not be required.

Composer text, attachments, and other unsent draft content may remain device-local.

Actual behavior

The other desktop client continues showing its previous mode selection. Each client can therefore display and use a different Build/Plan or access/runtime mode for the same thread.

Impact

Minor bug or occasional failure.

The mismatch is easy to overlook when switching devices and can cause the next turn to run with a different interaction or access mode than expected.

Version or commit

Current Nightly as of 2026-08-03: 0.0.32-nightly.20260803.986, corresponding to main @ 30c96228067b. Exact per-client build numbers were not captured separately.

Environment

• T3 Code Desktop Nightly on macOS
• T3 Code Desktop Nightly on Windows
• Both clients connected to the same remote T3 Code environment
• Same existing server-backed thread open on both clients

Logs or stack traces

No crash or stack trace. This is a deterministic client-state synchronization issue.

Screenshots, recordings, or supporting files

No response

Workaround

Manually verify and select the same modes on every client before sending the next prompt.

Relevant implementation context

The current web client prefers locally persisted composer overrides over the server-backed thread values:

• ChatView.tsx
• composerDraftStore.ts

For an existing server thread, the mode-change handlers update the local composer draft. The corresponding server commands are dispatched by persistThreadSettingsForNextTurn when a message is sent:

• ChatView.tsx
• ChatView.tsx

The server/client-runtime already exposes thread.runtime-mode.set and thread.interaction-mode.set, so this appears to be a synchronization/ownership problem rather than missing thread fields.