Agent sandbox PATH puts wrong Ruby first; `bundle exec` fails until agent manually re-prepends toolcache bin

[sg650]

Summary

Even with gh-aw-firewall#1359 and #1977 in place, the agent's bash sandbox doesn't see the Ruby version selected by ruby/setup-ruby first on PATH. The first bundle exec rubocop (or rspec) call hits a Ruby version mismatch, and the agent thrashes through rbenv/rvm/ls /opt/hostedtoolcache/Ruby/ until it figures out it has to manually prepend the right toolcache bin to PATH on every subsequent shell invocation.

Versions

• gh-aw: v0.72.1 (latest stable)
• gh-aw-firewall: v0.25.41 (awf-config.json → container.imageTag: "0.25.41")
• Engine: copilot, model claude-sonnet-4.6
• Setup: ruby/setup-ruby@v1.307.0, ruby-version: 4.0.4, bundler-cache: true

Reproduction

1. Workflow uses a shared step component that runs ruby/setup-ruby@v1 for Ruby 4.0.4.
2. In the host workflow shell, before the agent starts, a verify step prints:

   PATH=/opt/hostedtoolcache/Ruby/4.0.4/x64/bin:/usr/share/rust/.cargo/bin:/home/runner/.local/bin:/opt/pipx_bin:…
   which ruby:   /opt/hostedtoolcache/Ruby/4.0.4/x64/bin/ruby
   which bundle: /opt/hostedtoolcache/Ruby/4.0.4/x64/bin/bundle
   ruby --version:   ruby 4.0.4 …
   

   So ruby/setup-ruby is correctly setting $GITHUB_PATH and bundle resolves to 4.0.4 on the host.
3. Inside the agent's bash tool, the first bundle exec rubocop … returns a Ruby version mismatch error from bundler.
4. The agent spends 6+ tool calls diagnosing (rbenv versions, cat .ruby-version, ls /opt/hostedtoolcache/Ruby/).
5. Every successful Ruby command thereafter is prefixed with:

   export PATH="/opt/hostedtoolcache/Ruby/4.0.4/x64/bin:$PATH" && bundle exec …
   

Likely cause

The copilot harness command (from agent-stdio.log line 84) builds the sandbox PATH like this:

export PATH="${RUNNER_TEMP}/gh-aw/mcp-cli/bin:$PATH" && \
export PATH="$(find /opt/hostedtoolcache /home/runner/work/_tool -maxdepth 4 -type d -name bin 2>/dev/null | tr '\n' ':')$PATH"

That blunt find prepends every */bin directory it finds under hostedtoolcache (multiple Ruby versions, Python, Node, Go, etc.) in find traversal order, discarding the version ordering that ruby/setup-ruby already wrote to $GITHUB_PATH. Whichever Ruby find returns first wins — and it's not the one bundler-cache was populated against, so bundle exec errors out.

This appears to override, not augment, the propagated $GITHUB_PATH from PR #1359.

Evidence

• Host verify step output (above) confirms $GITHUB_PATH propagation is working at the workflow level.
• Agent stdio log line 84 shows the harness PATH-rebuild logic.
• Agent stdio log lines 269–379 show the manual export PATH=… prefix pattern repeating across ~15 subsequent shell calls.
• Agent reasoning trace: "The Ruby version mismatch means rubocop can't run."

Expected behavior

The harness should preserve the toolchain order set by $GITHUB_PATH / setup-* actions, e.g. by appending discovered hostedtoolcache bins after $PATH rather than prepending, or by skipping the find-prepend entirely when $GITHUB_PATH is non-empty.

Workaround currently in use

In our workflow prompt, we instruct the agent to manually prepend the toolcache bin on every Ruby command. This works but is wasteful (extra tokens, agent confusion on the first call) and doesn't generalize to other ecosystems where setup-* actions select a specific toolchain version.

Related

• gh-aw-firewall#1359 (propagate $GITHUB_PATH into chroot)
• gh-aw-firewall#1977 (related PATH/env propagation)

[lpcox]

🔗 AWF tracking issue: https://github.com/github/gh-aw-firewall/issues/github/gh-aw-firewall#3135

Generated by Firewall Issue Dispatcher · ● 8.1M · ◷

[pelikhan]

Please test in v0.74.2+