github / github/copilot-cli

Docs present local sandbox capabilities (per-host filtering, cross-platform isolation) as working, but they do not — please align docs with actual behavior

Open
#3,861 1 comment 1 reaction 0 assignees View on GitHub
area:networking area:permissions
Dominant language
Shell
Stars
11.2k
Forks
1.9k
Avg merge
14h 16m
Merged PRs (30d)
6

Description

### Summary
The documentation and the `/sandbox` settings UI present capabilities as working that do not actually function. Per-host network filtering (`allowedHosts` / `blockedHosts`) is offered as a way to allow/block individual hosts, and the docs claim a "consistent isolation experience" across macOS, Linux, and Windows. In practice these do not hold, so users trust documented features, then waste time discovering they don't work. Please update the documentation to match actual behavior.

### What the docs say
- [Configuring local sandbox settings](https://docs.github.com/en/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings) describes host rules as a way to allow or block access to individual hosts when outbound connections are otherwise restricted, with no indication that this may not take effect.
- [About cloud and local sandboxes](https://docs.github.com/en/copilot/concepts/about-cloud-and-local-sandboxes) states local sandboxing delivers "a consistent isolation experience regardless of your operating system."

### Actual behavior
Per-host filtering (`allowedHosts` / `blockedHosts`) does not actually restrict traffic to/from individual hosts. This is confirmed in the sandbox backend source ([microsoft/mxc](https://github.com/microsoft/mxc)):

- **macOS (seatbelt backend).** The seatbelt profile builder cannot filter by hostname. When `allowedHosts` is set, it does not restrict to those hosts — it degrades to allowing **all** outbound. Source comment in `src/backends/seatbelt/common/src/profile_builder.rs`: *"Seatbelt only accepts `*` or `localhost` in `(remote ...)` filters — per-hostname filtering isn't possible, so allowedHosts degrades to allow-all outbound as a best-effort."* `blockedHosts` is rejected outright in `seatbelt_runner.rs`: *"macOS Seatbelt does not support per-host network filtering."* So a user who configures `allowedHosts` to limit egress actually gets unrestricted outbound.

- **Linux (bubblewrap backend).** With `allowOutbound: false`, configured host rules are dropped as a no-op. Runtime log (`~/.copilot/logs/process-*.log`): `[rust:sandbox_spawn] allowOutbound is false (no-op without outbound); dropping 1 allowedHosts and 0 blockedHosts.` The allowed host (`api.github.com`) is unreachable — DNS fails (`lookup api.github.com on 127.0.0.53:53: connection refused`).

- **Windows.** Separately, the sandbox fails to start commands at all on current builds (see #3849: `Experimental_CreateProcessInSandbox returned E_NOTIMPL`).

### Impact
Because the docs and UI advertise these features as functional, users rely on them and spend time troubleshooting capabilities that do not work as documented. On macOS this is also a security concern: configuring `allowedHosts` to narrow egress silently results in unrestricted outbound. The gap between documented capability and real behavior is the core problem.

### Request
Please update the documentation to reflect actual behavior:
1. State the real support status / limitations of `allowedHosts` / `blockedHosts` (currently they do not take effect; on macOS `allowedHosts` degrades to allow-all outbound).
2. Stop presenting a "consistent cross-platform isolation experience" while platforms such as Windows cannot run sandboxed commands at all.

### Environment
- Copilot CLI v1.0.64-0
- Per-host filtering behavior verified against microsoft/mxc backend source (macOS seatbelt, Linux bubblewrap); Linux behavior also reproduced at runtime. Windows failure per #3849.

### Related
- #3849 (Windows sandbox `E_NOTIMPL` — sandboxed commands fail to start)

Contributor guide

Open the contributing guide

Research direction

Review the "Configuring local sandbox settings" and "About cloud and local sandboxes" pages, then compare their claims with the cited mxc Seatbelt and bubblewrap behavior and related issue #3849. Done means the documentation accurately states the current host-filtering limitations and platform-specific sandbox support, including Windows command-start failures.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux, macos
Domain
documentation, operating-systems
Issue type
Documentation
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
62/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.