Evaluate simulator pane handoff for Expo, Claude, and Codex

[janicduplessis]

Problem

Stim can select a native macOS viewer for an owned local iOS simulator, but browser-based and agent-hosted simulator panes may offer better ways to inspect the same device. They cannot be treated as native open -a targets without checking how they attach to an exact existing UDID and whether they manage its lifecycle.

Evidence

• Expo Device Hub is an Expo DevTools browser plugin or standalone server. Its published feature list includes live device streaming, interaction, boot, shutdown, and device creation: https://github.com/expo/expo-device-hub
• Claude Code Desktop has an iOS simulator pane and can attach a booted device, but its current documentation says the pane does not yet work with Xcode 27 and manages devices by session: https://code.claude.com/docs/en/desktop-ios-simulator
• OpenAI's published Codex simulator workflow uses XcodeBuildMCP and a plugin to drive a booted simulator; a stable Codex pane API for selecting an external UDID has not been verified: https://learn.chatgpt.com/use-cases/ios-simulator-bug-debugging

Cause

These tools expose browser services or agent session controls rather than the native application and URL contract used by Device Hub and Siniulator.

Fix idea

Investigate each tool's supported way to attach to a specific Stim-owned UDID without creating, booting, shutting down, or deleting another workspace's device. Document a manual handoff where no stable programmatic interface exists. Add an adapter only when its lifecycle contract can preserve Stim ownership and the selected workspace device. Keep Expo's project/Metro port requirement explicit.