Setup
NANOCLAW_EGRESS_LOCKDOWN=true, plus any host-local service agents are expected to reach — an ollama endpoint, a host-side bridge/proxy on a localhost port, anything addressed via host.docker.internal.
Problem
src/egress-lockdown.ts attaches the OneCLI gateway container to the --internal network under the alias host.docker.internal. Two consequences for agents on that network:
- The alias is hijacked. Anything in the container that resolves
host.docker.internal (the documented way to reach the host from Docker) now silently connects to the OneCLI gateway container instead of the host. Ports that happen to be open on the gateway answer with the wrong service; everything else connection-refuses.
- There is no route to the host at all.
--internal networks get no gateway, so host-published services (e.g. an ollama instance on :11434, host-side MCP bridges) become unreachable the moment lockdown turns on. Features that worked in the default-bridge configuration break with no error pointing at lockdown.
This makes lockdown all-or-nothing in practice: you can have egress control or host-local services, not both — and the failure mode is misdirected traffic rather than a clean error.
Suggestion
- Attach the gateway under its own alias (e.g.
onecli-gateway) and point the injected proxy config at that, instead of squatting on host.docker.internal.
- For host-local services, provide an explicit allowlisted relay: a small dual-homed forwarder container (one leg on the internal network, one on the default bridge with
--add-host to the real host-gateway) that relays only operator-listed ports. This keeps the no-internet invariant while restoring deliberate host access.
I run a variant of the forwarder approach in production (TCP relay, read-only, cap-drop, non-root, per-port allowlist) and can turn it into a PR if there's interest — filing as an issue first since it touches the lockdown architecture rather than being a point fix.
🤖 Generated with Claude Code
Setup
NANOCLAW_EGRESS_LOCKDOWN=true, plus any host-local service agents are expected to reach — an ollama endpoint, a host-side bridge/proxy on a localhost port, anything addressed viahost.docker.internal.Problem
src/egress-lockdown.tsattaches the OneCLI gateway container to the--internalnetwork under the aliashost.docker.internal. Two consequences for agents on that network:host.docker.internal(the documented way to reach the host from Docker) now silently connects to the OneCLI gateway container instead of the host. Ports that happen to be open on the gateway answer with the wrong service; everything else connection-refuses.--internalnetworks get no gateway, so host-published services (e.g. an ollama instance on:11434, host-side MCP bridges) become unreachable the moment lockdown turns on. Features that worked in the default-bridge configuration break with no error pointing at lockdown.This makes lockdown all-or-nothing in practice: you can have egress control or host-local services, not both — and the failure mode is misdirected traffic rather than a clean error.
Suggestion
onecli-gateway) and point the injected proxy config at that, instead of squatting onhost.docker.internal.--add-hostto the real host-gateway) that relays only operator-listed ports. This keeps the no-internet invariant while restoring deliberate host access.I run a variant of the forwarder approach in production (TCP relay, read-only, cap-drop, non-root, per-port allowlist) and can turn it into a PR if there's interest — filing as an issue first since it touches the lockdown architecture rather than being a point fix.
🤖 Generated with Claude Code