getting started

Reach it from your phone

The phone client is the same application, not a companion. It goes over your own tailnet with no relay in the path and no swe-mux account, because there is no swe-mux server for an account to live on.

#

Setting it up

  1. Install Tailscale on the host machine and on the phone, on the same tailnet.
  2. Leave the daemon running. It listens on loopback and on the machine's detected Tailscale address; muxd --local-only is how you stop it doing the second one.
  3. On the phone, open the machine's .ts.net hostname over HTTPS.
  4. Turn Use Tailscale DNS on, and leave Android's Private DNS off or automatic. The certificate is bound to the hostname, so the raw 100.x address cannot serve HTTPS at all.
  5. Install it to the home screen when the browser offers. It is a progressive web app, so it gets its own window and can receive push notifications.

It worked when the workspace renders on the phone with your Projects in it, and a terminal pane accepts input.

#

HTTPS is not optional for the microphone or the clipboard

Browsers restrict both outside a secure context. swe-mux puts Tailscale Serve on port 443 in front of the daemon for exactly this, and starts it at boot. Port 443 rather than the daemon's own port is deliberate: the daemon binds its port on the tailnet address directly for the plain-HTTP fallback, and a Serve on the same port would collide with it.

tailscale serve status        # confirm it proxies to the daemon's real port
#

Understand the access boundary before you leave it running

Tailscale policy is the entire access boundary. There is no separate swe-mux login, so any device your tailnet admits to that listener has terminal and code-execution authority on the host, equal to the account running the daemon.

Binding 0.0.0.0, a LAN interface, port forwarding, and Tailscale Funnel are unsupported configurations rather than discouraged ones. They put a terminal on a network that has no policy in front of it.

#

What parity means here

swe-mux has no feature that exists on the desktop and not on the phone. The only desktop-only code paths are hidden terminal pre-warming, the collapsed sidebar rail, and keyboard chords a phone cannot produce.

One session can be attached from several devices at once. Exactly one connection may write, and the terminal size is arbitrated rather than fought over, so the phone does not reflow the desktop out from under you. The phone renders a single-pane projection of the same workspace tree rather than a second layout.

#

Development servers, without a raw port

A local dev server your session started is proxied through the daemon's own URL, hot module reload included, so the phone never needs to reach a raw port on the host. Notes, files, and previews covers the Preview tab.