What makes tox-tunnel-ops notable?

1.9K downloads. Trust evidence available

How should tox-tunnel-ops be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

tox-tunnel-ops

Encrypted P2P TCP tunneling for remote network access — a self-hosted VPN / ngrok / Tailscale alternative built on the Tox protocol (libsodium). No API keys, no accounts, no central servers, no port-forwarding. Solves NAT traversal, carrier-grade NAT, double NAT, intranet penetration (内网穿透), and remote machine access without router or firewall changes. Tunnels SSH, RDP/VNC desktops, database connections (PostgreSQL/MySQL/Redis/MongoDB), homelab/NAS access (Synology, TrueNAS), local dev servers, and arbitrary TCP ports. Use when: setting up remote SSH/RDP/MySQL/PostgreSQL/Redis/MongoDB access from anywhere, exposing a local dev server or internal web app, sharing a homelab/Synology/TrueNAS service, granting time-scoped contractor access, generating ToxTunnel server/client/rules YAML configs, diagnosing toxtunnel connection failures, tightening rules.yaml access control, running a loopback SOCKS5 / HTTP CONNECT listener through a Tox tunnel, exporting toxtunnel operational metrics into Prometheus / Grafana, hot-reloading rules without restart (SIGHUP / `toxtunnel reload`), inspecting live tunnel state via `toxtunnel inspect`, or wiring multi-server failover for production redundancy.

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.9k

Updated

Oct 10, 2026

Version

0.4.14

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.9K downloads reported by the source. Last updated 10/10/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 10, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 10, 2026
Adoption signal: 1.9K downloadsadoption · observed Oct 10, 2026
Latest release: 0.4.14release · observed Aug 31, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17ewfqx5ypm5882jq61sbrnyx83hg57:tox-tunnel-ops

Install using `clawhub skill install s17ewfqx5ypm5882jq61sbrnyx83hg57:tox-tunnel-ops` in an isolated environment before connecting it to live workloads.
No published capability contract is available yet, so validate auth and request/response behavior manually.
Review the upstream CLAWHUB listing at https://clawhub.ai/agentx-icu/tox-tunnel-ops before using production credentials.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-agentx-icu-tox-tunnel-ops/snapshot"

Documentation

CLAWHUB

159,101 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: tox-tunnel-ops
description: "Encrypted P2P TCP tunneling for remote network access — a self-hosted VPN / ngrok / Tailscale alternative built on the Tox protocol (libsodium). No API keys, no accounts, no central servers, no port-forwarding. Solves NAT traversal, carrier-grade NAT, double NAT, intranet penetration (内网穿透), and remote machine access without router or firewall changes. Tunnels SSH, RDP/VNC desktops, database connections (PostgreSQL/MySQL/Redis/MongoDB), homelab/NAS access (Synology, TrueNAS), local dev servers, and arbitrary TCP ports. Use when: setting up remote SSH/RDP/MySQL/PostgreSQL/Redis/MongoDB access from anywhere, exposing a local dev server or internal web app, sharing a homelab/Synology/TrueNAS service, granting time-scoped contractor access, generating ToxTunnel server/client/rules YAML configs, diagnosing toxtunnel connection failures, tightening rules.yaml access control, running a loopback SOCKS5 / HTTP CONNECT listener through a Tox tunnel, exporting toxtunnel operational metrics into Prometheus / Grafana, hot-reloading rules without restart (SIGHUP / `toxtunnel reload`), inspecting live tunnel state via `toxtunnel inspect`, or wiring multi-server failover for production redundancy."
metadata:
  openclaw:
    requires:
      bins: ["toxtunnel"]
      env: []
    emoji: "🔒"
    homepage: "https://github.com/agentx-icu/tox-tcp-tunnel"
    os: ["darwin", "linux", "win32"]
---

# tox-tunnel-ops
You are a ToxTunnel operations specialist. You help users design, deploy, and diagnose TCP tunnels over the Tox P2P network using **tox-tcp-tunnel**.

Project links:
- GitHub repository: `https://github.com/agentx-icu/tox-tcp-tunnel`
- Releases: `https://github.com/agentx-icu/tox-tcp-tunnel/releases`

## What This Skill Does
This skill helps you create **secure, encrypted TCP tunnels** that work behind NATs and firewalls without any central server. Common use cases:

- **Remote SSH access** — connect to a home or office machine from anywhere, no port forwarding needed
- **Remote desktop (RDP/VNC)** — access Windows/Linux desktops through encrypted P2P tunnel
- **Database tunnel** — securely connect to PostgreSQL, MySQL, Redis, MongoDB through a private tunnel
- **Web service exposure** — share a local dev server or internal web app with teammates
- **NAS / homelab remote access** — access Synology, TrueNAS, or any home server from outside the LAN
- **Intranet penetration** — bypass corporate or carrier-grade NAT without VPN infrastructure
- **Temporary contractor access** — grant time-scoped, auditable access to specific services, revocable without a restart via hot-reload
- **Air-gapped / LAN-only networking** — works entirely on local network without internet
- **Dynamic browsing / debugging proxy** — point a browser, curl, or DB client at a loopback SOCKS5 / HTTP CONNECT listener instead of enumerating every destination in YAML
- **Production HA** — multi-server failover (one primary, ordered fallbacks) for tunnels tha

_meta.json

{
  "ownerId": "kn7bamw47ka1ke1kfr1b857nmn835vyp",
  "slug": "tox-tunnel-ops",
  "version": "0.4.14",
  "publishedAt": 1788185250591
}

references/diagnose.md

# Diagnose Reference

Use this reference when an existing tunnel does not work and you need a layered,
evidence-driven troubleshooting flow.

## Diagnostic Layers

Run through these layers in order. Stop at the first failure and propose a fix.

### Layer 1: Process & Binary

- Is `toxtunnel` installed? (`which toxtunnel`)
- Is it running? (`ps aux | grep toxtunnel` / `Get-Process toxtunnel`)
- Which config file is it using? What mode?
- What version? (≥ v0.3.0 unlocks the inspect/reload/metrics short-circuits below)

**Prefer `inspect` over log tailing for live state.** If the daemon is up
and v0.3.0+, this single command answers Layers 1, 4, and 5 in one shot:

```bash
toxtunnel inspect status --json | jq .
toxtunnel inspect tunnels
```

Look for: `mode`, `version`, `friends_online`, `peer_online_seconds` (client),
`tunnels_active`, `bytes_in`, `bytes_out` — that is the complete field set.
`friends_online: 0` points at Layer 4; friends online with no tunnels points at
Layer 5. (There is no `active_server`, `pid` or `uptime` field, and `inspect`
takes only `tunnels` / `status`.)

### Layer 2: Configuration Static Check

**Start here, always:**

```bash
toxtunnel config check -c /path/to/config.yaml --strict
```

This is the daemon's own validator (v0.4.11+). Exit `0` = usable, `1` =
unloadable / invalid / (with `--strict`) carrying keys the daemon would silently
ignore. Anything it reports is authoritative — fix it before investigating
anything else, and do not hand-audit YAML that it has not seen.

Blind spots you must cover by hand (verified against v0.4.12; the alias one is
closed from v0.4.13):

1. **It never opens `server.rules_file`.** A server config pointing at a
   nonexistent or malformed rules file still prints `is valid`. Rules problems
   surface only when the daemon loads them (Layer 3).
2. **On v0.4.12 and older it does not resolve known-servers aliases.** There an
   alias-form `client.server_id` fails with
   `Server ID must be 76 characters, got N`, even when the alias is registered
   and the daemon runs fine — confirm with `toxtunnel servers list -c <config>`
   before treating that one message as an error. **v0.4.13+ resolves aliases**
   at startup, on reload and in `config check`, so this gap does not apply
   there.

`bash scripts/diagnose.sh <config>` runs the validator and then covers whichever
of these gaps apply to the daemon in front of you.

Then check by hand:

- Is `mode` set correctly?
- Does `data_dir` exist and is it writable?
- Does `tox_save.dat` exist? (first run creates it)
- Client-specific:
  - Is `server_id` set?
  - Is `server_id` not the placeholder `<PASTE_SERVER_TOX_ID_HERE>`?
  - If `server_id` is exactly 76 hex characters → treat as literal Tox ID.
  - If `server_id` is shorter → treat as an alias and check that
    `<data_dir>/known_servers.yaml` exists and contains an entry whose `alias:`
    matches. (`toxtunnel servers list -d <data_dir>` resolves this quickly.)
    A non-76-char `server_id` wit

references/execute.md

# Execute Reference

Use this reference when the user wants to deploy a ToxTunnel setup, install the
binary, start processes, or configure service persistence.

## Step 0: Environment Detection

Run these checks before writing files or starting anything:

### 1. Is `toxtunnel` installed?

```bash
which toxtunnel 2>/dev/null || where toxtunnel 2>nul
```

If not found, prefer package installation over source builds.

#### Preferred: version-pinned native package

The canonical, always-current install instructions are the "Installation"
section of the repo's [`README.md`](https://github.com/agentx-icu/tox-tcp-tunnel#installation);
if this file and the README ever disagree, the README wins. The newest release
at the time of writing is **v0.4.12** — check the Releases page for the current
one rather than trusting this number.

**When you are installing on an operator's machine, do not pipe a script from a
mutable branch into `sudo sh`.** You have already detected OS and architecture,
so you can do the installer's actual job — pick the right asset, hand it to the
package manager — from a version-pinned URL. This avoids piping a mutable remote
script into a root shell. It is **not** "no remote code as root": installing a
DEB/RPM/PKG/MSI still runs that package's maintainer scripts with privileges.
What changes is that the code executed is the released package, pinned to a
version you chose, rather than whatever `master` holds at that moment:

```bash
VER=0.4.12; ARCH=x86_64          # or aarch64
BASE="https://github.com/agentx-icu/tox-tcp-tunnel/releases/download/v${VER}"

# Linux (DEB - Ubuntu/Debian)
curl -fsSL -o "/tmp/toxtunnel-${VER}.deb" "${BASE}/toxtunnel-${VER}-Linux-${ARCH}.deb"
sudo apt-get install -y "/tmp/toxtunnel-${VER}.deb"

# Linux (RPM - Fedora/RHEL/CentOS)
curl -fsSL -o "/tmp/toxtunnel-${VER}.rpm" "${BASE}/toxtunnel-${VER}-Linux-${ARCH}.rpm"
sudo rpm -i "/tmp/toxtunnel-${VER}.rpm"

# macOS (ARCH=arm64 or x86_64)
curl -fsSL -o "/tmp/toxtunnel-${VER}.pkg" "${BASE}/toxtunnel-${VER}-Darwin-${ARCH}.pkg"
sudo installer -pkg "/tmp/toxtunnel-${VER}.pkg" -target /
```

```powershell
# Windows (Administrator PowerShell); ARM: toxtunnel-$VER-Windows-ARM64.msi
$VER='0.4.12'
irm "https://github.com/agentx-icu/tox-tcp-tunnel/releases/download/v$VER/toxtunnel-$VER-Windows-AMD64.msi" -OutFile "$env:TEMP\toxtunnel.msi"
msiexec /i "$env:TEMP\toxtunnel.msi" /qn
```

**Integrity, stated accurately.** No `.sha256` or signature assets are
published — the release carries the packages and their `-latest` aliases. But
GitHub exposes a SHA-256 digest for every release asset regardless, so there IS
something to verify against: compare the downloaded file's digest with the one
GitHub reports for that asset. What is missing is independent
signature/provenance — the digest and the file come from the same party, so it
detects corruption and truncation, not a compromised release. Note also that a
release URL is only immutable if the repository enabled immutable relea

examples/db-migration.md

# Database Migration Window via ToxTunnel

## Scenario

A DBA needs a secure tunnel to a production or staging database for a migration,
data transfer, or bulk operation. The tunnel should be strictly time-limited and
logged.

> **What "audited" means here.** ToxTunnel logs *tunnel* activity: which friend
> opened a tunnel, to which `host:port`, when it closed, and how many bytes
> flowed. Even at `level: debug` it never sees inside the stream — the payload is
> an opaque TCP byte stream to it, so **no SQL statement, table name, row count
> or transaction is ever recorded**. If the migration needs statement-level
> accountability, turn on the database's own auditing (`pgaudit` or
> `log_statement = 'all'` for PostgreSQL, the audit plugin / general query log
> for MySQL) — that is the only place query-level evidence exists. Say this to
> anyone who asks for "an audit trail of the migration".

## Topology

```
DBA Workstation (client)              DB Server (server)
────────────────────────              ──────────────────
pg_dump / migration tool              PostgreSQL on :5432
  → 127.0.0.1:15432                          ↑
        ↓                                    ↑
  toxtunnel client                    toxtunnel server
        ↓                                    ↑
        └──── Tox P2P encrypted tunnel ──────┘
```

## Pre-Migration Checklist

- [ ] Create a **temporary database user** with minimum required permissions
  - Read-only for verification: `CREATE USER migration_ro WITH PASSWORD '...' LOGIN; GRANT SELECT ON ALL TABLES IN SCHEMA public TO migration_ro;`
  - Read-write for migration: `CREATE USER migration_rw WITH PASSWORD '...' LOGIN; GRANT ALL ON ALL TABLES IN SCHEMA public TO migration_rw;`
- [ ] Back up the database before starting
- [ ] Agree on a maintenance window with stakeholders
- [ ] Test the migration on a staging copy first

## Server Config

```yaml
mode: server
data_dir: /var/lib/toxtunnel        # mutable state — NOT under /etc
logging:
  level: debug                       # verbose TUNNEL-level record; not SQL
  file: /var/log/toxtunnel/migration.log
tox:
  udp_enabled: true
  bootstrap_mode: auto
server:
  rules_file: /etc/toxtunnel/rules.yaml
```

> **`data_dir` holds mutable state, so keep it out of `/etc`.** That directory
> carries the Tox identity (`tox_save.dat`), the pid file, the data-directory
> lock and the inspect socket — all written at runtime. `/var/lib/toxtunnel` is
> what the packaged Linux unit uses (`StateDirectory=toxtunnel`,
> `StateDirectoryMode=0750`), owned by the dedicated `toxtunnel` user; macOS
> equivalent is `/usr/local/var/toxtunnel`. Keep `/etc/toxtunnel` for
> `server.yaml` and `rules.yaml` only.
>
> **Run the daemon as that unprivileged account, not as root.** Nothing here
> needs root once the package is installed: the Tox port is 33445 and the targets
> are ordinary services. The packaged unit already does this; a hand-written one
> must set `User=`, `Group=` and `StateDirectory=` i

Github ReposUpdated 10h agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.