Verification
AI disclosure: Drafted with Pi using OpenAI GPT-6-sol. Local investigation and command execution were AI-assisted. I will answer maintainer questions myself without AI/LLM assistance.
Provide a detailed description of the proposed feature
Could Homebrew pass each Ruby load-path entry with its own -I option when launching sandbox workers, rather than combining $LOAD_PATH into a single colon-separated argument?
brew upgrade fails during bottle extraction on a managed Apple Silicon Mac running SentinelOne. SentinelOne appears to interpret the combined -I argument as one filesystem path and blocks execution when it exceeds 1,024 characters.
This is a compatibility request, not a claim that Ruby or macOS imposes this argument-length limit.
Environment
- Homebrew:
7.0.6-42-gddc6726
- macOS:
26.3.1 (25D2128), Apple Silicon
- Homebrew portable Ruby:
4.0.7
- SentinelOne:
25.4.1
- Homebrew prefix:
/opt/homebrew
Proposed change
In Library/Homebrew/sandbox.rb, change Sandbox.ruby_command:
- [*HOMEBREW_RUBY_EXEC_ARGS, "-I", $LOAD_PATH.join(File::PATH_SEPARATOR),
+ [*HOMEBREW_RUBY_EXEC_ARGS, *$LOAD_PATH.flat_map { |path| ["-I", path] },
"--", HOMEBREW_LIBRARY_PATH/file, *args]Ruby supports repeated -I options. This preserves the load-path order without disabling sandboxing or modifying endpoint-security settings.
What is the motivation for the feature?
Multiple unrelated bottle upgrades fail with:
... /opt/homebrew/Library/Homebrew/sandbox_operation.rb extract`
was terminated by uncaught signal KILL.
The worker's combined -I argument contained 99 library directories and was 8,698 characters long.
Relevant SentinelOne log excerpt, with timestamps and process identifiers omitted:
[com.sentinelone.agent:esmanager]
Blocking execution of
/opt/homebrew/Library/Homebrew/vendor/portable-ruby/4.0.7/bin/ruby
because it contains path that is too long to check.
Other SentinelOne entries show attempts to scan the colon-separated directory list as a single file.
Isolation tests
On this machine:
- Ruby starts normally with a short
-I argument.
- A synthetic 1,024-character
-I argument succeeds; a 1,025-character argument results in SIGKILL.
- This happens with both
/usr/bin/ruby and Homebrew's portable Ruby, outside the Homebrew sandbox as well.
- Passing the original 99 directories as separate
-I arguments allows Ruby to start successfully.
These results are specific to the affected security configuration, not necessarily reproducible on an unmanaged Mac.
Validation
With this local patch, one previously failing formula upgrade completed successfully, including bottle extraction. The full remaining upgrade set has not been tested.
How will the feature be relevant to at least 90% of Homebrew users?
I do not expect this to directly affect 90% of users. It is a small compatibility improvement for managed machines running affected endpoint-security software, using supported Ruby syntax while preserving behavior for other users. I understand if maintainers consider this solely a third-party issue.
What alternatives to the feature have been considered?
- A SentinelOne vendor fix or an IT-approved policy adjustment would address the underlying blocking behavior, but is outside Homebrew's control.
- Maintaining the one-line local Homebrew patch works for the tested upgrade, but creates maintenance overhead as Homebrew updates.
- Disabling security controls is not proposed. The tested change leaves Homebrew sandboxing and endpoint-security settings intact.
Would maintainers accept a PR implementing this compatibility change?
Verification
brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.AI disclosure: Drafted with Pi using OpenAI GPT-6-sol. Local investigation and command execution were AI-assisted. I will answer maintainer questions myself without AI/LLM assistance.
Provide a detailed description of the proposed feature
Could Homebrew pass each Ruby load-path entry with its own
-Ioption when launching sandbox workers, rather than combining$LOAD_PATHinto a single colon-separated argument?brew upgradefails during bottle extraction on a managed Apple Silicon Mac running SentinelOne. SentinelOne appears to interpret the combined-Iargument as one filesystem path and blocks execution when it exceeds 1,024 characters.This is a compatibility request, not a claim that Ruby or macOS imposes this argument-length limit.
Environment
7.0.6-42-gddc672626.3.1(25D2128), Apple Silicon4.0.725.4.1/opt/homebrewProposed change
In
Library/Homebrew/sandbox.rb, changeSandbox.ruby_command:Ruby supports repeated
-Ioptions. This preserves the load-path order without disabling sandboxing or modifying endpoint-security settings.What is the motivation for the feature?
Multiple unrelated bottle upgrades fail with:
The worker's combined
-Iargument contained 99 library directories and was 8,698 characters long.Relevant SentinelOne log excerpt, with timestamps and process identifiers omitted:
Other SentinelOne entries show attempts to scan the colon-separated directory list as a single file.
Isolation tests
On this machine:
-Iargument.-Iargument succeeds; a 1,025-character argument results inSIGKILL./usr/bin/rubyand Homebrew's portable Ruby, outside the Homebrew sandbox as well.-Iarguments allows Ruby to start successfully.These results are specific to the affected security configuration, not necessarily reproducible on an unmanaged Mac.
Validation
With this local patch, one previously failing formula upgrade completed successfully, including bottle extraction. The full remaining upgrade set has not been tested.
How will the feature be relevant to at least 90% of Homebrew users?
I do not expect this to directly affect 90% of users. It is a small compatibility improvement for managed machines running affected endpoint-security software, using supported Ruby syntax while preserving behavior for other users. I understand if maintainers consider this solely a third-party issue.
What alternatives to the feature have been considered?
Would maintainers accept a PR implementing this compatibility change?