OpenAI Codex na Windows, macOS, Linux: Sandbox na każdej platformie

OpenAI Codex na Windows, macOS, Linux: Sandbox na każdej platformie

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ć.

  1. Porównanie platform
  2. macOS: Seatbelt policies
  3. Linux: Landlock + seccomp
  4. Windows: WSL recommended
  5. Docker: container-level isolation
  6. Tryby sandbox w config.toml
  7. Troubleshooting

Porównanie platform

Sandbox capabilities across platforms
FeaturemacOSLinuxWindows NativeWSL
Sandbox maturityFullFullExperimentalFull
Filesystem isolationSeatbeltLandlockLimitedLandlock
Syscall filteringSeatbeltseccompseccomp
Network blockingPartial
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:

bash
codex doctor
# Pokaże: Sandbox: Seatbelt (active)

Linux: Landlock + seccomp

Linux oferuje najpotężniejszą izolację przez kombinację dwóch mechanizmów:

Mechanizmy sandbox na Linux
MechanizmCo robiKernelTyp ochrony
LandlockOgranicza dostęp do plików i katalogów5.13+Filesystem
seccompFiltruje wywołania systemowe3.5+Syscalls
bubblewrapPełna izolacja namespace (fallback)anyContainer-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):

bash
# 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 doctor

Bubblewrap 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):

powershell
# Zainstaluj WSL2 z Ubuntu
wsl --install

# W WSL terminal:
npm i -g @openai/codex
codex doctor

WSL2 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:

Windows Native vs WSL
FeatureNativeWSL
Filesystem isolationPartialFull (Landlock)
Syscall filteringFull (seccomp)
Network blockingPartialFull
Production readyNoYes

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:

json
// .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
# Dockerfile
FROM node:20-slim

# Zainstaluj Codex
RUN npm i -g @openai/codex

# NIE uruchamiaj jako root!
USER node
WORKDIR /workspace

Uruchomienie z dodatkowymi ograniczeniami:

bash
docker run -it \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --read-only \
  --tmpfs /tmp \
  -v $(pwd):/workspace \
  my-codex-image codex
Docker best practices dla Codex
FlagCo robiPriorytet
USER nodeNie root w kontenerzeWymagane
--cap-drop=ALLMinimalne capabilitiesRekomendowane
--read-onlyTylko /tmp i /workspace zapisywalneOpcjonalne
--network=noneBez sieciDla sandboxed tasks
--security-opt=no-new-privilegesBlokuje privilege escalationRekomendowane

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:

toml
# ~/.codex/config.toml
sandbox_mode = "workspace-write"  # domyślny
Tryby sandbox
TrybPlikiKomendySiećUżycie
read-onlyTylko odczytNieNieCode review, analiza
workspace-writeOdczyt + zapis w workspaceTak (w workspace)Nie*Codzienna praca
danger-full-accessPełen dostępTakTakIzolowane środowiska

*Sieć w workspace-write można włączyć:

toml
[sandbox_workspace_write]
network_access = true

Chronione ś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:

bash
codex doctor

Częste problemy:

Sandbox troubleshooting
ProblemPlatformaRozwiązanie
Permission denied przy uruchomieniumacOSDodaj Terminal do Full Disk Access
Sandbox: unavailableLinuxKernel < 5.13 – zainstaluj bubblewrap
Network blocked unexpectedlyAllSprawdź sandbox_mode w config.toml
Cannot write to workspaceDockerSprawdź volume permissions i USER
Slow startupWSLUż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:

bash
# Na remote server
ssh user@server
codex doctor  # Sprawdź sandbox na serwerze

Na 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.