tunnel-mcp

Files (6)

• SKILL.md
• binary.md · references/
• profiles-state-and-keys.md · references/
• runtime-flows.md · references/
• setup-and-install.md · references/
• troubleshooting.md · references/

SKILL.md (first lines)

# Tunnel MCP

Use `scripts/tunnel_mcp` from this plugin when a user asks Codex to manage MCP
tunnels through `tunnel-client`. The plugin entrypoint is a thin router onto
the public native `tunnel-client runtimes ...` and
`tunnel-client admin-profiles ...` command trees.

When the `tunnel-mcp` MCP app tools are available, use them first instead of
manual shell routing:

- `install_or_select_tunnel_client`
- `create_tunnel_runtime`
- `connect_stdio_mcp`
- `list_runtime_aliases`
- `runtime_status`
- `stop_runtime`

The app tools are an operator surface over native `tunnel-client`; they
orchestrate `tunnel-client runtimes ...`, normalize structured output, and keep
tunnel protocol/runtime behavior in the Go binary.

Before acting, consult only the smallest relevant reference under `references/`:

- `references/binary.md`: how to find or obtain a public-safe `tunnel-client` binary
- `references/setup-and-install.md`: install, export, reset, binary-vs-bundle setup
- `references/profiles-state-and-keys.md`: profiles, state dirs, admin/runtime key split
- `references/runtime-flows.md`: create, connect, list, status, stop, rm, attach by tunnel id
- `references/troubleshooting.md`: `/healthz`, `/readyz`, `/ui`, status, logs, stale aliases

## Rules

- Use `tunnel-client admin tunnels` for remote tunnel CRUD. Do not call raw
  tunnel-service HTTP endpoints from this plugin.
- Route operational actions through `tunnel-client runtimes ...` and
  `tunnel-client admin-profiles ...`.
- Use `scripts/tunnel_mcp self-check` for plugin/binary/router compatibility;
  it must report secret reference presence without printing secret values.
- Use native `tunnel-client run --profile <name>` only when the user
  intentionally wants a foreground daemon attached to the current terminal;
  do not translate profile files into flags in the plugin layer.
- For a long-lived local runtime managed by Codex, use
  `tunnel-client runtimes connect ...`; do not use `nohup` or `disown` as the
  tunnel-client supervision path.
- After `runtimes connect`, run `tunnel-client runtimes status <alias>` before
  reporting success. Only report success when status shows the managed runtime
  running with health reported; use `--json` when Codex needs explicit
  `process_running`, `healthy`, and `ready` fields.
- Do not assume a source checkout, build system, helper, or tmux. The installed
  plugin must work with the selected `tunnel-client` binary alone.
- Treat ambient `PATH` binary candidates as diagnostics unless selected through
  `--tunnel-client-bin`, `TUNNEL_CLIENT_BIN`, or `.tunnel-client-bin`.
- Tunnel state, admin profiles, generated runtime profiles, stale-alias
  handling, cleanup classification, and local process management are owned by
  native `tunnel-client`; consult the relevant reference before explaining those
  details.
- Keep admin and runtime credentials split: admin CRUD uses
  `admin-profiles`; runtime attach/connect uses `--runtime-api-key env:NAME` or
  `file:/path`. Do not pass literal keys.
- Never write literal API keys, bearer tokens, cookies, or inline `sk-` style
  secret material into plugin state or generated configs.
- Surface `control_plane_poll_health` separately from `/healthz` and `/readyz`;
  local readiness can be green while control-plane polling fails through a dead
  proxy.

From dylmarriner/scos-memory, MIT.

More from dylmarriner/scos-memory