Linux sandbox hangs silently when the host denies namespace creation; the override env var is undocumented
Chưa có ai nhận issue này.
- Ngôn ngữ chính
- Shell
- Star
- 11.2k
- Fork
- 1.9k
- Merge trung bình
- 14 giờ 16 phút
- Pull request đã merge (30 ngày)
- 6
Mô tả
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
- Linux host with
copilot1.0.83. - Run it under any outer sandbox that exports
HTTP_PROXYandHTTPS_PROXYand deniesunshareandsetns. A seccomp profile or a user namespace withCLONE_NEWNETdisallowed both do it. - 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
- A documented way to tell the CLI that the host cannot sandbox. If
COPILOT_CLI_SANDBOX_SUPPORT_OVERRIDEis the intended knob, documenting it is enough. - A bounded failure when namespace setup is denied: a timeout and a message that names the denied operation, instead of a silent hang.
- 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.
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Hướng nghiên cứu
Tái hiện hiện tượng treo khi HTTP_PROXY và HTTPS_PROXY được thiết lập trong lúc unshare và setns bị từ chối, sau đó kiểm tra binary runtime native và đường dẫn khởi động CLI liên quan đến COPILOT_CLI_SANDBOX_SUPPORT_OVERRIDE. Công việc được xem là hoàn tất khi override được hỗ trợ đã được ghi lại và việc thiết lập namespace bị từ chối sẽ thất bại trong thời gian hữu hạn kèm thông báo giải thích, thay vì âm thầm bị treo.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- linux, shell
- Lĩnh vực
- cli, operating-systems, security
- Loại issue
- Lỗi
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức độ hoạt động
- Sôi nổi
- Độ rõ ràng
- Khá rõ ràng
- Mức phù hợp với người mới
- 48/100