[Feature]: Add an Mobile preview with agent controls like web preview

[IuriGuerreiro]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/desktop

Problem or use case

When developing an Android, IOs or React Native application, I cannot view or interact with the running app inside T3 Code.

The browser preview supports web applications, but mobile development requires switching between T3 Code, Android Studio, and a separate emulator window. The coding agent also cannot inspect the current Android screen or perform basic interactions to verify its changes.

I want to launch or attach to an Android emulator as well ios emulator if possible and see its screen inside T3 Code, and allow the agent to perform controlled interactions such as taking screenshots, tapping, swiping, typing, and pressing Android navigation buttons, for automated testing

Proposed solution

Add an Android device preview surface alongside the existing browser preview.

The desktop application would:

• Discover connected Android emulators and devices through ADB.
• Allow selecting or starting an Android Virtual Device.
• Display the device screen inside the preview panel using a low-latency stream, potentially through scrcpy.
• Forward mouse and keyboard input as taps, swipes, text input, and Android key events.
• Support common actions such as Back, Home, rotate, reload/relaunch app, screenshot, and opening Logcat.
• Preserve the selected device and preview state across client reconnects where possible.

Expose a small set of agent-facing operations, either through the existing preview automation infrastructure or an internal mobile automation service:

• List and select devices.
• Capture a screenshot and structured UI hierarchy.
• Tap or long-press coordinates or UI elements.
• Swipe and scroll.
• Type text.
• Press Back, Home, Enter, and other supported keys.
• Launch or stop an application by package name.
• Wait for a UI element or text to appear.

Existing projects such as Mobile MCP or Appium MCP could be evaluated for automation behavior, but the human-facing preview and emulator lifecycle should remain owned by T3 Code rather than requiring an external MCP server.

Why this matters

This would make T3 Code useful for end-to-end Android and React Native development instead of limiting integrated verification to browser applications.

Developers could remain in one workspace while building, viewing, and testing mobile changes. Agents could also verify UI changes directly rather than relying on the developer to manually describe the emulator state or provide screenshots.

The same internal abstraction could later support physical Android devices and a separate macOS-only iOS Simulator implementation.

Smallest useful scope

An Android-only first version that supports one already-running local emulator.

The minimum useful version would:

• Detect an emulator through ADB.
• Show its screen in a T3 Code desktop preview panel.
• Forward taps, swipes, typing, Back, and Home.
• Capture screenshots for agent inspection.
• Launch an application by package name.

Starting and creating AVDs, physical-device support, Logcat integration, structured UI inspection, recording, multiple devices, and iOS support can follow later.

Alternatives considered

The agent can currently use ADB commands to interact with an Android device. However, this is slow because each interaction requires separate commands for inspecting the screen and performing an action. On real devices, these commands also frequently fail or do not produce the expected result, making the workflow unreliable.

Using Android Studio with a separate emulator window works for manual development, but the agent cannot directly inspect or reliably interact with it.

An external MCP server such as Mobile MCP or Appium MCP could provide more reliable mobile automation, but T3 Code would still need an integrated preview and lifecycle management.

Risks or tradeoffs

• Android emulators consume significant CPU, memory, and disk space, so concurrent emulator instances should be limited.
• T3 Code must supervise emulator, ADB, and streaming processes and clean them up after crashes or shutdowns.
• Video decoding and input forwarding need to remain responsive without affecting conversation rendering.
• Input coordinates must account for scaling, orientation changes, system bars, and device resolution.
• Arbitrary ADB shell access should not be exposed directly to the renderer or agent without validation.
• Physical devices require explicit authorization and should not be controlled accidentally.
• Windows, macOS, and Linux have different Android SDK discovery and virtualization requirements.
• External projects may be useful references, but depending on them directly introduces versioning, security, and lifecycle risks.

Examples or references

• Existing T3 Code browser preview and preview automation architecture
• Android Emulator command-line documentation:
  https://developer.android.com/studio/run/emulator-commandline
• scrcpy, for low-latency Android display and control:
  https://github.com/Genymobile/scrcpy
• Mobile MCP:
  https://github.com/mobile-next/mobile-mcp
• Appium MCP:
  https://github.com/appium/appium-mcp
• Android MCP Server with ADB, UIAutomator, and scrcpy streaming:
  https://github.com/jduartedj/android-mcp-server

Contribution

• I would be open to helping implement this.

[juliusmarminge]

You can use serve-sim for iOS to stream a simulator to the preview browser. Not sure if there's a similar solution for Android https://github.com/EvanBacon/serve-sim

[IuriGuerreiro]

You can use serve-sim for iOS to stream a simulator to the preview browser. Not sure if there's a similar solution for Android https://github.com/EvanBacon/serve-sim

that's really cool i didn't know about serve-sim i tried to check you solutions for android some but didnt tried them out yet:

https://github.com/NetrisTV/ws-scrcpy
https://github.com/bilbospocketses/ws-scrcpy-web

the android solutions are mostly based on scrcpy

I think it it would be really cool if the LLM could make a tool call like Preview_Mobile and it would auto open the preview browser with it, using serve-sim for IOs and another solution for android depending on the user device and what it wants to test, and then use the preview browser tools to test the native app.

[Johnson-f]

add support for this. urgent! claude desktop already have this built in natively no need for serve-sim

[juliusmarminge]

add support for this. urgent! claude desktop already have this built in natively no need for serve-sim

I really don't think our resources are best spent on making a 1st party solution for this when there are good open alternatives. Just make a skill like the one we use ourselves to develop our mobile app (https://github.com/pingdotgg/t3code/blob/main/.agents/skills/test-t3-mobile/SKILL.md)