Tailscale plugin: support inbound to the Grok Bot box, or a Tailscale node that survives resets #774
Description
Summary
The Tailscale plugin (third_party/tailscale) lets Grok Bot reach MCP servers on my tailnet as a managed tag:grokbot device. That covers outbound MCP traffic only. Most of what I need from Tailscale is the other direction: devices on my tailnet reaching the Grok Bot box itself. Today that only works by installing Tailscale on the box by hand, and box resets keep breaking it.
My setup
- Personal tailnet. The box runs its own tailscaled as
grokbot-host(tag:grokbots), with Tailscale SSH and one Funnel path. - Inbound uses:
- SSH from my devices into the box (Tailscale SSH only, rules in my tailnet policy)
- A private web app my bots serve on the box's tailnet IP
- A Twilio voice webhook exposed through Tailscale Funnel on a single path (/phone)
- Outbound uses: reading various homelab services over the tailnet
What breaks
The box has been reset several times recently. Each reset wipes /var/lib/tailscale, so the self-managed node needs an interactive re-login, comes back under a new name (grokbot-host-1) until I delete the old machine, and loses its Funnel config. A plugin-managed connection would avoid all of that.
Ask
- Let the plugin's tailnet connection accept inbound traffic to the box: SSH, a TCP port, and Funnel/Serve for a path.
- Let non-MCP traffic from the box (plain HTTP, scripts) use the plugin's connection, not just MCP connectors.
- Or provide a supported way to run a Tailscale node on the box whose identity persists across resets.
Environment
Grok Bot on a personal tailnet. Box Tailscale 1.104.2, kernel TUN mode.
Activity
deanrie commentedon Oct 23, 2026
Hey @Cellolizard, the plugin as shipped is one direction by design: the README's model is a
tag:grokbotdevice whose grants decide which MCP hosts and ports the bot may reach, and nothing in it installs or manages a tailscaled on the box. What you describe (SSH into the box, a private app on its tailnet IP, a Funnel path for Twilio) is node identity for the box itself, which is a different thing from an outbound connector and would have to survive the resets that wipe/var/lib/tailscale. Two parts of your report are actionable on their own and worth separating in the thread: the reset wiping the self-managed node (that is a box lifecycle question, not a plugin one, and belongs with the Grok Bot team with yourgrokbot-host-1rename as the symptom), and the connector growing an inbound mode (that is this plugin's owner's call, and your three concrete uses are the spec they would need). An auth key with--advertise-tagsand a pre-approved tag in your policy would at least remove the interactive re-login after each reset while nothing else changes.