AI agent z pełnym dostępem do terminala to potężne narzędzie – i potencjalne ryzyko. Exec Policy Rules pozwalają precyzyjnie kontrolować, które komendy Codex może uruchamiać automatycznie, które wymagają twojej zgody, a które są całkowicie zablokowane.
To trzecia warstwa ochrony (obok sandbox mode i approval policy) – i najbardziej granularna.
- Dlaczego ograniczać komendy?
- Gdzie definiować reguły
- Składnia Starlark
- Allow, Prompt, Forbidden
- Przykłady reguł
- Gotowe wzorce dla zespołów
- Testowanie reguł
- Audyt i logowanie
Dlaczego ograniczać komendy?
Scenariusz: Prosisz Codex o cleanup repozytorium. AI interpretuje to dosłownie i uruchamia rm -rf na folderze, który wydawał się niepotrzebny. Ups.
Exec Policy Rules to warstwa bezpieczeństwa między AI a twoim systemem:
| Obszar | Bez reguł | Z regułami |
| Security | Codex może uruchomić rm -rf | Destrukcyjne komendy zablokowane |
| Compliance | Brak kontroli nad prod | Deploy wymaga approval |
| Audit | Brak logów | Każda akcja logowana do OTel |
| Consistency | Każdy ma inne ustawienia | Zespół używa tych samych reguł |
Gdzie definiować reguły
Reguły mogą być definiowane na trzech poziomach (od najwyższego priorytetu):
| Priorytet | Lokalizacja | Zakres |
| 1 | .codex/rules/*.rules | Projekt |
| 2 | ~/.codex/rules/default.rules | Użytkownik |
| 3 | /etc/codex/rules/*.rules | System (admin) |
Reguły o wyższym priorytecie nadpisują niższe. Pozwala to na:
- Globalny zakaz
rm -rfna poziomie systemu - Per-projekt allowlist dla narzędzi CI tego projektu
- Osobiste reguły dla eksperymentów
Składnia Starlark
Reguły definiujesz w plikach .rules używając składni Starlark (uproszczony Python):
# ~/.codex/rules/default.rules
prefix_rule(
pattern = ["gh", "pr", "view"],
decision = "prompt",
justification = "Viewing PRs is allowed with approval",
)Struktura prefix_rule():
prefix_rule(
pattern = ["cmd", "arg1", "arg2"], # Prefiks komendy
decision = "allow", # allow | prompt | forbidden
justification = "Why this decision", # Wyświetlane przy prompt
match = ["cmd arg1 arg2 extra"], # Opcjonalne: dokładne matche
not_match = ["cmd arg2 arg1"], # Opcjonalne: wyjątki
)prefix_rule() dopasowuje komendy po prefiksie – sekwencji początkowych argumentów. gh pr view 123 pasuje do pattern = ["gh", "pr", "view"].
Allow, Prompt, Forbidden
| Decyzja | Działanie | Przypadek użycia |
| allow | Wykonaj automatycznie bez pytania | Bezpieczne odczyty, testy, lint |
| prompt | Zapytaj użytkownika przed wykonaniem | Operacje zapisu, deploy staging |
| forbidden | Zablokuj całkowicie, nie pytaj | rm -rf, DROP TABLE, prod deploy |
Domyślnie wszystko wymaga zatwierdzenia (prompt). Reguły pozwalają poluzować lub zaostrzyć kontrolę dla konkretnych wzorców.
Zasada: Zacznij od forbidden dla destrukcyjnych komend, prompt dla operacji zapisu, allow dla odczytów. Rozluźniaj ostrożnie.
Przykłady reguł
Git – odczyty bez pytania, push z promptem:
# Allow read operations
prefix_rule(
pattern = ["git", "status"],
decision = "allow",
)
prefix_rule(
pattern = ["git", "log"],
decision = "allow",
)
prefix_rule(
pattern = ["git", "diff"],
decision = "allow",
)
# Require approval for writes
prefix_rule(
pattern = ["git", "push"],
decision = "prompt",
justification = "Pushing requires approval",
)
prefix_rule(
pattern = ["git", "push", "--force"],
decision = "forbidden",
justification = "Force push is never allowed",
)npm/pnpm – instalacja z promptem, publish zablokowane:
prefix_rule(
pattern = ["npm", "install"],
decision = "prompt",
justification = "Installing packages modifies node_modules",
)
prefix_rule(
pattern = ["npm", "publish"],
decision = "forbidden",
justification = "Publishing to npm requires manual process",
)
prefix_rule(
pattern = ["npm", "run", "test"],
decision = "allow",
)
prefix_rule(
pattern = ["npm", "run", "lint"],
decision = "allow",
)Docker – build OK, push zablokowany:
prefix_rule(
pattern = ["docker", "build"],
decision = "allow",
)
prefix_rule(
pattern = ["docker", "push"],
decision = "forbidden",
justification = "Pushing images requires CI pipeline",
)
prefix_rule(
pattern = ["docker", "run"],
decision = "prompt",
justification = "Running containers requires approval",
)Destrukcyjne komendy – zawsze forbidden:
# File deletion
prefix_rule(
pattern = ["rm", "-rf"],
decision = "forbidden",
)
prefix_rule(
pattern = ["rm", "-r"],
decision = "forbidden",
)
# Database operations
prefix_rule(
pattern = ["psql", "-c", "DROP"],
decision = "forbidden",
)
prefix_rule(
pattern = ["mysql", "-e", "DROP"],
decision = "forbidden",
)Gotowe wzorce dla zespołów
Starter ruleset (skopiuj do ~/.codex/rules/default.rules):
# === FORBIDDEN (never allow) ===
prefix_rule(pattern = ["rm", "-rf"], decision = "forbidden")
prefix_rule(pattern = ["rm", "-r"], decision = "forbidden")
prefix_rule(pattern = ["git", "push", "--force"], decision = "forbidden")
prefix_rule(pattern = ["npm", "publish"], decision = "forbidden")
prefix_rule(pattern = ["docker", "push"], decision = "forbidden")
# === PROMPT (require approval) ===
prefix_rule(pattern = ["git", "push"], decision = "prompt")
prefix_rule(pattern = ["npm", "install"], decision = "prompt")
prefix_rule(pattern = ["docker", "run"], decision = "prompt")
# === ALLOW (safe read operations) ===
prefix_rule(pattern = ["git", "status"], decision = "allow")
prefix_rule(pattern = ["git", "log"], decision = "allow")
prefix_rule(pattern = ["git", "diff"], decision = "allow")
prefix_rule(pattern = ["npm", "run", "test"], decision = "allow")
prefix_rule(pattern = ["npm", "run", "lint"], decision = "allow")
prefix_rule(pattern = ["cat"], decision = "allow")
prefix_rule(pattern = ["ls"], decision = "allow")
prefix_rule(pattern = ["pwd"], decision = "allow")Dla zespołów: Umieść reguły w /etc/codex/rules/team.rules (wymaga sudo). Każdy dev dostanie te same zabezpieczenia bez ręcznej konfiguracji.
Testowanie reguł
Przed wdrożeniem przetestuj reguły:
# Sprawdź konkretną komendę
codex execpolicy check --pretty \
--rules ~/.codex/rules/default.rules \
-- gh pr view 7888
# Sprawdź destrukcyjną komendę
codex execpolicy check --pretty \
--rules ~/.codex/rules/default.rules \
-- rm -rf node_modulesKomenda pokaże która reguła zadziała i jaką decyzję podejmie Codex:
Command: rm -rf node_modules
Matched rule: prefix_rule(pattern=["rm", "-rf"])
Decision: FORBIDDEN
Justification: File deletion with -rf is never allowedAudyt i logowanie
Dla pełnego audytu włącz OpenTelemetry w config.toml:
[otel]
environment = "production"
exporter = "otlp-http"
[otel.exporter.otlp-http]
endpoint = "https://otel.yourcompany.com/v1/logs"Codex wyśle eventy dla każdej decyzji:
codex.tool_decision– która reguła zadziałałacodex.tool_result– wynik wykonania
To daje pełną ścieżkę audytu: kto, kiedy, jaką komendę próbował uruchomić i co się stało.
| Event | Zawartość |
| codex.tool_decision | Komenda, matched rule, decision |
| codex.tool_result | Exit code, stdout/stderr (redacted) |
Więcej o bezpieczeństwie Codex w artykule o sandbox i audycie. Reguły exec policy to jeden z elementów większego systemu kontroli – razem z trybami uprawnień dają pełną kontrolę nad tym, co AI może robić.