
rn-devtools-hub
io.github.rn-devtools-hub由 GitHub 账号 rn-devtools-hub 发布v0.22.0更新于 Oct 24, 2026
Drive a running React Native or Expo app from inside its JS runtime: see, act, prove.
概览
本地 hub 与应用内 SDK,让 AI 助手在 React Native 或 Expo 应用的 JS 运行时内查看、操作并验证正在运行的应用。
- 可以做什么
- 查看应用:读取项目上下文、语义化 UI 树,以及带源文件与行号的元素,并审计无障碍暴露情况
- 操作界面:按元素而非像素进行点击、输入、提交和滚动,另有类型化开发动作与原生点击、滑动兜底
- 验证结果:对元素和事件做断言、比较视觉快照,并确定性地冻结时间与模拟网络
- 控制状态与事件:读取和设置应用状态、挂载组件、等待真实事件而非固定等待
- 录制与回放:保存、列出并运行 .hubflow 场景,提出修复候选,导出会话时间线
- 原生与发布:启动模拟器或设备,设置权限、位置、外观与推送,并通过可选插件读取或操作 App Store Connect 与 Google Play
- 适用场景
- 适合在调试或测试 React Native、Expo 应用时,让助手看到 React 实际渲染的内容、按元素操作而不依赖坐标,并用断言而非截图验证行为。也适合希望把运行时场景录制后在 CI 中回放,或需要检查应用商店发布状态的团队。
- 运行要求
- 以 npm 包形式通过 npx 在本地运行,需要 Node 20+(Bun 可选),并需在 React Native 或 Expo 项目中通过 init 接入 SDK。可选功能需要额外项目依赖,如 react-native-view-shot、AsyncStorage 或 expo-sqlite;设备镜像还需 adb 或 Xcode 命令行工具。商店插件需要各自的凭据;仪表盘令牌可用 RN_DEVTOOLS_TOKEN 固定。
安装
在 SourceWeft 中
- 打开 控制台中的 rn-devtools-hub,将其添加到工作区。
- 为需要使用其工具的对话启用该服务。
Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。
其他 MCP 客户端
参照 仓库 中的启动说明。
README
rn-devtools-hub
The agent runtime for React Native. Your agent sees the app the way React sees it, knows which file produced each element, acts without coordinates, and proves that it works. Zero dependencies, no telemetry or usage counting, with a local hub and SDK.
Documentation · Quick start · Integration · Contributing
Use it from an agent
Both plugins install the MCP server plus a skill that teaches the agent to chain its tools: check the project context before debugging anything that looks impossible, prove results with assertions instead of screenshots, wait on events instead of sleeping, and read an element's source instead of grepping the repository.
Claude Code
Codex
Then start the hub at the root of your app, which is what the agent talks to:
Registering the server by hand works too. Claude Code:
Codex, in ~/.codex/config.toml:
Cursor has no marketplace, so it is two files in your own project.
Declare the server in .cursor/mcp.json:
And copy the rule, which is the Cursor equivalent of the skill:
It ships with alwaysApply: false, so Cursor pulls it in when the task
matches instead of paying for it on every request.
For any other agent, the skill on its own comes from the skills.sh registry:
It writes .agents/skills/rn-devtools-hub and links it into whichever
agents it detects, from Gemini CLI and Copilot to Windsurf and Zed. This
installs the skill only, so register the server as above and start the hub
to give the agent something to talk to.
Any client that speaks only stdio uses npx rn-devtools-hub mcp, which
bridges to the hub and starts it on demand.
When a testing or debugging task starts, the agent is instructed to announce
the project and its clickable dashboard URL, then continue automatically.
The hub supplies the actual bound port and current token, including when a
second project uses a fallback port. The link is also available in the
dashboard field of list_devices, get_project_context and session_start.
Screenshots
[Overview panel: KPI tiles, JS thread lag, HTTP statuses and request durations] Overview: request counts, error rate, JS thread lag, connection and device at a glance
[Network panel: request list with colored methods and a foldable JSON response] Network: colored methods, slow requests highlighted, foldable JSON, copy as cURL, secrets redacted before they leave the device
[Mirror panel: live Android screen with tap, swipe and key controls] Mirror: the live device screen over adb, click to tap, drag to swipe, wheel to scroll, plus Back/Home/Recents/Dev menu
[Tools panel: MCP calls per tool, failures, empty answers with their reason, and a timeline of the agent loop against the app's events] Tools: what the agent did and what the app did back, calls per tool split into answered / empty / failed, failures grouped by message, empty answers with the reason the tool gave, and the context each answer bills the agent
Why
The SDK lives inside the JavaScript runtime of your app.
The SDK executes directly alongside your application code. It reads React's tree, invokes handlers, instruments requests and reaches registered stores through APIs installed inside the app. The hub receives these capabilities over its own local connection, without requiring a debugger protocol session. Other tools can access runtime internals through protocols such as CDP; the hub's foundation is an explicit in-app SDK and its event contracts.
That position is what the whole product is built on. Everything else follows from it:
A pure JavaScript SDK in the app (inert in production), a local hub in a single process, a dashboard in the browser. Zero dependencies anywhere, including the hub. The hub has no telemetry. MCP results are delivered to your agent and may be sent to its model provider. Configured store plugins contact their declared vendor endpoints.
Features
The Overview panel opens with the project context: what the project declares, what the app actually runs, and whatever the two disagree on. A stale native build is the most common way to lose an afternoon here, and it is named before you start reading code.
Plus: multi-device with merged sessions, bug report export in Markdown (ready for a GitHub issue), real-time capability badges, and a local MCP server to drive everything from Claude, Cursor or any MCP client.
See Hubflow scenarios to record an exploration, save it as a runtime regression test, replay it in CI and inspect its selected success or failure screenshots in the dashboard.
What an agent gets
Source locations survive React 19, where the location lives in owner stacks pointing into the bundle: the hub symbolicates them against Metro before the agent sees them.
For AI agents, the hub also exposes runtime UI automation over MCP:
get_ui_tree (semantic tree of the visible components, read from the React
runtime, including native views without accessibility like maps), query_ui
(find elements by role and accessible name, testID, placeholder, text or
label, scoped with within, with measured rects), ui_act (tap, type exact
text, submit, scroll, all by element, never by pixels, and it reads the
field back to say whether the text landed), typed dev actions
(list_actions/run_action: navigate, seed, login without touching the
UI), and a correlated event flow (wait_for_event, get_events_since) that
replaces sleeps with real signals like screen.ready. Works in Expo Go,
development builds and bare React Native, and in CI without any simulator:
enable it with devtools.attachUiAutomation().
The hub covers the native layer too, as a superset of what idb/simctl
scripting gives an agent: session_start boots a dev build on the right
Metro server with zero dialogs (permissions pre-granted, dev-menu
onboarding skipped), plus set_permission, launch_app, open_url,
screenshot_native, set_location, send_push, set_appearance,
set_animations, set_overlay (the expo-dev-menu bubble covers native
controls no UI tree can show) and the last-resort tap_native and
swipe_native, on iOS simulators and Android devices, with every capability
probed and degrading cleanly.
Everything above stops at the machine. The half of a release that does not is behind a plugin: App Store Connect and Google Play ship with the hub and stay inert until you give them credentials. They read a release and they drive one, so the agent that decides to widen a rollout is the agent that already has the crash evidence for it. Installing the hub's plugin installs the release skill with it, so there is nothing else to add.
A configured plugin prints the hosts it will contact at startup, an
unconfigured one exposes no tool at all rather than costing an agent context
it cannot use, and RN_DEVTOOLS_PLUGIN_WRITES=off removes every tool that
could change anything. See docs/plugins.md.
Quick start
Prerequisites: Node 20+. Bun is used when present, and is not required. Optional capabilities (adb mirror, iOS simulator, Wi-Fi) have their own prerequisites: see the integration guide.
init inspects your project and generates only the code it can actually
run: axios interception if you use axios, the Storage panel if you have
AsyncStorage, device info if you have expo-device, and so on. It never
overwrites an existing glue file (use --force), and --dry-run shows
what it would change.
That's it: logs, crashes and performance already flow in. Every additional integration (network, cache, storage, SQLite, mirror...) is a recipe of a few lines: see the integration guide.
Integration guide
The SDK is agnostic: it exposes generic primitives that you wire to YOUR libraries. All the recipes are in docs/integration.md, notably:
devtools.attachAxios(instance, "api"): any axios instancedevtools.wrapFetch(fetch, "uploads"): any fetch-based clientdevtools.emit(type, payload): feed any paneldevtools.onCommand(name, handler): respond to the dashboard (e.g. SQLite)devtools.registerAction({name, label, danger, requiresNative}, handler)devtools.attachUiAutomation(): UI perception and actions for AI agentsdevtools.markScreenReady("Login"): "screen ready" signal agents wait on- The complete events and commands protocol: docs/protocol.md. It is the contract: any tool (or any LLM) can integrate a panel by implementing it.
Host project dependencies
The SDK imposes NOTHING. Depending on the features you want, add to YOUR project:
Security
- The SDK is inert outside
__DEV__(double guard: yours and the SDK's) - The dashboard requires a token (printed at startup,
RN_DEVTOOLS_TOKENto pin it) - Sensitive headers (Authorization, cookies, x-api-key) are redacted before leaving the device
- The SQLite console only accepts SELECT and PRAGMA
- The MCP server only listens on localhost, with Origin verification
- Design panel assets are confined to the project root, with whitelisted extensions
- Plugins are the only outbound path, they are inert without credentials, each one declares the hosts it contacts, and no credential is ever returned by a tool or written to a log
- Every plugin tool that changes something is declared as such, is
annotated so MCP clients confirm it, and can be removed entirely with
RN_DEVTOOLS_PLUGIN_WRITES=off RN_DEVTOOLS_SCREENSHOTS=off(or a number) removes or budgets pixel captures, for teams who do not want an agent verifying with screenshots
Contributing
Contributions are welcome. The full guide is in CONTRIBUTING.md. In short:
- Commits follow Conventional Commits
(
feat:,fix:,docs:...): the changelog and versions derive from them automatically (release-it), and commitlint checks them at commit time - The pre-commit hooks run typecheck + tests
- Release:
npm run release(maintainers)
For AI agents: read AGENTS.md and llms.txt.
License
来源:README.md,提交 ec87431
工具
0版本历史
1- v0.22.0最新Sep 16, 2026
评分
已满足适用检查项的 50%
该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。
- 近 30 天内可连通25 分
请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。
- 已声明认证方式10 分
请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。
- 已列出工具15 分
请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。
- 描述必需15 分
- 图标10 分
- 文档15 分
- 许可证10 分