--host refuses 0.0.0.0
--host accepts one concrete local interface address; 0.0.0.0 is a wildcard and is rejected, so a LAN or container setup that expects it fails at boot.
The refusal is a policy, not a bug: binding every interface is how a local tool ends up on a public network by accident.
The error, verbatim
It rejects the wildcard address when the profile boots, before the UI is served.
Why people hit it, most likely first
Copying a container or reverse-proxy recipe that assumes 0.0.0.0 works for every server.
Trying to reach the UI from a phone on the LAN and guessing the wildcard instead of the machine address.
Running inside a container where the interface address is not known when the command is written.
The fix
Pass the address you actually want to bind, and add it as a trusted host if the UI will be opened from another device.
dsh web --host 192.168.1.20 --port 8080 --no-open
dsh web --host 192.168.1.20 --port 8080 --trusted-host 192.168.1.20:8080If that does not settle it
Inside a container, resolve the interface at start: --host $(hostname -i) in the CMD line, not a hard-coded value.
If the UI loads but its API calls are refused, that is the trusted-host fence, not the bind address — add --trusted-host.
Common questions
Is there a flag to allow wildcards?
No. The check rejects wildcard literals by design; bind a specific interface instead.
How do I find the right address?
ipconfig on Windows, ip -4 addr show on Linux; pick the adapter on the same network as the client.