[BUG] macOS sandbox blocks JVM attach mechanism — Gradle/Mockito tests fail, sandboxed daemon contaminates terminal

Preflight Checklist

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

What's Wrong?

The sandbox blocks the JVM HotSpot attach mechanism by restricting file creation and Unix domain socket bind() in /var/folders/.../T/ (macOS user temp dir). This causes Mockito 5.x tests to fail with MockitoInitializationException when run via the Bash tool.

The Gradle daemon started under the sandbox persists after the command exits, so subsequent ./gradlew test runs from a regular terminal also fail — the sandboxed daemon is reused. This makes the failure look like a macOS/JDK issue rather than a sandbox issue. Running ./gradlew --stop from an unsandboxed terminal recovers.

Related: #39257 (same root cause for .NET/MSBuild). Also: #18545 (prior Gradle sandbox issue).

What Should Happen?

./gradlew test (and any command that uses JVM self-attach) should succeed from within Claude Code's Bash tool. The macOS user temp directory
(/var/folders/.../T/) is a standard, user-scoped location for temporary files and IPC sockets — the sandbox should allow file creation and Unix domain
socket binding there by default.

Error Messages/Logs

org.mockito.exceptions.base.MockitoInitializationException:
  Could not initialize inline Byte Buddy mock maker.
  It appears as if your JDK does not supply a working agent attachment mechanism.

  Caused by: java.lang.IllegalStateException: Could not self-attach to current VM using external process
  

  ByteBuddy attacher dump (from the forked attacher JVM):
  
  java.lang.reflect.InvocationTargetException
    at net.bytebuddy.agent.Attacher.install(Attacher.java:102)
    at net.bytebuddy.agent.Attacher.main(Attacher.java:64)
  Caused by: com.sun.tools.attach.AttachNotSupportedException:
    Unable to open socket file /var/folders/vj/.../T/.java_pid33312:
    target process 33312 doesn't respond within 10500ms or HotSpot VM not loaded
  

  The two-stage nature was confirmed by adding sandbox paths incrementally:
  - Adding only `allowWrite` for `/var/folders` → error changed from EPERM on `.attach_pid` file creation to 10.5s timeout waiting for `.java_pid` socket
  - Adding both `allowWrite` + `allowUnixSockets` for `/var/folders` → tests pass

Steps to Reproduce

1. Have a Java/Gradle project that uses Mockito 5.x (default with Spring Boot 3.x/4.x)
2. Run ./gradlew test from Claude Code's Bash tool
3. Tests fail with:

``
org.mockito.exceptions.base.MockitoInitializationException:
Could not initialize inline Byte Buddy mock maker.
...
Caused by: java.lang.IllegalStateException:
Could not self-attach to current VM using external process
``

1. Run ./gradlew test from a regular terminal — also fails (reuses the sandboxed daemon)
2. Run ./gradlew --stop then ./gradlew test from the terminal — passes (fresh daemon)

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.146

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Root Cause

The JVM attach API creates two artifacts in the macOS user temp dir (resolved via native confstr(_CS_DARWIN_USER_TEMP_DIR), typically
/var/folders/.../T/):

1. File .attach_pid<pid> — blocked because allowWrite doesn't include /var/folders
2. Unix domain socket .java_pid<pid> — blocked because allowUnixSockets doesn't include /var/folders

Both are created by grandchild processes (Gradle daemon → test JVM → ByteBuddy attacher) and both are required for the HotSpot attach API.

## Workaround

Add to ~/.claude/settings.json:

``json
{
"sandbox": {
"network": {
"allowUnixSockets": ["/var/folders", "/private/var/folders"]
},
"filesystem": {
"allowWrite": ["/private/tmp", "/var/folders", "/private/var/folders"]
}
}
}
``

Both /var/folders AND /private/var/folders are needed because /var symlinks to /private/var on macOS.

## Suggested Default Fix

The default macOS sandbox config should allow writes and Unix socket creation in the user's temp directory. Options:

• Allowlist /var/folders and /private/var/folders by default
• Or dynamically resolve the path via confstr(_CS_DARWIN_USER_TEMP_DIR)