smithery/hyperlane-xyz

start-http-registry

Start the local HTTP registry server for development. Use when testing infra scripts or commands that need a Abacus work private overrides such as RPC URLS.

Installation

$ npx skills add smithery/hyperlane-xyz --skill start-http-registry

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery/hyperlane-xyz · top by installs.

npx skills add smithery/hyperlane-xyz

Browse all from smithery/hyperlane-xyz

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,311 B
  • docs SUMMARY.md 183 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Start HTTP Registry Server

Start the http-registry server in the background.

Instructions:

  1. First, find the monorepo root (working directory may have drifted):

``bash git rev-parse --show-toplevel ``

  1. Run the command with runinbackground: true, prefixing with cd to the monorepo root AND CI=false inline (see next paragraph for why):

``bash cd <MONOREPO_ROOT> && CI=false pnpm -C typescript/infra start:http-registry ``

--writeMode (optional): append --writeMode when the calling skill will write artifacts back through the server — warp deploy, warp apply, and warp alt create persist the resulting config/addresses via the write routes. Omit it for read-only flows (warp read, warp check). Serving private/pinned RPCs (the reason to use the HTTP registry at all) is independent of --writeMode; the flag only enables the write routes.

Why CI=false: the infra HTTP registry wraps getRegistryForEnvironment (typescript/infra/config/registry.ts:192), which merges filesystem chain metadata with per-chain RPC overrides. The override source is CI-gated: CI !== 'true' → GCP Secret Manager (private / keyed URLs like Alchemy, Dwellir, Ankr, TronGrid); CI === 'true' → MAINNET3<CHAIN>RPC_URLS env vars (the GitHub-Actions injection path). On Haggis workers and any environment where those env vars aren't set, CI=true silently falls back to the public on-disk registry URLs — which are rate-limited (e.g. Tron's public trongrid.io = 3 rps unauthenticated → 429 during broadcasts). Prefix inline so the setting is scoped to this single invocation; do NOT export CI=false globally — other flows in the same session may legitimately need CI=true.

  1. Wait for the log line Server running in the background task's output before any downstream consumer hits the server. This is the canonical readiness signal.
  2. Verify the server is reachable using the /readiness endpoint, NOT the root path — the root returns 404 by design and is not a liveness signal:

``bash curl -sf http://localhost:<port>/readiness && echo "ok" ``

The server only routes specific paths: /readiness, /metadata, /addresses, /chains, /chain/<name>, /warp-route/deploy/<id>, /warp-route/deploy?<filter>, etc. Hitting http://localhost:<port>/ returns 404 even when the server is healthy. Do NOT interpret a root-404 as "server is dead" and fall back to passing the local FS registry path to downstream --registry flags — falling back bypasses the centralized RPC config the HTTP registry provides and can cost real mainnet gas on retries against flaky public RPCs.

  1. Report the task/shell ID + the port (typically 3333, read from the logs) to the user.
  2. Remind the user they can stop it later with KillShell using that ID, or via /stop-http-registry.

Example output:

Started http-registry server in background (shell ID: shell_abc123) on http://localhost:3333. Readiness verified.
To stop it later, I can use KillShell or you can run /stop-http-registry.