Description
Description of the bug:
Right now, if you want to use a remote cache for Bazel, and you are on a machine that has no non-proxied network access, that machine must expose both a TCP and a Unix domain socket endpoint; the former for dependency downloads, the latter for --remote_proxy. This is troublesome. (And fwiw, this is currently the case on Claude Code for the Web, which also runs afoul of a long-standing issue where Bazel does not like HTTPS proxies with credentials—Anthropic, for whatever reason, uses a JWT credential in its HTTPS_PROXY setup.)
This ticket tracks reducing the scope of the proxy challenge from "Unix domain socket plus TCP" to either "just Unix domain socket" or "just TCP."
Which category does this issue belong to?
No response
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Start a new Claude Code for the Web session against any project that uses Bazel and try to build or test anything.
Which operating system are you running Bazel on?
Linux
What is the output of bazel info release?
release 8.4.2
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse HEAD ?
git@github.com:mrdomino/bazel
b1630eedbe79a7487a79dc4b7f75d27b22e3c0ab
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
The Claude Code for the Web environment is bonkers. E.g., they put *.googleapis.com in their no_proxy, so once you get to the “Bazel remote cache” part of the maze, you’re liable to spend hours trying to figure out why you’re not successfully circumventing that setting before you realize that the entire proxy configuration is just being completely ignored.