# pranshuchittora/simvyn: one CLI for simulators, emulators and real devices

> A TypeScript monorepo that puts iOS simulators, Android emulators and USB devices behind a web dashboard and a headless CLI, with a portable agent skill built on the terminal tool rather than an MCP server. Its stated Node floor and its engines field disagree, and its Pi agent dependencies are pinned to wildcards while everything else is versioned.

**pranshuchittora/simvyn** — Universal mobile devtool for Agents & Humans - control iOS Simulators, Android Emulators, and real devices from a single dashboard and CLI

- Repository: https://github.com/pranshuchittora/simvyn
- Stars: 437 · Forks: 31
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/pranshuchittora-simvyn

## The stated Node floor and the engines field are different numbers

The requirements section says Node.js 22 (22.14.0+) or 24+. The engines field in the manifest says `^22.22.1 || ^24.11.0 || >=26.0.0`.

Those disagree in a way that bites. A machine on Node 22.16 satisfies the documented requirement and fails the engines check, because the caret range starts eight patch releases higher. The same pattern repeats on the 24 line, where the docs name no minimum but the manifest requires 24.11.0.

The manifest is also broader in one direction, accepting anything at or above 26.0.0, which the docs never mention.

Two install routes reach the same binary:

```bash
npm install -g simvyn
```

for a global install, and

```bash
npx simvyn
```

for one-time use with nothing installed. Both then start a local server, open the web dashboard in a browser, and discover connected simulators, emulators and USB devices automatically. The second command is also the whole quick start, which means the first thing a new user runs is the one that will surface the version mismatch.

The platform requirement is equally blunt: macOS for full iOS and Android support, or Linux for Android only. There is no Linux path to an iOS simulator at all.

## The agent skill refuses to register an MCP server, on purpose

The agent integration is the most unusual thing here, and it is a subtraction rather than an addition.

The repository ships a portable Agent Skill that teaches an agent to discover devices, run supported CLI commands, capture screenshots, inspect app data and collect bounded logs. What it explicitly does not do is register an MCP server or any new agent tools. It uses whatever terminal tool the agent already has.

That choice has real consequences. An agent driving simvyn has no bespoke function names to memorize and no schema to keep in context, but it also gets no typed arguments, so the skill compensates by insisting on explicit device IDs and stating the platform limits up front. The reasoning is legible in the docs: the surface the agent touches is the same CLI a person would type.

The agent-facing surface is also much smaller than the feature list. Seventeen feature areas are advertised, and the agent path covers device discovery, supported commands, screenshots, app data inspection and bounded logs. The dashboard, by contrast, exposes all of them, including a command palette and keyboard navigation, styled after Apple's Liquid Glass design language.

Every feature is reachable without the dashboard at all, since the CLI is described as covering everything headlessly through `simvyn <command>`.

## Two agent install paths gated on different release events

Installing the agent integration has two forms, and they become available at different moments.

```bash
pi install npm:simvyn
```

That path treats the npm package as a Pi package and requires Pi 0.74 or later. What it adds is four tools named `simvyn`, `simvyn_screenshot`, `simvyn_logs` and `simvyn_record`, a `/simvyn` command that runs the dashboard, and three prompt templates: `/simvyn-repro`, `/simvyn-screen` and `/simvyn-logs`.

The other path installs the portable skill from GitHub and the CLI separately:

```bash
npm install -g simvyn
npx skills add pranshuchittora/simvyn --skill simvyn --agent codex --yes
```

The gating conditions are different, and that is the trap. The GitHub route needs the skill files to be present on the default branch. The Pi route needs the Pi resources to be in the published npm release. So a change committed to main is usable through one route and not the other until a release ships.

For anything unreleased the documentation redirects to local checkout instructions in the agent setup guide, and a compact index at `llms.txt` sits at the repository root for tooling that accepts documentation URLs. The setup guide also covers a bundled launcher, noninteractive operation and the current limitations.

## The test command reaches three of the seven workspaces

The workspace list runs to seven entries: shared types, core, server, cli, dashboard, and a wildcard covering everything under the modules directory.

The test script does not follow that shape. It invokes the Node test runner through tsx, with the experimental test module mocks flag enabled, and scopes its glob to the core package, the location module and the extensions directory.

So the dashboard, the server, the CLI and every module other than location sit outside the test command. Given that the modules directory is itself a wildcard workspace, the gap is a directory rather than a package, and it grows as modules are added.

The runner flag is worth noting on its own. Module mocking in the Node test runner is still behind an experimental switch, so this suite depends on a flag whose name and availability can change between releases.

Around the tests, the tooling is a two-linter setup rather than one. Formatting is Prettier, which also runs on staged files at commit time through lint-staged and simple-git-hooks, covering TypeScript, JavaScript, JSON, CSS, Markdown and YAML extensions. Actual linting is oxlint with its own configuration file at the root. Type checking is split in two as well: the root project build, and a separate project for the extensions directory, which is where the Pi integration lives.

## The Pi agent packages are pinned to wildcards

Every devDependency in the manifest uses a caret range with one exception pattern that stands out. `@earendil-works/pi-ai` and `@earendil-works/pi-coding-agent` are both pinned to `*`.

The rest of the list is conventionally versioned: lint-staged at ^17.5.1, oxlint at ^1.82.0, prettier at ^3.9.6, tsdown at ^0.23.0, tsx at ^4.23.13, typebox at ^1.3.30 and typescript at ^7.0.2.

So the two packages that the agent extension is built against are the two that can change without a commit. Any upstream release of the Pi agent SDK lands in a fresh install of the development tree, and the extensions directory is where the breakage would surface, which is consistent with it having its own separate type check command.

Two details about that namespace are worth flagging for anyone tracing the dependency. The packages sit under an `earendil-works` scope rather than the Pi vendor scope, and they are referenced by a wildcard while the Pi package registration described in the documentation points at pi.dev. The documentation index for agents is a separate file in docs/ rather than part of the extension.

For anyone reproducing a build, that pair is the part of the dependency set worth pinning locally.

## The dashboard is copied into the CLI package by hand during build

The quick start is one command that both starts a server and opens a browser, which means the web dashboard ships inside the CLI package rather than as something you install separately. The build script shows how.

The release build chains three steps: build the dashboard, build the CLI, then run a preparation script. The CLI build itself bundles the simvyn workspace and then does two shell operations, deleting `packages/cli/dist/dashboard` and copying `dist/dashboard` into its place.

That copy is a literal file copy inside an npm script rather than a bundler feature, so the dashboard's build output has to land at a specific path relative to the repository root for the release to contain it. If the dashboard's output directory ever moves, the copy silently stops matching and the packaged CLI ships without a dashboard.

The development scripts are laid out the same way. The main dev script starts the CLI with a no-open flag in the background and runs the dashboard workspace alongside it, with separate scripts for each half so you can run just the server or just the dashboard. The start script is the plain CLI entry with no flags.

The repository root itself is named simvyn-monorepo, distinct from the published package name, and it also carries a planning directory, so build scaffolding and project planning notes live alongside the source.

## Push sending and app-data clearing are stated for one platform each

Most capability bullets are platform-neutral, which makes the ones that are not stand out.

Push notifications are described as composing JSON payloads, sending them to iOS simulators, and shipping a template library. No Android emulator or physical device is named as a push target anywhere in that list.

App data clearing runs the other direction. Under app management the bullet reads as clearing app data on Android devices, with no mention of the equivalent on an iOS simulator.

Neither asymmetry is flagged as a limitation, and both appear inside sections whose surrounding bullets, such as launching and terminating by bundle ID, are clearly platform-neutral. The detail may exist in the fuller module sections further down, but the summary a reader will act on names one platform per capability.

Elsewhere the module list is genuinely broad. The log viewer streams over WebSocket with level filters from debug through fatal, regex and process-name filtering, find-in-page search that highlights without hiding context, and paginated history with virtual scrolling. The database inspector reaches SQLite tables, arbitrary SQL, SharedPreferences and NSUserDefaults. Crash logs cover iOS diagnostic reports alongside Android logcat and tombstone output. Real-time device state updates arrive over WebSocket.

## Conclusion

Adopt it if you want one surface for driving mobile targets from both a person and an agent, and if you are on macOS, since Linux covers Android only. Choose it particularly if you would rather an agent drive a CLI than inherit a new set of tool definitions. Before committing, check your Node version against the engines field rather than the stated floor, expect the test suite to leave the dashboard and server uncovered, and pin the two Pi agent packages yourself rather than relying on wildcards.

## FAQ

### What does simvyn control?

iOS simulators, Android emulators and USB-connected physical devices from one dashboard and CLI, with real devices discovered automatically and grouped separately. macOS provides full iOS plus Android support while Linux is Android only, and every feature also works headlessly through simvyn <command>.

### Does simvyn install an MCP server for coding agents?

No, and that is a stated design decision rather than an omission. The bundled Agent Skill uses the agent's existing terminal tool and registers neither an MCP server nor new agent tools, instead teaching the agent to drive the CLI with explicit device IDs and platform limits.

### What Node version does simvyn require?

The documentation states Node.js 22 (22.14.0+) or 24+, while the manifest engines field requires ^22.22.1, ^24.11.0 or >=26.0.0. A machine on a Node 22 release between 22.14.0 and 22.22.0 satisfies the docs and fails the engines check.

### How do I install simvyn for a coding agent?

Install the CLI with npm install -g simvyn, then add the portable skill from GitHub using npx skills add pranshuchittora/simvyn --skill simvyn --agent codex --yes. That path needs the skill files on the default branch, while the Pi path needs the Pi resources inside the published npm release.

### What does simvyn add to the Pi coding agent?

Four tools named simvyn, simvyn_screenshot, simvyn_logs and simvyn_record, a /simvyn command that runs the dashboard, and the /simvyn-repro, /simvyn-screen and /simvyn-logs prompt templates. It requires Pi 0.74 or later and installs with pi install npm:simvyn.

### How are simvyn's tests run and what do they cover?

Through the Node test runner via tsx with the experimental test module mocks flag, scoped to the core package, the location module and the extensions directory. The dashboard, the server, the CLI and the remaining modules are not in that path.

## Sources

- [Issues](https://github.com/pranshuchittora/simvyn/issues)
- [pranshuchittora/simvyn on GitHub](https://github.com/pranshuchittora/simvyn)
- [README](https://github.com/pranshuchittora/simvyn/blob/main/README.md)
- [Releases](https://github.com/pranshuchittora/simvyn/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pranshuchittora-simvyn