## Issue Report: Web service hangs when host IP is in 172.x.x.x range

[rhinoceros]

Question

Issue Report: Web service hangs when host IP is in 172.x.x.x range

Problem Description

The opencode web service fails to respond (connection hangs) when the host machine belongs to a 172.x.x.x network (e.g., standard private B-class subnets). While the container starts without errors, curl <host-ip>:4096 never completes.

Root Cause Analysis

The issue stems from the IP filtering logic in the getNetworkIPs function:

// From packages/opencode/src/cli/cmd/web.ts
// Skip Docker bridge networks (typically 172.x.x.x)
if (netInfo.address.startsWith("172.")) continue

This logic incorrectly assumes that all 172.* addresses are internal Docker bridge networks. However, many enterprise and cloud environments use the 172.16.0.0/12 range for actual physical or virtual host networking. By skipping these, the application may fail to identify the correct interface to bind to or advertise.

Proposed Fixes / Workarounds

1. (Recommended) Immediate Workaround: Use Host Networking

To bypass the container's internal bridge and the IP filtering logic, run the container using the host's network stack. Note that -p is not used in this mode.

docker run -d \
   --restart unless-stopped \
   --name opencode \
   --network host \
   -v $(pwd)/data:/home/opencode \
   -v $(pwd)/workspace:/home/opencode/workspace \
   -e HOME=/home/opencode \
   ghcr.io/anomalyco/opencode:1.2.15 \
   web --hostname 0.0.0.0 --port 4096 --print-logs --log-level DEBUG

2. Potential Source Code Fix

The filtering logic should be more specific, targeting only the default Docker bridge subnet (usually 172.17.0.0/16) or, better yet, allowing a CLI flag to override the IP detection entirely.