agent-container: GITHUB_PATH entries merged into AWF_HOST_PATH; verify chroot PATH resolution for setup-* installed tools (e.g., [Content truncated due to length]

[lpcox]

Problem

Tools installed by GitHub Actions setup-* actions (e.g., astral-sh/setup-uv, actions/setup-node, ruby/setup-ruby) add their bin directories to $GITHUB_PATH. Inside the AWF agent chroot, these tools resolve as command not found unless invoked via absolute path, even though they work fine in pre-agent workflow steps.

Example: uv run ... → bash: line 1: uv: command not found inside AWF; absolute path invocation in the same run works.

Context

Original report: github/gh-aw#21144

AWF has a mechanism to handle this: src/docker-manager.ts:163–210 (readGitHubPathEntries() and mergeGitHubPathEntries()) reads the $GITHUB_PATH file and merges its entries into AWF_HOST_PATH before composing the agent environment. The containers/agent/entrypoint.sh chroot PATH logic then uses AWF_HOST_PATH to build the final PATH inside the chroot.

The issue may be:

1. The fix was merged after v0.60.0 (the version in the report) and is not yet verified against the setup-uv case.
2. The $GITHUB_PATH file may not be set in certain runner configurations (e.g., self-hosted runners that do not set GITHUB_PATH).
3. The entrypoint's chroot PATH construction (containers/agent/entrypoint.sh) may not correctly translate host paths under /home/runner/... to their chroot equivalents under /host/home/runner/....

Root Cause

src/docker-manager.ts:557–565:

const githubPathEntries = readGitHubPathEntries();
environment.AWF_HOST_PATH = mergeGitHubPathEntries(process.env.PATH, githubPathEntries);

This only runs when GITHUB_PATH env var is set AND the file exists. On some self-hosted runners, GITHUB_PATH may not be set as a process env var, causing readGitHubPathEntries() to return [] and the setup-uv path to be absent from AWF_HOST_PATH.

The entrypoint then constructs the chroot PATH from AWF_HOST_PATH, prefixing each entry with /host. If setup-uv installs uv to /home/runner/.local/bin, that becomes /host/home/runner/.local/bin in the chroot — correct only if the host home is mounted there.

Proposed Solution

1. Add debug logging in readGitHubPathEntries() (src/docker-manager.ts:163) when GITHUB_PATH is unset or the file is missing, so the issue is visible with --log-level debug.

2. Verify end-to-end with setup-uv: write an integration test (or smoke test in .github/workflows/) that:

   • Runs astral-sh/setup-uv before the AWF step
   • Confirms uv --version succeeds inside the AWF agent

3. Fallback: if GITHUB_PATH env var is not set but $PATH already contains the tool's directory (because the runner pre-sets it), ensure AWF_HOST_PATH includes those entries.

4. Document in README.md or docs/environment.md that $GITHUB_PATH-based tool installations are automatically available inside the AWF chroot, and note the minimum AWF version where this was introduced.

Generated by AWF Issue Auditor · ◷

[github-actions]

👋 Hello! I noticed this issue might be related to an existing issue:

• Tools installed by pre-AWF setup steps (setup-ruby, setup-dart) may not be visible in chroot #1356 — Tools installed by pre-AWF setup steps (setup-ruby, setup-dart) may not be visible in chroot (closed as completed on 2026-03-23)

Both issues describe the same root cause: setup-* actions add tool paths to $GITHUB_PATH, but those entries may not propagate correctly into the AWF agent chroot's PATH. #1356 was closed as completed, which aligns with the context in this issue (the fix exists in src/docker-manager.ts via readGitHubPathEntries()/mergeGitHubPathEntries()).

This issue appears to be a follow-up/verification task — confirming the fix works for setup-uv and edge cases (e.g., self-hosted runners where GITHUB_PATH env var isn't set). If so, it may be worth referencing #1356 for historical context on the original fix.

This is an automated message from the issue duplication detector.

Generated by Issue Duplication Detector for issue #1464