[BUG/UX] Sandbox network whitelist: No way to proactively configure domains, git operations fail without prompts

[0x1355]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Git commands pre-approved in settings fail silently with exit code 128 when sandbox is enabled, due to network restrictions blocking github.com. There's no prompt to whitelist the domain, and the /sandbox command doesn't provide a way to proactively add network allowlists.

What Should Happen?

Option A (Reactive prompts):
When pre-approved git command needs network access, show prompt:
Git push requires network access to github.com
[ Deny ] [ Allow Once ] [ Update Sandbox Configuration ]

Option B (Proactive configuration):
/sandbox command should provide UI to add network whitelists:
Network allowed domains:
• code.claude.com
• github.com [Add]

[Add new domain...]

Option C (Smart defaults):
Git-related commands should auto-whitelist common git hosting domains when pre-approved:

• github.com, *.github.com
• gitlab.com, *.gitlab.com
• bitbucket.org, *.bitbucket.org

Error Messages/Logs

Error: Exit code 128
error: could not write config file .git/config: Device or resource busy
fatal: could not set 'remote.origin.url' to xxx

Steps to Reproduce

1. Enable sandbox mode in .claude/settings.local.json:
   { "permissions": { "allow": [ "Bash(git push:*)", "Bash(git remote set-url:*)" ] } }
2. Run a git command that requires network access:
   git push

or

git remote set-url origin git@github.com:user/repo.git
3. Command fails with:
Error: Exit code 128
ssh: Could not resolve hostname github.com: Temporary failure in name resolution
fatal: Could not read from remote repository.
4. Try /sandbox command to add network whitelist
5. Unable to add domains proactively

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.0.37

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

Impact

• Broken workflow: Pre-approved git commands don't work as expected
• Poor UX: Silent failures without guidance on how to fix
• Security workaround: Users forced to disable sandbox entirely for git operations
• Documentation gap: Docs mention reactive prompts but they don't trigger

[ralf-dev16]

I'm experiencing a similar issue with Android/Gradle builds in the Claude Code web sandbox.

Use Case

Building an Android app with Gradle (that has complex transitive dependencies)

Problem (analysed by Claude)

Java's DNS resolver bypasses the sandbox proxy, causing all Gradle dependency resolution to fail with UnknownHostException, even when domains are added to the network allowlist.

Symptoms

• ✅ Works: curl https://repo1.maven.org - successful
• ✅ Works: wget https://plugins.gradle.org - successful
• ❌ Fails: ./gradlew build - java.net.UnknownHostException: repo1.maven.org: Temporary failure in name resolution

The proxy configuration appears to be working for curl/wget, but Java's built-in DNS resolver (used by Gradle/Maven) completely bypasses it and attempts direct DNS lookups, which are blocked by the sandbox.

Root Cause (analysed by Claude)

This appears to be a fundamental limitation of Java's HTTP client DNS resolution in restricted sandbox environments. Even with proxy settings configured (-Dhttp.proxyHost, etc.), certain artifact resolutions trigger DNS lookups that bypass the proxy.

Current Workaround

Using GitHub Actions for builds, which defeats the purpose of the sandbox for iterative development.

Request

This issue affects all Java/Gradle/Maven projects in the web sandbox. Would appreciate either:

• A way to force Java DNS resolution through the sandbox proxy
• Pre-configured Maven/Gradle dependency caches for common libraries
• Documentation if there's a known workaround

[deviantintegral]

Not only is git failing, but the gh command line tool doesn't work either.

Be careful about trying to make this work - if you specify invalid WebFetch permissions, the entire settings.json file may be ignored and sandboxing may be disabled, leading you to think your permission rule is actually working!

#12468

[ddworken]

Hi! Thank you for the feedback, we'll consider adding a UI to /sandbox to explicitly add WebFetch permission rules. But until then if you add a WebFetch rule to your permissions config, this will also allow the domain in the sandbox. See here for info on how to configure custom permissions rules.

[gwillen]

Hi! Thank you for the feedback, we'll consider adding a UI to /sandbox to explicitly add WebFetch permission rules. But until then if you add a WebFetch rule to your permissions config, this will also allow the domain in the sandbox. See here for info on how to configure custom permissions rules.

Just to make sure I understand -- this won't solve the problem with git/gh/gradle, right? Because the sandbox only permits DNS requests through the sandbox proxy, which they aren't using, so adding permission rules won't help?

[pthieu]

on v2.076: