Reach your fleet from another device — without opening it up.

One extra step on each new device

Loom's loopback API requires a local access credential on every write and on the terminal socket, even over a tunnel. On the host, loom open appends it for you; a tunnelled browser has never seen it — so you get a writes-locked state rather than a broken one. The cockpit loads and reads normally, and the moment the daemon turns down a write or a socket it switches to that state: a banner saying writes are locked, with a field to paste the credential into. A terminal pane also prints its own reason line in place of staying blank. Paste the credential and writes work again — nothing is replayed, so redo whatever was refused; terminals re-attach by themselves. Paste a wrong or stale one and the banner tells you that credential was refused, and keeps the field so you can try the right one.

The credential is the contents of gateway-loopback.key under LOOM_HOME (~/.loom/gateway-loopback.key by default), read off the host — the machine running Loom, not the one you're sitting at. Paste it once per browser, or supply it once in the URL instead:

http://127.0.0.1:4317/?token=<credential>

To have Loom print that URL, run this on the host (loom start and loom status deliberately never print it):

loom open --print-url --port 4317

--port (and optional --host) are the address you'll browse at on the far device — your tunnel's local end. --host accepts only 127.0.0.1 (the default) or localhost, the two names the daemon serves the cockpit on. They are different browser origins, each with its own token, so stick to one. The URL goes to stdout and a live-credential warning to stderr; it's read from the same key file, so it adds no network surface. Don't paste it into chat or tickets.

Either way the browser keeps it and strips it from the address bar. It's stored per browser origin, so each URL you reach the cockpit by needs it once of its own. Treat it like a password: anything holding it can drive the full loopback API.

Why this is the default recommendation

With an SSH forward, the daemon's listening surface never changes — it stays bound to 127.0.0.1. There's no gateway token to mint, no TLS material to manage inside Loom, and no interface exposed for anyone to probe. The transport's own identity layer (your SSH keys) does the authenticating.

Two things never to do

Never point a proxy at the daemon's own port (4317 by default). On that port the class still follows the peer address: a request carrying X-Forwarded-*, Forwarded, Via, X-Real-IP or Tailscale-* headers is treated as remote whether or not proxy mode is configured. With no remote access configured, or on a route only local callers may use, it gets a 403 with code: "proxy-shaped-header" naming the header; with remote access configured it is simply a remote caller and needs the gateway token. But a proxy that rewrites Host to 127.0.0.1:4317 and adds none of them (nginx's default proxy_pass does exactly this) is indistinguishable from a local client and is served as loopback — the full local read surface, with no token. Point the proxy at proxyPort only. If you see a 403 with code: "proxy-shaped-header" (or, in every case, the daemon log's proxy-shaped header line), a proxy added one of those headers to a request aimed at the daemon's own port: point a reverse proxy at proxyPort, or exclude 127.0.0.1 and localhost via NO_PROXY if a local HTTP proxy is relaying a local client. Sessions Loom itself spawns already exclude 127.0.0.1, localhost and ::1 from HTTP proxies automatically, so that advice applies only to your own tools and browser outside Loom.

Never use Tailscale Funnel. A request carrying Tailscale-Funnel-Request is refused on every route of the proxy listener, but a Funnel would still put this listener on the public internet.

Three things to know before you turn it on

The remote bind is a second listener on its own port — loopback never changes. The daemon keeps answering on http://127.0.0.1:4317, plain HTTP, whatever you configure, so loom status, loom stop, loom open, every agent's tool connection and the http://127.0.0.1:4317 admin calls on this page keep working. The remote listener is separate: it binds remoteAccess.bindHost on remoteAccess.port (default: the daemon port + 1, so 4318), terminates TLS when remoteAccess.tls is set, and must use a different port from the daemon's. Remote clients dial <scheme>://<host>:<remote port>, where <host> is the bindHost (for a wildcard bind, any allowedHosts entry) and the scheme is https whenever remoteAccess.tls is configured — plain http only for a .ts.net tailnet bind with no TLS configured. If the remote listener can't open — no gateway token yet, TLS material that won't load, a wildcard bind without allowedHosts, a port clash, or a bind failure — the daemon logs exactly why and carries on loopback-only.

A wildcard bind needs allowedHosts. bindHost: "0.0.0.0" (or ::) listens on every interface, but a real client's Host is the address or name it dialled — never the literal 0.0.0.0 — and the DNS-rebinding guard matches Host exactly. List every hostname or IP your clients will use in remoteAccess.allowedHosts; a wildcard bind with an empty list does not open at all. It also works alongside a specific bindHost (a tailnet client may reach both the MagicDNS name and the 100.x address). Matching is exact and case-insensitive — no wildcards or suffixes — and 0.0.0.0, :: and loopback addresses are rejected as entries.

A browser's Origin must be the full remote origin — <scheme>://<allowed host>:<remote port>, the same scheme and port the client dialled — and only a request that actually arrives from a non-loopback address may present one. A loopback caller keeps the loopback-only rule.

What a remote token can reach

A remote request is deliberately limited to a read-and-steer surface: the read-only views, the answer/steer actions on an already-running session (answer a question, send input, stop, resume, end), and the live session sockets — the terminal stream (view-only to a remote peer: nothing but a repaint goes down it, steering goes through the governed REST input route, and a host shell is never reachable remotely, on that socket or through the REST input and stop routes), the companion chat stream, and a fleet-status feed. Everything else — the web app's own routes, vault and git writers, the internal control endpoints, the MCP mounts, and even the gateway-token admin itself — stays loopback-only by construction. A valid remote token can never mint, rotate, or revoke tokens over the wire; only the human at the local machine can. Remote requests are also rate-limited per IP and per token; repeated wrong-token attempts from one IP are throttled, never hard-locked, so a valid token is never blocked by someone else's failures on a shared IP; loopback traffic is exempt.

The companion chat stream is the one deliberate exception to "view-only": a remote token may send chat and audio on it, because that arrives through the companion's own governed inbound path rather than as a raw write to a terminal. Whether it should stay that way is an open question we haven't settled yet.