Context: A workflow's firewall domain allowlist includes localhost (for local MCP/tool use). AWF auto-detects the localhost keyword and automatically enables --enable-host-access. Separately, the gh-aw compiler (v0.82.x line) defaults the agent sandbox to network.isolation:true + topologyAttach: [...].
Problem: These two AWF modes are mutually exclusive at the CLI level:
[ERROR] ❌ --network-isolation is not yet supported with --enable-host-access.
[ERROR] Host access relies on host-level iptables, which network-isolation mode does not configure.
The agent step crashes immediately — before any tool call or model request is attempted.
Reproduction: gh-aw v0.82.9, AWF v0.27.31. Workflow allowlists localhost in its domain config; compiled output sets "isolation":true,"topologyAttach":["<gateway>"] in awf-config.json; AWF's own localhost auto-detection then adds --enable-host-access, and the process exits with code 1 before the harness even starts.
Related: we found the same underlying conflict via a different trigger (GOOGLE_API_KEY placed in engine.env also causes the compiler to emit network.isolation while a separate code path adds --enable-host-access). This localhost-allowlist trigger is likely more common and would affect any workflow that legitimately needs both localhost access and the default isolation topology.
Ask: either have the compiler avoid emitting network.isolation when it also detects it will auto-enable host access (pick one mode consistently), or teach AWF to support the combination (e.g. host-access via the isolated network's proxy rather than host iptables).
Context: A workflow's firewall domain allowlist includes
localhost(for local MCP/tool use). AWF auto-detects thelocalhostkeyword and automatically enables--enable-host-access. Separately, the gh-aw compiler (v0.82.x line) defaults the agent sandbox tonetwork.isolation:true+topologyAttach: [...].Problem: These two AWF modes are mutually exclusive at the CLI level:
The agent step crashes immediately — before any tool call or model request is attempted.
Reproduction: gh-aw v0.82.9, AWF v0.27.31. Workflow allowlists
localhostin its domain config; compiled output sets"isolation":true,"topologyAttach":["<gateway>"]in awf-config.json; AWF's own localhost auto-detection then adds--enable-host-access, and the process exits with code 1 before the harness even starts.Related: we found the same underlying conflict via a different trigger (
GOOGLE_API_KEYplaced inengine.envalso causes the compiler to emitnetwork.isolationwhile a separate code path adds--enable-host-access). Thislocalhost-allowlist trigger is likely more common and would affect any workflow that legitimately needs both localhost access and the default isolation topology.Ask: either have the compiler avoid emitting
network.isolationwhen it also detects it will auto-enable host access (pick one mode consistently), or teach AWF to support the combination (e.g. host-access via the isolated network's proxy rather than host iptables).