wire_push
Build a self-contained native binary (xcodebuild Release / gradle installRelease) and install it on a USB-attached phone via the agent's host machine. No Metro / dev server is involved — JS is bundled into the .app/.apk at build time. Auto-detects the framework (Expo, React Native, Flutter, nativ...
This record as markdown: /tools/io-github-kivanccakmak-yaver/wire-push.md
What wire_push does on Yaver
AI agents invoke wire_push to trigger actions in Yaver. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call: builds kicked off, notifications sent, workflows started.
| Parameter | Type | Required | Description |
|---|---|---|---|
path | string | — | Project path. Empty = the AI session's working directory (the dir Claude Code / Codex / opencode was started in) — typically what you want. Walks one level into |
config | string | — | Build configuration. Default Release (self-contained binary, no Metro). Pass Debug only when iterating with a running Metro dev server. |
device | string | — | Specific device UDID (iOS) or serial (Android). Empty = first attached. Run wire_detect first to see your options. |
platform | string | — | Force a platform when the project supports both. Empty = auto-pick (native projects pick by stack; cross-platform projects pick ios on macOS, android elsewhere) |
no_launch | boolean | — | Install the app but don't launch it after. Default false. |
timeout_sec | integer | — | Hard timeout in seconds. Default 1800 (30 min). Cold-cache xcodebuild + pod install + hermesc compile easily hits 20+ min on first run. |
Parameters from the server's own tool schema.
Why wire_push is rated High
This tool compiles native binaries using build systems (xcodebuild, gradle) and installs the resulting app onto a physical device. It executes long-running build and deployment processes, runs shell-level commands, and interacts with external hardware.
From the tool's definition Build a self-contained native binary (xcodebuild Release / gradle installRelease) and install it on a USB-attached phone via the agent's host machine
Risk signalsAccepts file system path (path)
Attacks that exploit this kind of access
The rule that runs wire_push safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Yaver, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For wire_push, this is the rule to start with:
wire_push stays usable, but rate-capped: a runaway agent can't fire it dozens of times a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Yaver, apply this rule, and every wire_push call is checked against it from then on.
Questions about wire_push
Build a self-contained native binary (xcodebuild Release / gradle installRelease) and install it on a USB-attached phone via the agent's host machine. No Metro / dev server is involved — JS is bundled into the .app/.apk at build time. Auto-detects the framework (Expo, React Native, Flutter, native iOS, native Android) and walks into common subdirs (mobile/, app/, apps/*, packages/*) when the path itself isn't a mobile project. Long-running (5-30 min); captures stdout/stderr to ~/.yaver/logs/wire-push-*.log and returns the path + last 30 lines so you can grep for errors. Returns {ok, exit_code, device, platform, stack, log_path, log_tail, elapsed_sec}. It is categorised as a Execute tool in the Yaver MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
wire_push accepts 6 parameters: path, config, device, platform, no_launch, timeout_sec. The full parameter table on this page comes from the server's own tool schema.
Register the Yaver MCP server in PolicyLayer and add a rule for wire_push: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Yaver. Nothing to install.
wire_push is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the wire_push rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for wire_push. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
wire_push is provided by the Yaver MCP server (yaver-cli). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Yaver, and thousands of servers like it.
Across the catalogue