Codex uruchamia kod – i potrzebuje sandbox, żeby ten kod nie narobił szkód. Każda platforma ma inne mechanizmy izolacji. Oto co musisz wiedzieć o Windows, macOS i Linux.
Sandbox to pierwsza linia obrony. Nawet jeśli Codex dostanie złośliwe instrukcje (przez prompt injection lub niezaufany kod), sandbox ogranicza co może faktycznie zrobić.
- Porównanie platform
- macOS: Seatbelt policies
- Linux: Landlock + seccomp
- Windows: WSL recommended
- Docker: container-level isolation
- Tryby sandbox w config.toml
- Troubleshooting
Porównanie platform
| Feature | macOS | Linux | Windows Native | WSL |
| Sandbox maturity | Full | Full | Experimental | Full |
| Filesystem isolation | Seatbelt | Landlock | Limited | Landlock |
| Syscall filtering | Seatbelt | seccomp | – | seccomp |
| Network blocking | ✓ | ✓ | Partial | ✓ |
| Protected paths (.git, .codex) | ✓ | ✓ | ✓ | ✓ |
| Recommended for production | ✓ | ✓ | – | ✓ |
Praktyczny wniosek: Linux i macOS mają pełne, dojrzałe sandboxing. Na Windows używaj WSL – native sandbox jest eksperymentalny.
macOS: Seatbelt policies
Na macOS Codex używa Seatbelt – tego samego mechanizmu sandboxingu, który chroni aplikacje w App Store. Apple rozwija go od ponad dekady.
Co Seatbelt blokuje:
- Dostęp do plików poza workspace
- Połączenia sieciowe (w trybie workspace-write)
- Uruchamianie procesów systemowych
- Dostęp do Keychain i innych wrażliwych zasobów
- Montowanie dysków
- Modyfikacja preferencji systemowych
Instalacja standardowa (npm i -g @openai/codex) automatycznie konfiguruje sandbox. Nie musisz nic robić – Seatbelt działa out of the box.
Wymagania:
- macOS 12 (Monterey) lub nowszy
- Full Disk Access dla terminala (System Settings → Privacy & Security)
- Xcode Command Line Tools (
xcode-select --install)
Weryfikacja:
codex doctor
# Pokaże: Sandbox: Seatbelt (active)Linux: Landlock + seccomp
Linux oferuje najpotężniejszą izolację przez kombinację dwóch mechanizmów:
| Mechanizm | Co robi | Kernel | Typ ochrony |
| Landlock | Ogranicza dostęp do plików i katalogów | 5.13+ | Filesystem |
| seccomp | Filtruje wywołania systemowe | 3.5+ | Syscalls |
| bubblewrap | Pełna izolacja namespace (fallback) | any | Container-like |
Codex automatycznie wykrywa dostępne mechanizmy i używa najsilniejszego.
Co Landlock + seccomp blokują:
- Odczyt/zapis plików poza workspace
- Syscalle:
mount,ptrace,reboot,swapon - Tworzenie device nodes
- Ładowanie modułów kernel
- Zmianę ustawień sieciowych
Dla starszych kerneli (bez Landlock):
# Sprawdź wersję kernel
uname -r
# Jeśli < 5.13, zainstaluj bubblewrap
sudo apt install bubblewrap # Debian/Ubuntu
sudo dnf install bubblewrap # Fedora/RHEL
# Codex automatycznie go wykryje
codex doctorBubblewrap daje izolację porównywalną z kontenerem Docker, ale bez overhead. Używa Linux namespaces do utworzenia mini-kontenera.
Tip dla serwerów: Na VPS/cloud VM (Ubuntu 22.04+, Debian 12+, RHEL 9+) masz Landlock out of the box. Sprawdź: cat /sys/kernel/security/lsm | grep landlock
Windows: WSL recommended
Na Windows masz dwie opcje – i jedna jest zdecydowanie lepsza:
WSL (rekomendowane):
# Zainstaluj WSL2 z Ubuntu
wsl --install
# W WSL terminal:
npm i -g @openai/codex
codex doctorWSL2 to pełny Linux kernel, więc dostajesz Landlock + seccomp – identyczną ochronę jak na native Linux.
Native Windows (eksperymentalne):
Codex ma wsparcie dla natywnego Windows, ale sandbox jest znacznie ograniczony:
| Feature | Native | WSL |
| Filesystem isolation | Partial | Full (Landlock) |
| Syscall filtering | – | Full (seccomp) |
| Network blocking | Partial | Full |
| Production ready | No | Yes |
Native Windows sandbox nie jest tak dojrzały jak macOS/Linux. Używaj WSL dla pełnej izolacji, szczególnie gdy pracujesz z kodem z niezaufanych źródeł (open source dependencies, code review).
Konfiguracja VSCode + WSL:
// .vscode/settings.json
{
"chatgpt.runCodexInWindowsSubsystemForLinux": true
}Docker: container-level isolation
Uruchamiasz Codex w Docker? Kontener sam w sobie to sandbox, ale warto dodać warstwy:
# Dockerfile
FROM node:20-slim
# Zainstaluj Codex
RUN npm i -g @openai/codex
# NIE uruchamiaj jako root!
USER node
WORKDIR /workspaceUruchomienie z dodatkowymi ograniczeniami:
docker run -it \
--cap-drop=ALL \
--security-opt=no-new-privileges \
--read-only \
--tmpfs /tmp \
-v $(pwd):/workspace \
my-codex-image codex| Flag | Co robi | Priorytet |
| USER node | Nie root w kontenerze | Wymagane |
| --cap-drop=ALL | Minimalne capabilities | Rekomendowane |
| --read-only | Tylko /tmp i /workspace zapisywalne | Opcjonalne |
| --network=none | Bez sieci | Dla sandboxed tasks |
| --security-opt=no-new-privileges | Blokuje privilege escalation | Rekomendowane |
Docker + wewnętrzny sandbox Codex = dwie warstwy ochrony (defense in depth).
Tryby sandbox w config.toml
Niezależnie od platformy, Codex oferuje trzy tryby sandbox:
# ~/.codex/config.toml
sandbox_mode = "workspace-write" # domyślny| Tryb | Pliki | Komendy | Sieć | Użycie |
| read-only | Tylko odczyt | Nie | Nie | Code review, analiza |
| workspace-write | Odczyt + zapis w workspace | Tak (w workspace) | Nie* | Codzienna praca |
| danger-full-access | Pełen dostęp | Tak | Tak | Izolowane środowiska |
*Sieć w workspace-write można włączyć:
[sandbox_workspace_write]
network_access = trueChronione ścieżki (nawet w workspace-write):
/.git– tylko odczyt (nie zepsuje historii)/.agents– tylko odczyt (nie zmodyfikuje skills)/.codex– tylko odczyt (nie zmieni konfiguracji)
Troubleshooting
Diagnostyka:
codex doctorCzęste problemy:
| Problem | Platforma | Rozwiązanie |
| Permission denied przy uruchomieniu | macOS | Dodaj Terminal do Full Disk Access |
| Sandbox: unavailable | Linux | Kernel < 5.13 – zainstaluj bubblewrap |
| Network blocked unexpectedly | All | Sprawdź sandbox_mode w config.toml |
| Cannot write to workspace | Docker | Sprawdź volume permissions i USER |
| Slow startup | WSL | Użyj WSL2 (nie WSL1): wsl --set-version Ubuntu 2 |
macOS Ventura/Sonoma: Jeśli widzisz 'Operation not permitted', sprawdź System Settings → Privacy & Security → Full Disk Access i dodaj swój terminal (Terminal.app, iTerm, Warp).
Remote development (SSH):
Codex działa przez SSH, ale sandbox działa na maszynie zdalnej:
# Na remote server
ssh user@server
codex doctor # Sprawdź sandbox na serwerzeNa VPS/cloud VM (AWS EC2, GCP, Azure) masz zazwyczaj pełny Linux sandbox. Sprawdź kernel version: uname -r.
Więcej o bezpieczeństwie w artykule o Exec Policy Rules i konfiguracji sandbox.

