[FEATURE] Render mod UI (ui.render, panes) in Remote Control clients attached to a terminal session

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

A plugin's hooks module (mod) can draw UI with ui.render and open panes with $.ui.open. That UI shows up in a terminal session, and in a session hosted by the desktop app's Code tab. It does not show up in a Remote Control client attached to a terminal-hosted session. When I drive a terminal session from the Claude desktop app over Remote Control, a mod's pane opens in the terminal window and nothing appears in the desktop app.

Measured on Claude Code 2.1.296, Windows 11, Remote Control auto-enabled on the CLI session, desktop app attached:

• A command typed in the desktop app reaches the session as command.run with origin.kind === 'bridge'. $.ui.open({ id, title }) returns isPlaced: true.
• A matcher-less ui.render hook logged every render request after the command ran (two runs). Every request had surface: 'terminal': AssistantMessage x1, CommandOutput x2, and the Pane x1 with placement: 'dock'. None came from the desktop client, for any component.
• The desktop app showed the command's text reply. So it displays the conversation but never asks the session's mods to draw anything.

The same mod draws its pane in a session hosted by the desktop app, so the gap is specific to Remote Control clients.

Proposed Solution

Let a Remote Control client attach to the session as a render surface, the way a desktop-hosted session does. Its ui.render requests would carry its own surface (desktop, mobile), and panes would place in the client's own layout. A pane opened from a bridge-origin command would then appear where the person typed it.

If that is out of scope for now, it would help to say so in the mods documentation, and to report it through UiOpenResult (for example a reason saying no attached Remote Control client places panes).

Alternative Solutions

• Host the session in the desktop app instead of the terminal. The pane draws there, but the terminal's own workflow is lost.
• Show the mod's content in a separate window beside the desktop app. This works, but it is outside the app and needs its own window management.
• Return the content as command text from a bridge-origin command.run. This loses the live, persistent pane.

Priority

Medium - Would be very helpful

Feature Category

Developer tools/SDK

Use Case Example

1. A mod keeps a live to-do list in a docked side pane, re-reading a file every few seconds.
2. I start a CLI session in my terminal; Remote Control turns on automatically.
3. I continue the same session from the desktop app and type the mod's command to show the list.
4. Today, the pane opens in the terminal I am not looking at. With this feature, it would dock in the desktop app's view.

Additional Context

The probe mod was a ui.render hook with no matcher. It recorded surface, component, requestId, props.placement and viewport for each request, passed every request through with next(e), and drew a sentinel in its own pane. I can share it if useful.