copilot --acp ignores --sandbox and sandbox.enabled; shell commands run unsandboxed #5089

Describe the bug

In ACP mode (copilot --acp), the local sandbox is never applied, even when the CLI is started
with --sandbox --experimental and settings.json has sandbox.enabled: true and
allowBypass: false. A shell write to a path in sandbox.userPolicy.filesystem.readonlyPaths
succeeds. The same COPILOT_HOME, policy, and prompt in -p mode are blocked by the OS sandbox.

Evidence from the two sessions:

session/new exposes the config options mode, model, reasoning_effort, agent and
allow_all. None of them is a sandbox option, so an ACP client has no other way to enable it.

Affected version

GitHub Copilot CLI 1.0.94-5.

Steps to reproduce the behavior

1. Create a git repo with a file tests\Locked.txt that contains original.

2. Create an empty COPILOT_HOME folder, copy your config.json into it (for auth), and add
   this settings.json, using the absolute path of the repo's tests folder:

   {
     "sandbox": {
       "enabled": true,
       "allowBypass": false,
       "userPolicy": {
         "filesystem": { "readonlyPaths": ["C:\\path\\to\\repo\\tests"] },
         "network": { "allowOutbound": true, "allowLocalNetwork": true }
       }
     }
   }

3. Control (-p): from the repo root, with COPILOT_HOME set to that folder, run:

   copilot -p "Use only the powershell tool. Run exactly: Set-Content tests\Locked.txt changed  then report the exit code and any error verbatim. Do not retry." --sandbox --experimental --allow-all-tools --log-level debug
   

   Result: exit code 1, Access to the path '...\tests\Locked.txt' is denied. The file still
   contains original.

4. ACP: with the same COPILOT_HOME and working directory, start
   copilot --acp --sandbox --experimental --log-level debug from an ACP client. Send
   initialize, then session/new, then a session/prompt with the same text. Approve the
   shell permission request with allow_once.

5. Result: the command exits 0, and tests\Locked.txt now contains changed.

6. Compare COPILOT_HOME\session-state\<id>\events.jsonl for the two sessions: -p records
   sandboxApplied:"true", while ACP records sandboxApplied:"false".

Expected behavior

ACP sessions apply the local sandbox in the same way as interactive and -p sessions when
--sandbox is passed or sandbox.enabled is true. If that isn't intended, ACP should expose
the sandbox as a session/new config option, or fail clearly at startup instead of running
unsandboxed.

Additional context

• OS: Windows 11, build 26300.9705, x64
• Terminal / shell: Windows Terminal, PowerShell 7. The ACP client is a small .NET app that
  talks JSON-RPC over stdio.
• --log-file isn't accepted by 1.0.94-5 (unexpected argument '--log-file'), so the debug
  logs come from COPILOT_HOME\logs. I can attach both logs if they're useful.
• Why it matters: ACP is the mode that lets an orchestrator stream progress, answer permission
  requests, cancel, and re-prompt in a single long-lived process. Without the sandbox there,
  the orchestrator has to choose between steering (ACP) and OS-enforced write limits (-p).
• Related:
  • skillDirectories setting from settings.json is not honored in ACP mode (copilot --acp) #4700 (settings.json skillDirectories isn't honored in ACP mode). This might be the same
    root cause: settings not reaching ACP sessions.
  • ACP: expose the model list as a category:model config option (session/new returns only mode and allow_all) #4880 (ACP session/new exposes only a few config options).