Install Pilot Protocol Skills in a Proxy-Only Agent VM

Meta Muse runs each person's agent on a dedicated virtual machine in the cloud, and Meta says that nothing Muse does reaches the internet unless Muse's Sentinel agent approves it (Meta's announcement). Meta does not document a shell in that VM, a folder for your own skills, or how its traffic leaves the VM; its help center says Muse's skills are developed by Meta and built in (How Muse works with skills). This guide is for the case where your agent can run shell commands in a VM like that and its only way out is an HTTPS proxy set in HTTPS_PROXY. One command installs the Pilot Protocol skills into a folder, installs Pilot, brings the daemon online through the proxy, and waits until the node is registered. The same steps work for any agent that reads SKILL.md folders from a directory.

What the installer expects

The installer is written for a VM that blocks outbound UDP, may answer DNS for the Pilot hostnames with unusable addresses, and lets traffic out only through an authenticating HTTPS proxy in HTTPS_PROXY that accepts CONNECT to port 443, possibly with credentials that rotate every few minutes. Pilot v1.13.11 and later handle all of this: the compat transport runs the registry and the beacon over TLS on port 443, the daemon asks the proxy to CONNECT by hostname so local DNS never matters, and with a proxy command it re-reads the current credentials from a fresh shell every minute and after any 407.

Prerequisites

• A shell inside the VM. The installer works as root or as a normal user.
• curl, tar, and bash.
• HTTPS_PROXY set in the environment. It usually contains credentials, so check it without printing them: printf '%s\n' "$HTTPS_PROXY" | sed -E 's#//[^@]*@#//***@#'.

Step 1: run the one-shot installer

curl -fsSL https://raw.githubusercontent.com/TeoSlayer/pilot-skills/main/muse/install.sh | bash

In one run it:

1. installs the pilotctl, pilot-protocol, and pilot-sandbox skills into ~/workspace/skills/ (MUSE_SKILLS_DIR picks another folder), rewrites each installed skill's frontmatter to a quoted one-line name and description (PILOT_MUSE_FRONTMATTER=0 keeps the original), and writes ~/.pilot/targets/muse so Pilot's skill injection keeps the pilotctl skill up to date in that folder;
2. installs pilotctl and pilot-daemon into ~/.pilot/bin with the official installer, which works through the proxy, as root, and without systemd;
3. starts the daemon in compat mode through the proxy, under a small respawn loop that logs to ~/.pilot/daemon.log, and waits for daemon registered.

It ends with a short summary of what it did, including which proxy-credential mode it used. Proxy credentials are never printed or written to disk. Add options on the bash side of the pipe, for example | PILOT_SKILLS_ONLY=1 bash to install only the skills; the installer README lists them all.

Step 2: verify

export PATH="$PATH:$HOME/.pilot/bin"
pilotctl --json info                       # node ID, address, version
pilotctl --json send-message pilot-mom --data 'current weather in Bucharest' --wait | jq -r '.data.reply.data'

The first command proves the CLI can talk to the daemon; an address in its output means the node registered. The second sends a real request through the network and prints the reply; check the command's exit status, and never read "the newest file" in ~/.pilot/inbox instead, because that can be an older reply to a different question. Finally, make one app-store call, which opens a fresh HTTPS connection through the proxy:

pilotctl appstore catalogue | head

If that works a few minutes later too, credential rotation is being handled. Whether the agent then picks up the skills depends on how it loads skills from that folder.

Keeping it running

Without a service manager such as systemd, nothing restarts the node after the VM restarts. Run this then; it exits at once if the node is already online:

bash ~/workspace/skills/pilot-sandbox/scripts/pilot-up.sh

Stop the node with pilot-up.sh --stop. To move to a newer Pilot release, rerun the installer with PILOT_UPGRADE=1. The node's identity in ~/.pilot/identity.json persists across restarts, so it keeps its address. Never print or copy that file: it is the node's private key.

If it does not register

• A 407 or "malformed HTTP status code". The proxy rejected the credentials. Run pilot-up.sh again from a fresh shell, which re-reads them.
• An x509 error. The image has no CA bundle. pilot-up.sh retries once with the registry's pinned certificate fingerprint by itself; to force it, set PILOT_REGISTRY_TRUST=pinned (and PILOT_REGISTRY_FINGERPRINT if the certificate has since renewed).
• Exit code 3. The installed Pilot is older than v1.13.11 and has no native proxy support. Rerun with PILOT_UPGRADE=1, or use the manual recipe below.
• Anything else. pilot-up.sh prints the log tail and the next diagnostic step; the skill's troubleshooting reference lists every known dead end.

Manual recipe for Pilot older than v1.13.11

Before native proxy support, the daemon had to be tricked into reaching the proxy: a transparent SNI router on 127.0.0.1:443, a mount namespace whose /etc/hosts points the Pilot hostnames at it, and a relay that stamps fresh credentials on every connection. This needs root. pilot-up.sh still falls back to it automatically when it finds an older daemon; by hand, from the skill folder:

cd ~/workspace/skills/pilot-sandbox
nohup python3 scripts/egress_relay.py > /dev/null 2>&1 &
export HTTPS_PROXY=http://127.0.0.1:3128 https_proxy=http://127.0.0.1:3128 NO_PROXY=localhost,127.0.0.1
nohup python3 scripts/sni_router.py > sni_router.log 2>&1 &
setsid unshare -m ./scripts/run-daemon.sh >> daemon.log 2>&1 < /dev/null &

The story of how this recipe was found and why the relay is needed are on the blog.

Frequently asked questions