## Bug description An MCP server started with `--network host` loses all outbound connectivity the next time ToolHive re-creates it, after an upgrade to ToolHive v0.30.1 or later (where network isolation became the default). Its tools can no longer resolve DNS or reach any host; a Google-based server, for example, starts returning `Unable to find the server at www.googleapis.com`. `--network host` and network isolation are mutually incompatible, but ToolHive silently applies both: it builds the DNS (dnsmasq) and egress (Squid) sidecars but attaches them only to the per-workload `internal` Docker network (no route out), so every DNS lookup and outbound connection from the server fails. The break is silent for anyone who never opted into isolation: a server that only ever set `--network host` inherits isolation on the next re-create and stops working, with no error at deploy time. ## Steps to reproduce From scratch, with any HTTP MCP image (isolation is now the default, so `--isolate-network=true` is shown only for clarity): ``` thv run --network host --isolate-network=true --name repro <http-mcp-image> # List each sidecar's attached networks. Both are on ONLY the internal network; # neither is joined to toolhive-external (the network with a route out), which a # healthy isolated server's sidecars are: docker inspect repro-dns --format '{{range $k,$v := .NetworkSettings.Networks}}{{$k}} {{end}}' # => toolhive-repro-internal docker inspect repro-egress --format '{{range $k,$v := .NetworkSettings.Networks}}{{$k}} {{end}}' # => toolhive-repro-internal # That internal network has no route out, so DNS from inside the sidecar fails: docker exec repro-dns nslookup example.com 1.1.1.1 # => nslookup: can't connect to remote host (1.1.1.1): Network unreachable ``` ## Expected behavior ToolHive should detect the incompatible combination (isolation on together with a custom network mode: `--network host`, and by the same code path `--network none`) instead of silently starting a workload whose isolation is both broken (sidecars have no route out) and illusory (a host-networked container is not forced through the egress proxy). The right response depends on how isolation came to be enabled: - Isolation is on only because it is now the default (the user passed `--network host` but never `--isolate-network`): disable isolation for that workload and emit a warning. This keeps pre-existing host-mode servers working across the default flip instead of silently breaking them on the next re-create. - The user explicitly passed both `--network host` and `--isolate-network=true`: fail fast with an explanatory error, since that is a genuinely contradictory request. Either way, ToolHive should never report a workload as successfully started when its isolation is non-functional. ## Actual behavior `thv run` succeeds, `thv list` shows the server `running`, and no warning about the incompatible configuration is emitted; the breakage surfaces only at the first outbound call. Running the reproduction above (ToolHive v0.34.0, macOS/OrbStack): both sidecars come up attached only to `toolhive-<name>-internal`, never `toolhive-external`, while healthy default-mode servers on the same host (e.g. atlassian, gitlab) have both sidecars dual-homed on `toolhive-<name>-internal` and `toolhive-external`; and `nslookup` from inside the DNS sidecar returns `Network unreachable`. The report originated from a `google-workspace` server (runconfig `isolate_network: true` + `network.mode: host`) whose tools returned `Unable to find the server at www.googleapis.com` after such a re-create. ## Environment (if relevant) - ToolHive v0.34.0 (also on `main` at `709c918ae`). The regression dates to PR #5583 ("Default network isolation to on for local MCP servers"), merged 2026-06-23, first released in v0.30.1; every release since is affected. - Observed on macOS/OrbStack. The sidecar wiring is set in Go, so it is backend-independent. The break is not macOS-only: on Linux Docker Engine (Ubuntu 24.04, Docker 29.6.1) I confirmed the two preconditions that make it bite: a `--network host` container honors an injected `--dns` (it lands in the container's resolv.conf, so host networking does not exempt it), and a Docker `internal` network has no route out (a container on it gets `Network unreachable`). ## Additional context Root cause, in `DeployWorkload` (`pkg/container/docker/client.go`, `main` @ `709c918ae`): - The sidecars' shared endpoint config is seeded with only the internal network (220-223). `toolhive-external` (the one with a route out) is added and created only for the default modes `""`/`bridge`/`default` (226-233); a custom mode like `host` hits the `else` and is skipped (234-237). - But sidecar creation is gated only on `isolateNetwork` (240), not on the network mode, so in host mode it still runs and hands the sidecars the endpoint config that lacks `toolhive-external` (239-277). The internal network is created with `internal=true` (the `true` arg at 245 -> `NetworkCreateOptions{Internal: internal}` at 1176), which has no route off-box. - `addEgressEnvVars` (277, defined 1596-1609) also injects `HTTP(S)_PROXY = http://<name>-egress:3128` regardless of mode. Even if the sidecars were wired to `toolhive-external`, isolating a host-networked server would be illusory: `createMcpContainer` (1567-1586) leaves its endpoint config empty and lets `NetworkMode: host` (1539) stand, so the server is on no toolhive bridge, and the `http://<name>-egress:3128` proxy name resolves only via bridge embedded DNS, which a host-networked container does not use. So the resolution is to not isolate a host-networked workload, not to also wire the sidecars out. (On OrbStack, `docker network connect toolhive-external <name>-egress` and `<name>-dns` restored connectivity live, but it does not survive a re-create.) Not a duplicate: searched open/closed issues (isolate-network, host isolation, toolhive-external, egress/DNS sidecar); the closest are #5640 (`--allow-docker-gateway` / `host.docker.internal`, a different mechanism) and #1863 (whether to offer `--network host` at all). Neither covers host mode plus default isolation orphaning the sidecars.