Remote Dev Skillkit

Let AI agents safely help on real Mac, Windows, and Linux machines.

Install · Use · Docs · Security · Contributing

What It Does

Remote Dev Skillkit is an open-source safety layer for agent-native remote development.

It lets Codex, Claude Code, Hermes, OpenClaw/OpenCode, and MCP agents connect to a real machine, run scoped repair work, and return audit-ready evidence without receiving unrestricted shell access.

Agent gets	Human keeps
Skills, MCP tools, file/desktop/task adapters	Visibility, authorization, revocation, audit
Signed tasks with clear capabilities	Host-local policy and security boundaries
Artifacts and evidence bundles	Control over what runs and when it stops

Install

Copy the text below and send it to your Agent:

Please install Remote Dev Skillkit for your own agent runtime:
https://github.com/EitanWong/remote-dev-skillkit

Need the full installer contract? See Agent Bootstrap Prompt.

Manual install commands

go install ./cmd/rdev
rdev doctor
rdev bootstrap agent-plan --repo-root .

rdev skillkit export --source-root . --out dist/remote-dev-skillkit
rdev skillkit verify --bundle dist/remote-dev-skillkit

rdev skillkit plan-install \
  --bundle dist/remote-dev-skillkit \
  --out dist/skillkit-install \
  --frameworks codex,claude-code,hermes,openclaw,opencode,generic-mcp-agent

rdev skillkit verify-install-plan --plan dist/skillkit-install/install-plan.json

rdev skillkit install --bundle dist/remote-dev-skillkit --framework codex --target ~/.codex/skills
rdev skillkit install --bundle dist/remote-dev-skillkit --framework codex --target ~/.codex/skills --execute

Use

1. Connect A Machine

Ask your agent:

Use Remote Dev Skillkit to connect this computer for a visible support session.

The agent should use rdev.sessions.connect or:

rdev support-session connect --start

Inspect provider eligibility before starting a tunnel, especially on mainland China networks:

rdev tunnel providers --region cn-mainland --json
rdev tunnel probe --region cn-mainland --provider-policy /protected/path/providers.json --json

These inspection commands are read-only: they do not start a tunnel, accept terms, register an account, change configuration, or print credentials. A direct gateway or managed tunnel is reported as degraded-single-entry and is not ready to send by default. For an attended session, an operator may explicitly pass --allow-degraded-direct-handoff; the result remains degraded, is not ready to activate or execute, and still requires explicit stop/cleanup.

For --region global, the current Agent-side order is: a configured stable operator gateway; Cloudflare Quick Tunnel (priority 10); the managed, checksum-pinned tunn3l v0.5.1 client (priority 20); and localhost.run with its reviewed official host key (priority 30). Pinggy (priority 40) and other SSH providers are considered only after an explicit operator allowlist and an exact reviewed host pin. The target-side human still receives exactly the newly generated target_handoff_envelope.full_text: one recommended public hostname embedded in one short readable PowerShell command, not a tunnel selection UI.

If the target explicitly reports trycloudflare.com DNS failure or NXDOMAIN, do not retry Cloudflare as the default and do not manually start a tunnel. In a protected absolute work directory, create a protected provider-policy file with only:

{"disabled_provider_ids":["cloudflare-quick"]}

Then keep rdev support-session connect --start --work-dir <ABSOLUTE_PROTECTED_WORK_DIR> --region global --provider-policy <PROTECTED_POLICY_PATH> in the foreground. Let managed tunn3l or localhost.run take over, and send only the new generated handoff. Do not build a multi-URL PowerShell loop or mutate DNS, hosts, proxy, firewall, or target bootstrap state. One successful sample does not become cn-mainland evidence.

Anonymous/account-free tunnels are availability candidates, not guaranteed mainland-China services. cn-mainland remains fail-closed without fresh verified China Telecom, China Unicom, and China Mobile evidence. tunn3l's Anonymous=true means no account or registration is required; it is not a privacy or no-telemetry guarantee. In v0.5.1, the upstream client creates a dv_ plus 24-hex device ID (source) and sends that ID, the Agent hostname, and Agent OS in relay registration metadata (source). rdev gives it a fresh empty session HOME/USERPROFILE/XDG config and clears tunn3l credentials, subdomain/password overrides, and runtime preload variables, so it does not reuse the user's real ~/.tunn3l and generates a new session-scoped ID. The relay still observes normal network and HTTP tunnel traffic. These statements are pinned to that v0.5.1 source commit and must not be generalized to other releases.

Windows Temporary Layered Entry

For Windows amd64 attended sessions, a trusted Agent can verify the signed rdev-bootstrap.exe release artifact and materialize a private layered handoff. The bootstrap fetches an HTTPS layered-assets.json, verifies its Ed25519 release-root signature, selects only the Windows core rdev-host runtime, and uses the shared resumable content-addressed downloader. The controller pins the expected release version and windows/amd64 in signed bootstrap metadata; the bootstrap requires the downloaded manifest to match that version before it requests the runtime. Ticket and gateway values remain in the separately signed join manifest.

The first run downloads and SHA-256 verifies the core runtime. A warm run revalidates and reuses the digest cache without fetching the runtime again. The user-scoped cache is rooted below %LOCALAPPDATA%\RemoteDevSkillkit\cache; managed directories and files use private 0700/0600 permissions. On Windows, the primary visible launcher is Start-ConnectionEntry.ps1. The visible Start-ConnectionEntry.cmd broker tries that launcher under the current policy, retries with a process-scoped -ExecutionPolicy Bypass, and then uses its native CMD path. The retry changes no registry or machine policy. All paths share one private attempt directory; once its state reaches core_started, no launcher starts another core. Both launchers restrict handoff, attempt, and cache ACLs to the current user, SYSTEM, and Administrators; reject reparse or UNC paths; recheck bootstrap size and SHA-256; and keep the verified bootstrap in the foreground.

Temporary mode runs the selected host in the foreground. It does not install a service, create a scheduled task or registry persistence, or start a background updater. If layered prerequisites were not published, Connection Entry retains the visible Start-ConnectionEntry.ps1 archive-compatible fallback. Signature, digest, origin, path, or verification failures never execute the downloaded asset or automatically downgrade. The launcher prints the separately verified self-contained archive fallback as an explicit recovery command instead.

The layered run report contains from_cache, resumed, bytes, and ordered stage durations for manifest fetch, signature verification, runtime resolution, and launch preparation. bytes is the verified runtime size, not measured network transfer volume. No performance target is claimed until real Windows cold and warm acceptance evidence is collected.

For acceptance, save the first standalone JSON report emitted by each run as cold-layered-run.json and warm-layered-run.json; do not include subsequent foreground host output in either file. Package both reports with the other real Windows evidence:

rdev acceptance package-windows-temporary \
  --plan windows-plan/windows-temporary-plan.json \
  --out windows-evidence \
  --transcript transcript.txt \
  --release-verification rdev-verify.json \
  --audit audit.jsonl \
  --no-persistence-dir no-persistence \
  --denial-probes-dir denial-probes \
  --cold-layered-run cold-layered-run.json \
  --warm-layered-run warm-layered-run.json

The packager requires a cache miss in the cold report, a cache hit in the warm report, the complete ordered verification stages, and nonnegative durations. Reports containing ticket, gateway, token, redaction-marker, or private-path content are rejected before copying. Synthetic fixture reports are non-production and do not satisfy the formal release gate or replace a real Windows run. Keep the complete session-bound Windows evidence package private; review any report separately before publication.

2. Run Scoped Work

The agent creates signed tasks for specific capabilities: shell, PowerShell, files, desktop, Codex, Claude Code, or adapter workflows.

Examples:

rdev mcp tools
rdev demo local

3. Review Evidence

Tasks return artifacts, audit events, and evidence bundles before the agent claims the work is complete.

go test ./...
rdev acceptance fresh-agent-support-session --out .rdev/acceptance/fresh-agent-support-session

Built For

Scenario	Why it fits
Remote debugging	Agent can inspect, run tests, and collect evidence
Environment repair	Host policy controls what commands can run
Support sessions	Target user sees and can revoke the session
Agent framework setup	Same Skillkit works across major agent runtimes
Adapter development	pkg/adapterkit provides conformance helpers

Safety

Remote Dev Skillkit is for explicit, consent-based remote development.

It rejects hidden persistence, UAC or sudo bypass, disabled local security controls, public inbound listeners on target hosts by default, and unrestricted shell access without policy enforcement.

Docs

Topic	Link
Documentation index	docs/README.md
Install details	Skillkit Install
MCP tools	MCP Stdio
Bootstrap flow	Bootstrap
Architecture	Architecture
Threat model	Threat Model

Languages

English · 简体中文 · Español · Français · Deutsch · 日本語 · 한국어 · Português · हिन्दी · العربية · Русский

Develop

scripts/check.sh

License: Apache-2.0