macOS sandbox blocks Gradle daemon connection despite local networking being allowed #5105

Describe the bug

Gradle cannot execute even an offline help task inside the Copilot CLI macOS sandbox when outbound and local networking are configured as allowed.

The Gradle daemon starts successfully and listens on localhost, but the Gradle client cannot connect to it:

java.net.SocketException: Operation not permitted

The identical command succeeds with the Copilot sandbox disabled. Restarting Copilot with the sandbox enabled does not resolve the failure.

Affected version

Copilot CLI 1.0.95; also observed on 1.0.93.

Steps to reproduce the behavior

1. On macOS, enable the Copilot CLI sandbox and allow both outbound and local networking. The configured network settings are:

   {
     "allowOutbound": true,
     "allowLocalNetwork": true,
     "allowedHosts": [],
     "blockedHosts": []
   }

   /sandbox policy reports outbound and local networking as allowed.

2. In a Gradle 9.1.0 wrapper project with Java 21 selected, ask Copilot to execute:

   ./gradlew --offline --no-daemon --console=plain --stacktrace help

3. Gradle launches a single-use daemon to honor the project's JVM settings. The daemon binds a localhost port, but the client connection fails with Operation not permitted, before any task executes.

4. Disable the Copilot sandbox and repeat the identical command. It succeeds, executing only help.

Expected behavior

When local networking is explicitly allowed, Gradle should be able to connect to its localhost daemon.

If that setting intentionally excludes host-loopback connections, the policy display should make this distinction clear and document a supported way to permit the required connection without disabling the entire sandbox.

Additional context

Environment: macOS 26.6.2, ARM64; Gradle wrapper 9.1.0; Java Amazon Corretto 21.0.6.7.1.

The command uses offline mode, so dependency downloads are not involved. --no-daemon still launches a single-use daemon in this project.

Kernel-confirmed denial

In one sandbox-enabled run, the daemon listened on 127.0.0.1:53774. The macOS kernel log recorded:

Sandbox: java(5913) deny(1) network-outbound remote:*:53774

Effective policy from a separate failing run

Copilot's debug log identified the generated policy used for the command. Its network section was:

{
  "network": {
    "egress": {
      "default": "deny"
    },
    "ingress": {
      "default": "allow",
      "hostLoopback": "deny"
    },
    "runtimeConfig": {
      "networkProxy": "http://127.0.0.1:55437"
    }
  }
}

In that run, the Gradle daemon listened on 127.0.0.1:55438, not the proxy port 55437.

This appears consistent with the client being denied a direct host-loopback connection despite allowLocalNetwork: true. Gradle's daemon protocol uses raw TCP, so the HTTP proxy cannot carry that connection.

Please investigate whether allowLocalNetwork is being mapped correctly to the effective macOS policy, or whether a separate supported host-loopback permission is required.

Related reports

• github/copilot-cli#4854: a Windows /sandbox policy display issue. Unlike that report, the display here says networking is allowed, while the generated policy and kernel denial demonstrate an actual blocked connection.
• github/copilot-cli#4516: JVM filesystem-grant failures on macOS, with a recent comment also describing remote-repository/proxy problems. This report concerns the local Gradle daemon connection, without dependency downloads.

Only sanitized excerpts are included here; no project source, credentials, or full conversation/debug logs are attached.