Linux sandbox hangs silently when the host denies namespace creation; the override env var is undocumented

Version: 1.0.83 (behaviour first observed on 1.0.83-2, same requirement text on 1.0.83-5)

What happens

Since 1.0.83-2 the Linux sandbox restricts egress to the configured proxy and requires slirp4netns, iptables and /dev/net/tun. That path creates a network namespace. When the CLI runs inside an outer sandbox that denies unshare/setns, startup hangs. No error, no timeout, no log line.

A user reported it as a total hang after startup. The same user had seen MCP tool discovery time out on earlier builds, which we now believe was the same collision at lower severity.

Two changes make the collision worse than an error. 1.0.80 gave MCP tool discovery a 30 second default timeout, and 1.0.83-4 made server startup wait for the managed-settings fetch instead of racing it. Both turn a blocked network path into a stall rather than a failure.

Plain copilot on the same machine works. The failure needs an outer sandbox that both sets HTTP_PROXY/HTTPS_PROXY and blocks namespace creation.

Reproduction shape

1. Linux host with copilot 1.0.83.
2. Run it under any outer sandbox that exports HTTP_PROXY and HTTPS_PROXY and denies unshare and setns. A seccomp profile or a user namespace with CLONE_NEWNET disallowed both do it.
3. Start copilot. It never reaches the prompt and never exits.

We hit this with an outer sandbox we maintain. Any sandbox with those two properties should reproduce it.

What we found

COPILOT_CLI_SANDBOX_SUPPORT_OVERRIDE=unsupported makes startup skip the sandbox, and the CLI then works under the outer sandbox. The variable appears only in the native runtime binary. It is in no JS bundle and no documentation. We found it by reading the shipped artifact, which is not a discovery path we want to recommend to users.

Asks, most useful first

1. A documented way to tell the CLI that the host cannot sandbox. If COPILOT_CLI_SANDBOX_SUPPORT_OVERRIDE is the intended knob, documenting it is enough.
2. A bounded failure when namespace setup is denied: a timeout and a message that names the denied operation, instead of a silent hang.
3. Clarity on whether the CLI's sandbox is expected to work when the CLI already runs inside another sandbox, or whether the supported configuration is one sandbox only.

Happy to test a build, or to supply more detail on the outer sandbox's policy if that helps.

Disclosure, in the interest of transparency: this investigation and write-up were done with AI assistance. Every claim above was verified against the shipped 1.0.83 artifact before filing.

Reproduce the hang with HTTP_PROXY and HTTPS_PROXY set while unshare and setns are denied, then inspect the native runtime binary and CLI startup path around COPILOT_CLI_SANDBOX_SUPPORT_OVERRIDE. Done means the supported override is documented and denied namespace setup produces a bounded failure with an explanatory message rather than a silent stall.