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.

概覽

AI 產生的概覽

本機 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 固定。
安裝前請注意
助理可以操作並改變正在執行的應用程式:點擊、輸入、修改狀態、掛載元件,以及在模擬器或裝置上執行原生操作。設定憑證後,商店外掛可散布建置、提交審查、推進軌道以及擴大或暫停分階段發布;RN_DEVTOOLS_PLUGIN_WRITES=off 會移除所有可能改變內容的工具。MCP 結果會傳送給模型供應商,已設定的商店外掛會連線至其宣告的廠商主機。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 rn-devtools-hub,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。

其他 MCP 客戶端

參照 儲存庫 中的啟動說明。

README

[rn-devtools-hub]

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

/plugin marketplace add rn-devtools-hub/rn-devtools-hub/plugin install rn-devtools-hub

Codex

codex plugin marketplace add rn-devtools-hub/rn-devtools-hubcodex plugin add rn-devtools-hub

Then start the hub at the root of your app, which is what the agent talks to:

npx rn-devtools-hub

Registering the server by hand works too. Claude Code:

claude mcp add rn-devtools --transport http http://127.0.0.1:8973/mcp

Codex, in ~/.codex/config.toml:

toml
[mcp_servers.rn-devtools]url = "http://127.0.0.1:8973/mcp"

Cursor has no marketplace, so it is two files in your own project. Declare the server in .cursor/mcp.json:

json
{  "mcpServers": {    "rn-devtools": { "type": "http", "url": "http://127.0.0.1:8973/mcp" }  }}

And copy the rule, which is the Cursor equivalent of the skill:

bash
mkdir -p .cursor/rulescp node_modules/rn-devtools-hub/templates/cursor-rule.mdc \   .cursor/rules/rn-devtools-hub.mdc

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:

npx skills add rn-devtools-hub/rn-devtools-hub

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:

The agent canBecause it is inside the runtime
Find an element by role and accessible name, then act on itActions go through the app's own props, not through pixels
Get the file and line that produced an elementThe location lives in React's dev bookkeeping
Prove a step without a screenshotA screenshot cannot show a request that failed silently
Tell a stale native build from a code problemOnly the runtime knows what the binary actually is
Freeze the clock and the networkDate and fetch are in the runtime
Put the app in an exact state without walking ten screensStores are reachable directly
Explain a visual regression, not just score itThe changed region maps back to the component that owns 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

PanelWhat you see
OverviewKPI tiles, JS thread lag, HTTP statuses, duration distribution
CrashesFatal errors, JS errors, unhandled promise rejections, stacks
NetworkRequest/response inspector (colored methods, durations, sizes), copy as cURL, secrets redacted
UploadsLive upload queue (if your app emits the events, see the protocol)
CacheReact Query snapshot: keys, statuses, freshness, data
StorageAsyncStorage keys, sizes, values, live write timestamps
ScreensNavigation journey, time spent per screen
Logsconsole.log/info/warn/error, colorized JSON, filters
SQLiteRead-only SQL console (SELECT/PRAGMA) on your app's database
EndpointsMap of declared endpoints, calls, latencies
ActionsButtons driving the app: reload, clear caches, your custom actions
TestsHuman-readable .hubflow scenarios, live replay progress, failure diagnosis, approved visual evidence and safe target repair candidates
ToolsWhat the agents do with this hub: calls per tool, failures with their message, empty answers and why, context bytes returned (pixels counted separately, because a session spending most of its context on screenshots is a session verifying the expensive way), selectors used, and the loop replayed against the app's own events
PluginsThe services around the app: App Store Connect and Google Play, what each one is configured with, whether it may change a release, and every host it will contact
DesignIcon, splash, fonts, sounds, identity (read from app.json and the assets)
MirrorLive app screen (needs react-native-view-shot in the app), full Android via adb (tap, swipe, keyboard, Wi-Fi), iOS simulator via xcrun

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

ToolWhat it answers
get_project_contextWhat the project declares, what it actually runs, and the contradictions. Call it first when anything behaves impossibly
get_ui_tree, query_uiThe visible components, each carrying the source file and line that produced it
ui_actTap, type, submit, scroll, by element and never by pixel
assertProves a step: element kinds retry, event kinds catch a request that failed silently, a console error, an unhandled rejection
freeze_time, mock_networkDeterministic at the JS level, so a scenario runs the same twice
get_state, set_statePut the app in an exact state without walking ten screens
render_componentMount a component inside the running app, under its real providers
snapshot_baseline, compare_snapshotA visual diff that names the component owning the changed region
export_session, export_flowOne correlated timeline, and actions paired with the consequences they caused
save_flow, list_flows, get_flow, run_flow, propose_flow_repairPersist a runtime scenario, replay it with assertions and screenshots, and create a reviewable repair candidate when a strongly identified target moves
audit_accessibilityWhat React renders but the accessibility tree does not expose
list_plugins, asc_*, gplay_*The release around the app: has the build finished processing, where is the version in review, what is production serving, what do the store reviews say. And driving it: distribute to TestFlight, submit for review, promote a track, widen or halt a staged rollout
capture_store_screenshotsRegenerate the App Store and Play screenshots from the running app: devices, locales and screens from a manifest, each reached with the app's own dev actions, captured at native resolution and uploaded. The pixels never enter the agent's context

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.

bash
# 1. In your React Native / Expo project, as a devDependency:npm install --save-dev rn-devtools-hub
# 2. Wire it up automatically (detects your libraries, writes the glue,#    hooks the entry point, adds the `devtools` script):npx rn-devtools-hub init
# 3. Start the hub (runs on Bun or Node 20+)npm run devtools# -> Dashboard: http://localhost:8973/?token=... (URL printed at startup)

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 instance
  • devtools.wrapFetch(fetch, "uploads"): any fetch-based client
  • devtools.emit(type, payload): feed any panel
  • devtools.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 agents
  • devtools.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:

FeatureInstall in your projectType
The package itselfrn-devtools-hubdevDependencies
App mirror (screen stream)react-native-view-shotdependencies (included in Expo Go)
Storage panel@react-native-async-storage/async-storagealready present in most apps
SQLite consoleexpo-sqlite (or your driver + a sqlite.query handler)depends on your app
Enriched device infoexpo-device, expo-application, expo-networkdependencies
Full Android mirroradb on the dev machine (not in the app)system tool
iOS simulator mirrorXcode command line tools (dev machine)system tool

Security

  • The SDK is inert outside __DEV__ (double guard: yours and the SDK's)
  • The dashboard requires a token (printed at startup, RN_DEVTOOLS_TOKEN to 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:

bash
git clone https://github.com/rn-devtools-hub/rn-devtools-hubcd rn-devtools-hubnpm install          # also installs the husky hooksnpm test             # vitestnpm run typechecknpm run hub          # starts the local hub to test the dashboard
  • 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

MIT

來源:README.md,提交 ec87431

工具

0
SourceWeft 尚未在沙箱中啟動過該軟體包,因此其工具未知。

版本歷史

1
  1. v0.22.0最新Sep 16, 2026

評分

已滿足適用檢查項的 50%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通25 分

    請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。

  • 已宣告認證方式10 分

    請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。

  • 已列出工具15 分

    請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。

  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分