Summary
GOROOT is not present in the agent container's environment even when actions/setup-go runs as a step before Execute Claude Code CLI, despite awf being invoked with --env-all.
The security architecture spec §8.5 (Environment Variable Inheritance) explicitly states:
GOROOT explicitly captured after actions/setup-go (Go's trimmed binaries require it)
In practice, GOROOT is empty inside the container.
Example configuration
steps:
- name: Set up Go
id: setup-go
uses: actions/setup-go@4a3601121dd01d1626a1e23e37211e3254c1c06c # v6
with:
go-version-file: './go.mod' # use a value other than `'go.mod'` to prevent `gh aw compile` from dropping this `actions/setup-go` step as a duplicate of its internal one
cache: false
- name: Restore GOTOOLCHAIN=auto
run: echo "GOTOOLCHAIN=auto" >> $GITHUB_ENV
Observed behavior
After actions/setup-go runs on the runner and exports:
GOROOT=/opt/hostedtoolcache/go/<version>/x64
GOTOOLCHAIN=local
Inside the agent container:
GOROOT= ← empty, not forwarded
GOTOOLCHAIN=auto ← forwarded correctly (after overriding to auto via $GITHUB_ENV)
The awf invocation uses --env-all, so all runner env vars should be forwarded. GOTOOLCHAIN is forwarded but GOROOT is not.
Impact
The intended PATH fixup in the container entry command is silently skipped:
[ -n "$GOROOT" ] && export PATH="$GOROOT/bin:$PATH" || true
Because GOROOT is empty, the correct Go version is not prepended to PATH. The fallback find /opt/hostedtoolcache -maxdepth 4 -type d -name bin adds all Go versions to PATH, but in an uncontrolled order — which go resolves to an older pre-installed version rather than the one installed by actions/setup-go.
Correct version selection still works incidentally when GOTOOLCHAIN=auto is set (Go auto-downloads the right version), but the GOROOT-based mechanism is broken and the spec guarantee is not met.
Steps to reproduce
- Add
actions/setup-go as a step in a gh-aw workflow
- Run the workflow
- Inside the agent, run:
echo "GOROOT=${GOROOT}" — the value is empty
Expected behavior
GOROOT should be forwarded into the agent container as specified in §8.5, so that:
- The PATH fixup
$GOROOT/bin:$PATH correctly prepends the setup-go-installed version
- Go's runtime has a valid
GOROOT if needed (e.g. for trimmed binaries using runtime.GOROOT())
Environment
- gh-aw version: v0.65.7
- awf version: v0.25.13
🤖 This issue was filed by Claude Code (claude-sonnet-4-6).
Summary
GOROOTis not present in the agent container's environment even whenactions/setup-goruns as a step beforeExecute Claude Code CLI, despiteawfbeing invoked with--env-all.The security architecture spec §8.5 (Environment Variable Inheritance) explicitly states:
In practice,
GOROOTis empty inside the container.Example configuration
Observed behavior
After
actions/setup-goruns on the runner and exports:GOROOT=/opt/hostedtoolcache/go/<version>/x64GOTOOLCHAIN=localInside the agent container:
The
awfinvocation uses--env-all, so all runner env vars should be forwarded.GOTOOLCHAINis forwarded butGOROOTis not.Impact
The intended PATH fixup in the container entry command is silently skipped:
Because
GOROOTis empty, the correct Go version is not prepended to PATH. The fallbackfind /opt/hostedtoolcache -maxdepth 4 -type d -name binadds all Go versions to PATH, but in an uncontrolled order —which goresolves to an older pre-installed version rather than the one installed byactions/setup-go.Correct version selection still works incidentally when
GOTOOLCHAIN=autois set (Go auto-downloads the right version), but the GOROOT-based mechanism is broken and the spec guarantee is not met.Steps to reproduce
actions/setup-goas a step in a gh-aw workflowecho "GOROOT=${GOROOT}"— the value is emptyExpected behavior
GOROOTshould be forwarded into the agent container as specified in §8.5, so that:$GOROOT/bin:$PATHcorrectly prepends the setup-go-installed versionGOROOTif needed (e.g. for trimmed binaries usingruntime.GOROOT())Environment
🤖 This issue was filed by Claude Code (claude-sonnet-4-6).