-
Notifications
You must be signed in to change notification settings - Fork 314
Open
Description
Summary
We are using a gh-aw workflow with a documented GitHub Actions services: block for Postgres.
The service container starts successfully and publishes 5432:5432, but the AI agent running inside the default AWF sandbox cannot connect to it.
At the same time, the agent can successfully reach gh-aw's own host-backed HTTP services through host.docker.internal.
This makes the expected behavior unclear:
- Either GitHub Actions
services:are not meant to be reachable from the AWF agent. - Or they are meant to be reachable, but there is a networking bug or missing documentation.
Repro shape
engine:
id: copilot
env:
POSTGRES_HOSTNAME: host.docker.internal
services:
postgres:
image: postgres:15
ports:
- 5432:5432
env:
POSTGRES_USER: app
POSTGRES_PASSWORD: app
network:
allowed:
- defaults
- host.docker.internalApplication config was also set to use POSTGRES_HOSTNAME, so this was not a localhost misconfiguration.
Observed behavior
Service startup succeeds
docker create ... -p 5432:5432 ... postgres
5432/tcp -> 0.0.0.0:5432
postgres service is healthy.
host.docker.internal is allowed and usable for gh-aw infrastructure
Configuring HTTP MCP backend: mcpscripts, url=http://host.docker.internal:3000
Successfully connected ... url=http://host.docker.internal:3000
Configuring HTTP MCP backend: safeoutputs, url=http://host.docker.internal:3001
Successfully connected ... url=http://host.docker.internal:3001
Postgres is still unreachable from the AWF agent
PG::ConnectionBad: connection to server at "172.17.0.1", port 5432 failed: Connection timed out
Agent probes showed:
- localhost:5432 -> connection refused
- host.docker.internal:5432 -> timed out
- 172.30.0.x:5432 -> connection refused
Docs checked
Documented:
services:is supported and shown with a Postgres example:
https://github.github.com/gh-aw/reference/frontmatter/- agents run in a containerized sandbox in GitHub Actions:
https://github.github.com/gh-aw/reference/faq/ network.allowedsupports custom domains likehost.docker.internal:
https://github.github.com/gh-aw/reference/network/
Strongly implied by docs/source:
- gh-aw uses
host.docker.internalfor host-backed services when the agent sandbox is enabled - gh-aw rewrites
localhosttohost.docker.internalfor MCP HTTP services in sandboxed runs
What we could not find:
- any doc or example explaining whether a database started via
services:is expected to be reachable from the AWF agent - any Postgres-specific example showing the supported address pattern from inside the AWF sandbox
Question
What is the intended behavior here?
- Are GitHub Actions
services:expected to be reachable from the AWF agent? - If yes, what is the supported address pattern?
- If no, should the docs explicitly say that DB-backed validation must run in deterministic
steps:or separatejobs:outside the agent sandbox? - If this should work, is this a bug where
host.docker.internalworks for gh-aw MCP HTTP services but not for host-published TCP services like Postgres?
Requested outcome
Any of these would resolve the ambiguity:
- Confirm the supported configuration for Postgres access from AWF.
- Confirm this is not supported and document the recommended pattern.
- Fix the networking behavior if published service ports are supposed to be reachable from the AWF agent.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Type
Fields
Give feedbackNo fields configured for issues without a type.