Containerized gateway rejects host-networked containers when container ID is discoverable

[zarenner]

Summary

run_containerized.sh rejects host-networked gateway containers when it can determine its own Docker container ID. This breaks gh-aw generated workflows on Linux self-hosted runner containers with DinD.

Observed failure

Observed on a Linux self-hosted runner hosted inside an Ubuntu container with DinD.

Failure excerpt:

[INFO] Starting MCP Gateway in containerized mode...
[INFO] Running in containerized environment
[INFO] Container ID: 4f4979f2cb8e...
[INFO] Docker daemon is accessible
[INFO] Required environment variables are set
[INFO] Set DOCKER_API_VERSION=1.54 (server current)
[ERROR] Port 8080 is not exposed from the container
[ERROR] Add port mapping: -p <host_port>:8080

Current behavior

Current main still calls container-specific validation only when a container ID is discovered:

CONTAINER_ID=$(get_container_id) || true

if [ -n "$CONTAINER_ID" ]; then
    validate_port_mapping "$CONTAINER_ID"
    validate_stdin_interactive "$CONTAINER_ID"
    validate_container_config "$CONTAINER_ID"
    validate_log_directory_mount "$CONTAINER_ID"
fi

validate_port_mapping inspects .NetworkSettings.Ports and requires a HostPort:

local port_mapping=$(docker inspect --format '{{json .NetworkSettings.Ports}}' "$container_id" 2>/dev/null || echo "{}")

if ! echo "$port_mapping" | grep -q "\"${port}/tcp\""; then
    log_error "Port $port is not exposed from the container"
    log_error "Add port mapping: -p <host_port>:$port"
    exit 1
fi

if ! echo "$port_mapping" | grep -q '"HostPort"'; then
    log_error "Port $port is exposed but not mapped to a host port"
    log_error "Add port mapping: -p <host_port>:$port"
    exit 1
fi

This is incompatible with Docker host networking. For example:

docker create --entrypoint true --network host -p 18083:8080 ghcr.io/github/gh-aw-mcpg:v0.3.26

Docker reports:

WARNING: Published ports are discarded when using host network mode
NetworkSettings.Ports={}
HostConfig.PortBindings={"8080/tcp":[{"HostIp":"","HostPort":"18083"}]}
NetworkMode=host

So a host-networked gateway can never satisfy the .NetworkSettings.Ports / HostPort validation, even if -p is present.

Why this is environment-dependent

On some environments, such as Docker Desktop locally, get_container_id may fail and the script logs:

[WARN] Could not determine container ID

In that case the entire container-specific validation block is skipped and the gateway proceeds. On a Linux self-hosted runner container with DinD, the gateway can discover a Docker-style hex container ID, so it runs the incompatible port validation and exits.

That likely explains why smoke coverage can pass in some runner topologies but fail in this DinD setup.

Expected behavior

Host-networked containers should either:

1. be accepted by validation when HostConfig.NetworkMode=host, since published ports are intentionally absent from .NetworkSettings.Ports; or
2. produce guidance that this image no longer supports host networking and requires bridge networking plus -p.

Given github/gh-aw currently generates docker run -i --rm --network host for the MCP gateway, accepting NetworkMode=host seems like the compatibility-preserving fix.

Related upstream generator behavior

github/gh-aw current main still generates the gateway command with --network host in pkg/workflow/mcp_setup_generator.go:

containerCmd.WriteString("docker run -i --rm --network host")

Companion generator issue: github/gh-aw#39692

[zarenner]

Companion generator issue in github/gh-aw: github/gh-aw#39692

[github-actions]

🤖 This is an automated response from Repo Assist.

Good find! I've confirmed the root cause and opened a fix.

Root cause (run_containerized.sh, validate_port_mapping):

Docker sets NetworkSettings.Ports={} for host-networked containers because published ports are discarded — they're meaningless with --network host. The validation checks .NetworkSettings.Ports for the port key and a HostPort entry; both are always absent for host-networked containers, so the check always fails.

# This returns {} for --network host containers:
docker inspect --format '{{json .NetworkSettings.Ports}}' "$container_id"
# The actual binding is in HostConfig.PortBindings, but even that doesn't matter
# because on host networking the port is simply available on the host interface.

The check is skipped on Docker Desktop because get_container_id often fails there, which explains the topology-dependent behaviour described in the issue.

Fix: I've opened [Repo Assist] PR #7684 which detects HostConfig.NetworkMode=host before the port mapping check and returns early with an informational log. Bridge-networked containers are unchanged.

The companion generator issue in github/gh-aw (to stop emitting --network host) is a separate but related concern — once the generator switches to bridge networking the validation will work correctly as-is.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• proxy.golang.org

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "proxy.golang.org"

See Network Configuration for more information.

Generated by Repo Assist · 945.8 AIC · ⊞ 50.1K · ◷
_{Comment /repo-assist to run again}

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@851905c06e905bf362a9f6cc54f912e3df747d55