Force-unset GEM_HOME/GEM_PATH/RUBYLIB in the harness scrub - #66
Open
JPDuchesne wants to merge 1 commit into
Open
JPDuchesne wants to merge 1 commit into
JPDuchesne wants to merge 1 commit into
Conversation
Bundler.original_env only undoes what bundler itself mutated; keys the harness exported before the dispatcher's bundler booted — shadowenv's GEM_HOME/GEM_PATH activating .ai-flow, dev's RUBYLIB — are recorded as "original" and were faithfully restored into every spawn. The leak made a /build agent's bundle install compile Ruby 4.0 native extensions into the harness's 3.3 gem home, breaking every later run on that machine (plans run 32146691480, origin-firing failure on dev#120). Co-authored-by: Cursor <cursoragent@cursor.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
HarnessEnv.scrubrelied onBundler.original_envto undo harness activation, but keys exported before the dispatcher's bundler booted — shadowenv'sGEM_HOME/GEM_PATHactivating.ai-flow, dev'sRUBYLIB— are recorded as "original" and were faithfully restored into every spawn.TOOLCHAIN_KEYScovered their siblings (GEM_ROOT,RUBY_ROOT) but not them.GEM_HOMEleak was handled. Unlike dev's own entrypoint whereGEM_HOME/GEM_PATHare legitimate user config (bin/dev: self-defending entrypoint — scrub foreign bundler activation before Ruby boots dev#94), at this spawn seam they can only be harness activation.env -uscrubbing (the anti-pattern the boundary scrub exists to prevent), and itsbundle installcompiled Ruby 4.0 native extensions into the harness's 3.3 gem home — breaking every later ai-flow run on that runner, including origin-firing on dev#120. The runner's gem dir has been repaired withgem pristine.Test plan
ENVwithBundler.original_envfor the three keys (the pre-bundler-export state the restore half cannot undo) and asserts the overlay force-unsets them; failed before the fix, passes aftersrb tcclean, RuboCop cleanMade with Cursor