Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/jianzhichun/emergenpx agentmods add skills/jianzhichun/emerge/remote-runner-devWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/jianzhichun/emerge/remote-runner-dev)<a href="https://agentmods.dev/skills/jianzhichun/emerge/remote-runner-dev"><img src="https://agentmods.dev/badge/skills/jianzhichun/emerge/remote-runner-dev.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00051 | $0.03563 |
| Opus 5 | $0.00026 | $0.01782 |
| Sonnet 5 | $0.00010 | $0.00713 |
| Haiku 4.5 | $0.00005 | $0.00356 |
Grade C, and why
remote-runner-dev scanned grade C with 2 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Downloads and executes remote codehighSupply chain
curl | sh runs whatever the server returns today, which is not necessarily what it returned when this was reviewed.
Or open **Cockpit → Monitors → Add Runner** and copy the `curl … | bash` / `irm … | iex` lines. The script downloads the runner bundle from the daemon, writes `~/.emerge/runner-config.json`, installs optional pip deps, a Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
Or open **Cockpit → Monitors → Add Runner** and copy the `curl … | bash` / `irm … | iex` lines. The script downloads the runner bundle from the daemon, writes `~/.emerge/runner-config.json`, installs optional pip deps, a How it starts
The opening of the file, as written. The whole thing — 287 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Remote Runner Dev
Overview
Emerge's remote_runner.py is a lightweight HTTP execution server that runs on any machine where the actual tools live — a Windows VM with CAD software, a Linux HPC node with simulation tools, a GPU workstation, a mobile device emulator host. The dev machine stays clean; all environment-specific execution happens on the runner.
Core principle: deploy via icc_exec HTTP — not SSH exec, not SCP. The runner is its own deployment channel.
Architecture
Dev machine Remote machine (any OS)
──────────────── ──────────────────────────────────
emerge project dir deploy ─► <plugin_root>/scripts/
scripts/ icc_exec runner_watchdog.py (daemon)
connectors/ HTTP ─► └─ remote_runner.py (port <N>)
scripts/repl_admin.py └─ executes icc_exec calls
└─ has access to local tools,
GUI, COM objects, hardware
The runner executes code in its own process environment — not in the SSH session that deployed it. This distinction matters when the tool requires:
- A specific user session (Windows COM, GUI automation)
- Local hardware (GPU, USB device, simulator)
- Environment variables set at desktop login (conda env, license server, display)
Key Source Files
| File | Role |
|---|---|
scripts/remote_runner.py |
HTTP server; executes icc_exec only. Also contains RunnerSSEClient (connects to daemon SSE, dispatches popup commands) |
scripts/operator_popup.py |
Popup renderer. Persistent tk-main thread + _tk_dispatch queue; all popup types use tkinter Toplevel dialogs |
scripts/runner_watchdog.py |
Keeps runner alive; restarts on crash or .watchdog-restart signal |
scripts/repl_admin.py |
CLI: runner-install-url, runner-deploy, runner-status |
scripts/runner_client.py |
Routes requests to runner by target_profile |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 287 lines · 51 tokens per session scan C 310f241b4513
remote-runner-dev is a skill published in the GitHub repository jianzhichun/emerge (107 stars, last pushed 4mo ago), licensed MIT. It adds 51 tokens to every session and 3,563 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it C with 2 findings (downloads and executes remote code, makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
gke-ai-troubleshooting-jobset-interruption
Diagnoses GKE JobSet interruptions, restarts, and preemptions for AI/ML training workloads autonomously. Use when troubleshooting JobSet restart loops, spot VM preemptions, node readiness failures, host VM issues, or coordinator worker crashes. Don't use for general GKE cluster creation, basic workload deployment, or…
gke-node-notready
Diagnoses GKE nodes reporting NotReady or Unknown status by inspecting node conditions, events, kubelet/containerd logs, and node metrics, then proposing safe remediations. Use when nodes show NotReady, when the kubelet stops posting node status, or when workloads are evicted or stuck Pending due to node health. Don't…
gke-workload-troubleshooting
Diagnoses GKE workload failures (CrashLoopBackOff, OOMKilled, ImagePullBackOff, Pending, etc.) via logs and events. Use when pods fail to start or crash repeatedly. Don't use for GKE cluster infrastructure provisioning, node pool creation, or non-Kubernetes Google Cloud services.
gke-ai-troubleshooting-handle-disruption-gpu-tpu
Diagnoses, predicts, and mitigates node disruptions during Compute Engine host maintenance and hardware or software maintenance events for GPU and TPU workloads on GKE. Use when diagnosing node disruptions, predicting host maintenance events on GPU/TPU nodepools, inspecting node interruption PromQL metrics, auditing…
agentcore-investigation
Investigate Bedrock AgentCore runtime sessions via CloudWatch Logs Insights — resolve session/trace IDs, query OTEL spans, filter noise, build timelines. Use when debugging AgentCore agent sessions, tracing tool calls, or analyzing latency.
troubleshoot-sandbox
Troubleshoot OpenSandbox issues by running diagnostics (logs, inspect, events, summary) via CLI or HTTP API to diagnose sandbox failures like OOM, crash, image pull errors, network problems, etc.