### System details

Lenovo ThinkPad X1 Carbon Gen 11 (Intel i7-1370P, Iris Xe), Omarchy 4.0.0-1, Tailscale 1.102.2

### What's wrong?

Connecting to a tailnet from the Tailscale bar widget can silently break **all** DNS. The panel still reports Connected. There is no way in the widget to accept subnet routes or stop using tailnet DNS.

This is the Linux default combo of `--accept-dns` (on) and `--accept-routes` (off). It is fine until the tailnet pushes nameservers that only exist on advertised subnet routes. Tailscale then rewrites resolvers to those addresses, the client cannot reach them, and every lookup fails — not just MagicDNS.

#### Steps

1. Install Tailscale from Omarchy (`Install → Service → Tailscale`).
2. Do **not** finish auth in the install terminal. First login is later, from the bar widget.
3. Join a tailnet that (a) overrides or split-DNS-points at internal nameservers and (b) advertises those networks from a subnet router.
4. Toggle Tailscale on in the widget.

#### What I saw

`tailscale debug prefs` after the widget connect:

- `CorpDNS: true` (`--accept-dns`)
- `RouteAll: false` (`--accept-routes`)

`tailscale status --json` `Health` (while the widget said Connected):

- `Tailscale can't reach the configured DNS servers. Internet connectivity may be affected.`
- `Some peers are advertising routes but --accept-routes is false`

A subnet router on the tailnet was advertising internal RFC1918 prefixes. The pushed DNS servers live on those prefixes.

`tailscale set --accept-routes` restored DNS. That is a valid choice for this machine; it should not be implicit for every Omarchy user.

#### Why this happens in Omarchy

The installer is the only path that passes `--accept-routes`:

```bash
sudo tailscale up --accept-routes
```

That command is also the login gate. If auth is skipped there, the pref is never written.

The widget then does a flagless `tailscale up` (`Model.js` `loginPlan`, `Service.qml` `loginOrUp`). On a fresh node that applies Linux defaults: accept DNS, refuse routes.

The widget parses `tailscale status --json` and ignores `Health`. It has no accept-routes or accept-dns control.

#### What I am not asking for

Please do **not** make `--accept-routes` the silent default on install or on first widget connect.

Accepting routes installs every advertised prefix into the routing table. That can be office/lab networks, or a range that overlaps the user's LAN. Users who never opted in should not get that path.

The installer already passing `--accept-routes` is the aggressive choice. Copying it into the widget would make that footgun more reliable, not more correct. Leaving routes off is the safer default. The bug is the silent DNS failure and the missing choice.

#### Suggested fix

1. Surface `Health` in the panel. Do not show a clean Connected state when the daemon says DNS is unreachable.
2. When health reports unreachable DNS **and** advertised routes with `--accept-routes` false, ask. Two explicit actions, neither silent:
   - **Accept subnet routes** → `tailscale set --accept-routes` (show the prefixes if possible)
   - **Don't use tailnet DNS** → `tailscale set --accept-dns=false` (keep local resolvers)
3. Later on/off should stay flagless `up`/`down` so an explicit choice is not reset.

That keeps Linux defaults, matches users who do not want unexpected routes, and still gives a one-click recovery for tailnets that need them.

A follow-up could stop the installer from blindly passing `--accept-routes` and use the same prompt (the panel is the better place: after login it can show the actual CIDRs).