28allday
7d6e339dcb
Under tailscaled --tun=userspace-networking (no TUN device — the default in unprivileged containers), processes cannot dial tailnet addresses at all: inbound connections are proxied to loopback by tailscaled, but outbound 100.64.0.0/10 dials have no route. omarchy-send could receive on such boxes but never send, probe, or discover over the tailnet. New internal/tsproxy auto-detects this: when no local interface carries a tailnet address but a SOCKS5 proxy answers at localhost:1055 (the conventional --socks5-server address), tailnet-bound connections route through it. LAN traffic is never proxied; explicit HTTPS_PROXY/ HTTP_PROXY/NO_PROXY win over detection, restoring the env-var support the custom transports had silently dropped. Also guard NotePeer against the loopback trap the same proxying causes: inbound registers all appear to come from 127.0.0.1, and recording that over a peer's routable address made a TUI "send" loop back to our own receiver while looking delivered. Live-verified from an omaterm container (userspace tailscaled): headless send discovered and messaged a tailnet peer with no env vars set. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| app | ||
| client | ||
| clipboard | ||
| config | ||
| dbg | ||
| discovery | ||
| notify | ||
| protocol | ||
| security | ||
| server | ||
| tailscale | ||
| theme | ||
| transfer | ||
| tsproxy | ||
| tui | ||