Not Yet Implemented

Not Yet Implemented

Some things are advertised in the README, or exposed as a toggle in the UI, that do not work yet. The settings are real — they're parsed, validated, stored, and in some cases even sent across the wire — but nothing acts on them.

This page exists so you don't waste an evening debugging a feature that was never built. If a setting is on this list and it isn't doing anything: that's why. It's not your config.

Please don't file bugs against these. Feature requests and "I'd use this" comments are welcome.

The list

Thing	What you see	What actually happens
Offline MOTD	A per-tunnel field for a message to show players when your server is down.	Nothing is served. The code to answer a Minecraft status ping exists and is tested, but it is never called. When the agent or your server is down, the gateway just closes the connection — players get a normal "can't connect", not your message.
Bandwidth cap	A per-tunnel "limit throughput" field.	No rate limiter exists. Setting a value has no effect on throughput whatsoever.
Prometheus /metrics	A Settings toggle and an address field.	No metrics server exists. Nothing listens on that address; there is no /metrics endpoint to scrape.
Minecraft-aware = "polls the server for MOTD, player count and version"	That's what the tunnel editor's hint says.	There is no polling. What actually happens is passive sniffing of the login handshake — which is enough to attribute connections to player names, and that's all. The server's MOTD, player count and version are never fetched. The health check is a plain TCP connect.
UDP tunnels	The config file will accept type = "udp" if you hand-edit it.	There is no UDP code at all. The gateway rejects the tunnel and it never comes up. Minecraft Bedrock is UDP, so Bedrock is not supported.
per-conn transport	An agent.transport config value, and a Settings mention.	Never read. The agent always multiplexes; the gateway rejects anything else. Leave it on mux.
Minimize to tray	A Settings toggle (on by default!).	There is no tray icon. The setting is stored and ignored.
Autostart	A Settings toggle.	Does nothing. To start at boot, install the Windows service — that's the supported path.
Linux / macOS builds	CI publishes EXPERIMENTAL-linux-amd64 and EXPERIMENTAL-macos-universal artifacts.	They compile but cannot run. The engine must serve a Windows named pipe, and the IPC layer returns "unsupported" everywhere else — so the window opens and the engine immediately dies. They exist only to keep the code from rotting, and are never shipped as release assets. Real cross-platform support needs a Unix-socket IPC port.

Documentation and CLI that lies

Not features — just wrong text. Being upfront about these too:

• --headless is a no-op. The flag exists on proxyforward agent / gateway and is never read. Those subcommands are always headless; --headless=false will not give you a window.
• service install --role gateway does not exist. The README shows a --role flag; the service command takes no flags at all. The role comes from the config file. See CLI Reference.
• The headless gateway prints a broken pairing code. The code logged to the console at startup always contains the literal placeholder YOUR-PUBLIC-ADDRESS, even when you've set gateway.public_host. The token and fingerprint in it are correct — only the hostname is a stand-in, and you must substitute it by hand. Only the GUI fills in the real host.
• The README's download link 404s. No release has been tagged yet. Use a CI build or a source build.
• "Settings → Windows integration" (README) is really Settings → System.

Why ship the toggles at all, then?

Mostly because the config schema and the UI were built out ahead of the engine, and the project's own docs are candid about it — this list is derived from the maintainer's own "Reality check" table, which is the canonical source and is kept honest against the code.

The project's rule is that when one of these gets implemented, its row is deleted in the same commit that implements it. So: if a row is still here, the feature is still missing.

What does work

To be clear, because this page is a list of holes and that gives a skewed impression — the core is real and is tested hard:

• The tunnel itself: TLS 1.3, certificate pinning, multiplexed streams, one connection per player.
• Automatic reconnection, DNS re-resolution, resume-from-sleep, and clean session takeover.
• PROXY protocol v2 for real player IPs.
• Player-name attribution via login sniffing, with skins and avatars.
• Local analytics, traffic history, uptime tracking, and geography (with your own GeoIP file).
• Windows service, firewall integration, port-conflict diagnosis, redacted diagnostics bundles.
• A throughput and latency floor enforced in CI on every commit, plus continuous fuzzing of every parser an attacker can reach.