Ran the OpenClaw 2.8.1 daemon on a fresh Ubuntu 22.04 host. Captured all open file descriptors for the main process post-initialization. The count is higher than expected for a "minimal surface" product.
Key points from the `/proc//fd` listing:
* 3 sockets bound to localhost (admin API, internal event bus, metrics)
* 1 UNIX domain socket for plugin IPC
* 2 open handles to shared libraries in `/opt/openclaw/modules/`
* 1 handle to a configuration file in `/etc/openclaw/conf.d/`
* 1 handle to a log file
* **Notable:** 1 open connection to `updates.openclawsecurity.com` over TLS (port 443). This was not documented in the deployment guide.
Full list:
```
lrwx------ 1 openclaw openclaw 64 Mar 10 10:15 0 -> /dev/null
lrwx------ 1 openclaw openclaw 64 Mar 10 10:15 1 -> /dev/null
lrwx------ 1 openclaw openclaw 64 Mar 10 10:15 2 -> 'socket:[425381]'
lrwx------ 1 openclaw openclaw 64 Mar 10 10:15 3 -> 'socket:[425382]'
lrwx------ 1 openclaw openclaw 64 Mar 10 10:15 4 -> 'socket:[425383]'
lrwx------ 1 openclaw openclaw 64 Mar 10 10:15 5 -> /opt/openclaw/modules/detection.so
lrwx------ 1 openclaw openclaw 64 Mar 10 10:15 6 -> /opt/openclaw/modules/network.so
lr-x------ 1 openclaw openclaw 64 Mar 10 10:15 7 -> /etc/openclaw/conf.d/default.yaml
lrwx------ 1 openclaw openclaw 64 Mar 10 10:15 8 -> /var/log/openclaw/audit.log
lrwx------ 1 openclaw openclaw 64 Mar 10 10:15 9 -> 'socket:[425390]'
lrwx------ 1 openclaw openclaw 64 Mar 10 10:15 10 -> 'socket:[425391]'
```
Netstat output for the TCP sockets:
```
tcp 0 0 127.0.0.1:9443 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:41701 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:9100 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.5:45732 34.120.177.94:443 ESTABLISHED
```
Port 9100 (metrics) is bound to all interfaces, not just localhost. The outbound TLS connection to 34.120.177.94 is active immediately. This expands the attack surface beyond the documented localhost-only admin API.
Has anyone else audited the runtime FD list? Is the outbound update check configurable, or is it a forced call-home?
The TLS connection to their update domain is the real gem here. So much for a fully "air-gapped" or "disconnected" deployment option, which is still listed in the features matrix.
Check if your config has the `disable_telemetry` flag set to `true`. In 2.7, that flag only stopped event submission, but the daemon still kept the heartbeat connection open for "patch availability checks." That's probably what you're seeing. Classic compliance checkbox behavior - they give you a setting that implies control but the underlying data flow never actually stops.
You've got three local sockets too. That's the internal bus architecture they moved to last year. It's why the process now needs to bind to ephemeral ports on loopback, instead of using a single socket file. Creates more noise for your audit trail, naturally.
audit what matters