Skip to content

[Repo Assist] fix(run_containerized): skip port mapping validation for host-networked containers - #7684

Merged
lpcox merged 2 commits into
mainfrom
repo-assist/fix-host-network-validation-7647-ac55ac2c319c2393
Jun 17, 2026
Merged

lpcox merged 2 commits into
mainfrom
repo-assist/fix-host-network-validation-7647-ac55ac2c319c2393

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

🤖 This PR is from Repo Assist, an automated AI assistant for this repository.

Root Cause

When a container is started with --network host, Docker discards published port mappings and sets NetworkSettings.Ports={}. The existing validate_port_mapping function checks .NetworkSettings.Ports for the port key and a HostPort value. Both checks fail for host-networked containers — even when -p flags are present — causing the gateway to exit with:

[ERROR] Port 8080 is not exposed from the container
[ERROR] Add port mapping: -p :8080

This is environment-dependent: on Docker Desktop the get_container_id call often fails, so the entire validation block is skipped and the issue is invisible. On Linux DinD runners the container ID is discoverable, so the bad validation fires.

Fix

Add a HostConfig.NetworkMode check at the top of validate_port_mapping. If the mode is host, log an informational message and return early — ports are directly accessible on the host interface and no mapping validation is needed. Bridge-networked containers are completely unaffected.

+    local network_mode
+    network_mode=$(docker inspect --format '{{.HostConfig.NetworkMode}}' "$container_id" 2>/dev/null || echo "")
+    if [ "$network_mode" = "host" ]; then
+        log_info "Host network mode detected: port $port is directly accessible on the host (no mapping required)"
+        return 0
+    fi

Trade-offs

  • No security impact: we're relaxing a startup check that was already skipped in many environments.
  • No false negatives: host-networked containers genuinely don't need port mapping; the check would always fail spuriously for them.
  • A follow-up could also skip validate_container_config checks that inspect NetworkSettings for host-networked containers if similar issues arise.

Closes #7647

Test Status

⚠️ Infrastructure note: proxy.golang.org is blocked by the environment firewall for this workflow run, preventing go build/go test from running. This is a pre-existing infrastructure constraint affecting all Repo Assist runs — see prior PRs for context. The change is confined to run_containerized.sh; bash -n run_containerized.sh confirms the script has valid syntax.

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

…ed containers

When a container is started with --network host, Docker sets
NetworkSettings.Ports={} because published ports are discarded.
The existing validate_port_mapping check inspects NetworkSettings.Ports
and fails with "Port N is not exposed from the container", making it
impossible to use the gateway image with host networking even when a
-p flag is present.

Fix: inspect HostConfig.NetworkMode before the port mapping check.
If the value is "host", skip the NetworkSettings.Ports validation
and log an informational message instead. Bridge-networked containers
are unaffected.

Closes #7647

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@github-actions github-actions Bot added automation bug Something isn't working repo-assist labels Jun 17, 2026
@lpcox
lpcox marked this pull request as ready for review June 17, 2026 14:52
Copilot AI review requested due to automatic review settings June 17, 2026 14:52

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates the containerized startup validation script to correctly handle Docker containers running with --network host, where Docker discards published port mappings and leaves .NetworkSettings.Ports empty.

Changes:

  • Detect HostConfig.NetworkMode=host in validate_port_mapping and skip port-mapping validation in that case.
  • Add explanatory comments and an informational log message for host-networked containers.
Show a summary per file
File Description
run_containerized.sh Skips port-mapping validation for host-networked containers to avoid false startup failures.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

  • Files reviewed: 1/1 changed files
  • Comments generated: 1

Comment thread run_containerized.sh
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
GitHub Advanced Security started work on behalf of lpcox June 17, 2026 15:00 View session
@lpcox
lpcox merged commit 087ca9d into main Jun 17, 2026
27 checks passed
@lpcox
lpcox deleted the repo-assist/fix-host-network-validation-7647-ac55ac2c319c2393 branch June 17, 2026 15:02
GitHub Advanced Security finished work on behalf of lpcox June 17, 2026 15:02
github-actions Bot added a commit that referenced this pull request Sep 28, 2026
… --validate-env

Closes #14053

Root cause: run_containerized.sh's validate_port_mapping already skips
port-mapping validation when a container's HostConfig.NetworkMode is
"host" (fixed in #7684 for #7647), but the Go validator that
run_containerized.sh now delegates to via --validate-env
(ValidateContainerizedEnvironmentForRuntime) never got the same
exception. Docker discards published port mappings for
--network host containers, so NetworkSettings.Ports is always empty
and CheckPortMapping always fails, regressing #7647 for anyone running
the gateway with --validate-env under host networking.

Fix: add sys.IsHostNetworkMode(containerID), which inspects
HostConfig.NetworkMode the same way run_containerized.sh's bash fix
does, and skip the NetworkSettings.Ports check in
ValidateContainerizedEnvironmentForRuntime when host networking is
detected, treating the port as satisfied. Bridge-networked containers
are unaffected.

Trade-offs: matches the existing bash-side exception exactly, so no
new security surface; a failure to determine the network mode falls
back to running the original port-mapping check with a warning
instead of erroring outright.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
lpcox added a commit that referenced this pull request Sep 28, 2026
… containers in --validate-env (#14065)

🤖 *This PR is from Repo Assist, an automated AI assistant for this
repository.*

Closes #14053

## Root Cause

`run_containerized.sh`'s `validate_port_mapping` already skips
port-mapping validation when a container's `HostConfig.NetworkMode` is
`"host"` (fixed in #7684 for #7647), but the Go validator that
`run_containerized.sh` now delegates to via `--validate-env`
(`ValidateContainerizedEnvironmentForRuntime` in
`internal/config/validation_env.go`) never got the same exception.

Docker discards published port mappings for `--network host` containers,
so `NetworkSettings.Ports` is always empty and `CheckPortMapping` always
fails — regressing #7647 for anyone using `--validate-env` under host
networking, exactly as reported in #14053.

## Fix

- Added `sys.IsHostNetworkMode(containerID)` in
`internal/sys/docker.go`, which inspects `HostConfig.NetworkMode` the
same way `run_containerized.sh`'s bash fix does.
- `ValidateContainerizedEnvironmentForRuntime` now checks host
networking first and skips the `NetworkSettings.Ports` validation when
detected, treating the port requirement as satisfied (matching the
bash-side behavior). Bridge-networked containers are completely
unaffected.
- If the network-mode check itself fails (e.g., docker inspect error),
we fall back to running the original port-mapping check and surface a
warning, so we never silently skip validation when we can't determine
the mode.

## Trade-offs

- No security impact: this exactly mirrors an existing, already-shipped
bash-side exception; it does not relax any check for bridge-networked
containers.
- No new dependencies.

## Test Status

✅ **Build**: `go build ./...` passes
✅ **Unit tests**: added `TestIsHostNetworkMode` in
`internal/sys/docker_test.go` (mirrors existing `TestCheckPortMapping`
coverage: empty ID, invalid ID, unreachable docker socket cases); `go
test ./internal/sys/... ./internal/config/...` passes
✅ **make agent-finished**: full pipeline (format, build, lint, all Go +
Rust guard tests) passes clean

> [!WARNING]
> <details>
> <summary>Firewall blocked 4 domains</summary>
>
> The following domains were blocked by the firewall during workflow
execution:
>
> - `example.com`
> - `nonexistent.local`
> - `slow.example.com`
> - `thishostdoesnotexist12345.com`
>
> To allow these domains, add them to the `network.allowed` list in your
workflow frontmatter:
>
> ```yaml
> network:
>   allowed:
>     - defaults
>     - "example.com"
>     - "nonexistent.local"
>     - "slow.example.com"
>     - "thishostdoesnotexist12345.com"
> ```
>
> See [Network
Configuration](https://github.github.com/gh-aw/reference/network/) for
more information.
>
> </details>

> Generated by [Repo
Assist](https://github.com/github/gh-aw-mcpg/actions/runs/36424956675) ·
copilot · auto · 370.9 AIC · ⊞ 18.7K ·
[◷](https://github.com/search?q=repo%3Agithub%2Fgh-aw-mcpg+%22gh-aw-workflow-id%3A+repo-assist%22&type=pullrequests)
> <sub>Comment <em>/repo-assist</em> to run again</sub>
>
<details>
<summary><sub>Add this agentic workflow to your repo</sub></summary>

To install this agentic workflow, run

```
gh aw add githubnext/agentics@851905c
```
</details>


<!-- gh-aw-agentic-workflow: Repo Assist, engine: copilot, model: auto,
id: 36424956675, workflow_id: repo-assist, run:
https://github.com/github/gh-aw-mcpg/actions/runs/36424956675 -->

<!-- gh-aw-workflow-id: repo-assist -->
<!-- gh-aw-workflow-call-id: github/gh-aw-mcpg/repo-assist -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

automation bug Something isn't working repo-assist

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

2 participants