Sandbox RW path grants not honored by JVM processes spawned from Copilot CLI

Describe the bug

Summary

Sandbox path RW grants configured via /sandbox (e.g. ~/.m2/repository) are not honored by JVM/Java processes, even though the same path is fully writable for plain shell commands. Any Java-based tool (Maven, javac-compiled programs, etc.) fails with Operation not permitted on file/directory writes under a granted path, blocking real-world workflows like mvn clean compile.

Environment

• CLI version: 1.0.80
• OS: macOS (Darwin), aarch64
• Granted sandbox path: ~/.m2/repository (Read/Write)

Real-world impact

Running mvn clean compile in a multi-module Maven project fails identically — both the cyclonedx-maven-plugin and Maven core's own DefaultTrackingFileManager/DefaultUpdateCheckManager (writing resolver-status.properties for resolved dependency metadata under ~/.m2/repository/...) throw the same FileSystemException: Operation not permitted, even though the parent directories were freshly, successfully created by shell mkdir moments earlier in the same session.

Suspected root cause

The sandbox's file-access enforcement appears to differ by process/executable type rather than purely by path: shell built-ins (touch, mkdir) inherit the granted RW access, but JVM processes (java, and therefore javac, mvn) invoking sun.nio.fs.UnixFileSystemProvider (NIO FileChannel.open/Files.createDirectory) are denied on the identical path/grant.

Affected version

1.0.80

Steps to reproduce the behavior

1. In /sandbox, confirm ~/.m2/repository (or any path) is granted Read/Write.

2. From the CLI's shell tool, confirm plain shell operations succeed on that path:
   mkdir -p ~/.m2/repository/zz-test-dir && echo OK # succeeds
   touch ~/.m2/repository/zz-test-dir/file.txt && echo OK # succeeds

3. Compile and run a minimal Java program that writes a file under the same granted path via NIO:

    mkdir -p ~/.m2/repository/zz-test-dir
   

   import java.nio.channels.FileChannel;
   import java.nio.file.*;
   
   import static java.nio.file.StandardOpenOption.*;
   
   public class WriteTest {
       public static void main(String[] args) throws Exception {
           Path p = Paths.get(System.getProperty("user.home") + "/.m2/repository/zz-test-dir/javatest.properties");
           try (FileChannel ch = FileChannel.open(p, CREATE, WRITE)) {
               System.out.println("JAVA WRITE OK");
           }
       }
   }
   

   javac WriteTest.java && java WriteTest
   

4. Actual result:

Exception in thread "main" java.nio.file.FileSystemException: .../zz-test-dir/javatest.properties: Operation not permitted
   at java.base/sun.nio.fs.UnixFileSystemProvider.newFileChannel
   at java.base/java.nio.channels.FileChannel.open
   at WriteTest.main(WriteTest.java:7)

Expected behavior

"JAVA WRITE OK" printed.

Additional context

No response

Start by reproducing the contrast between shell writes and the Java NIO FileChannel.open example under a path granted through /sandbox. Trace the sandbox file-access enforcement for spawned JVM processes and compare it with shell commands. Done means the Java write succeeds and mvn clean compile can write under ~/.m2/repository without Operation not permitted.