rn-devtools

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-hub
codex 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:

[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:

{
  "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:

mkdir -p .cursor/rules
cp 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.

Related MCP server: React Native MCP Server

Screenshots

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.

# 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:

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:

git clone https://github.com/rn-devtools-hub/rn-devtools-hub
cd rn-devtools-hub
npm install          # also installs the husky hooks
npm test             # vitest
npm run typecheck
npm 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