Zarządzanie Codexem w firmie: requirements.toml, dostęp i audyt

Zarządzanie Codexem w firmie opiera się na dwóch mechanizmach. Ustawienia workspace ChatGPT decydują, kto w ogóle może korzystać z Codexa, a należący do administratorów plik requirements.toml ogranicza na każdej maszynie logowanie, zatwierdzanie, sandbox, wyszukiwanie, MCP, marketplace’y i reguły poleceń. Użytkownik nie może tych ograniczeń nadpisać, a codex doctor wskazuje plik, który wymusił każde z nich.

Ta strona jest dla tech leada lub inżyniera platformy, który odpowiada za Codexa w więcej niż jednym zespole, oraz dla CTO, który zatwierdza wdrożenie. Przegląd bezpieczeństwa prosi o dowód, że żaden laptop nie uruchamia Codexa z pełnym dostępem do dysku, niezatwierdzonym serwerem MCP albo na prywatnym koncie. Strona na wiki z napisem „tego nie wolno” nie jest dowodem. Potrzebujesz pliku, którego słucha każda maszyna, i testu, który zawodzi, gdy przestaje go słuchać.

Zakres: ta strona dotyczy wyłącznie Codexa. Jedną politykę przełożoną na Claude Code, Codex, Cursor i GitHub Copilot opisuje strona jedna polityka dla wszystkich agentów kodujących. Wspólne ustawienia zespołu (.codex/config.toml, AGENTS.md, pliki reguł, skills) znajdziesz w pracy zespołowej z Codexem. Jeśli warstwy config.toml są dla ciebie nowe, zacznij od konfiguracji Codexa.

Co zyskasz dzięki zarządzaniu Codexem

Mapę ustawień Codexa, które użytkownik może nadpisać, i tych, których nie może.
Bazowy requirements.toml, który ładuje się bez błędów w codex-cli 0.157.1, z pułapkami każdego klucza.
Kolejność wdrożenia w sześciu krokach, od tabeli polityki po dystrybucję na całą flotę.
Test CI, który dowodzi egzekwowania polityki bez ręcznego zaglądania do jakiegokolwiek laptopa.
Mapę dowodów audytowych: na jakie pytanie odpowiada każdy log i raport oraz na ile jest zweryfikowany.
Trzy prompty do skopiowania, które piszą politykę, budują test i raportują rozjazdy.

Które ustawienia Codexa może nadpisać programista?

Codex oddziela wartości domyślne od ograniczeń. Wytyczne OpenAI w skillu dokumentacji dołączonym do Codexa brzmią: „Keep config.toml defaults, requirements.toml constraints, and managed or administrator policy separate”. Tabela pokazuje, gdzie jest zapisana każda warstwa i która ma pierwszeństwo.

Warstwa	Gdzie się znajduje	Właściciel	Czy programista może ją nadpisać?	Do czego jej używać
Ustawienia workspace ChatGPT	Konsola administratora workspace	Administratorzy workspace	Nie	Kto może używać Codexa lokalnie i w chmurze; środowiska chmurowe; konektory
`requirements.toml`	`/etc/codex/requirements.toml` w Linuksie, zarządzane preferencje MDM w macOS albo warstwa enterprise dostarczana z workspace	Zespół bezpieczeństwa lub platformy	Nie. Niedozwolona wartość wraca do pierwszej dozwolonej, z ostrzeżeniem przy starcie	Minimalne wymagania: logowanie, zatwierdzanie, sandbox, wyszukiwanie w sieci, MCP, marketplace’y, reguły poleceń
Systemowy `config.toml`	`/etc/codex/config.toml`	Zespół platformy	Tak	Domyślne ustawienia floty, np. eksporter `[otel]`
`config.toml` użytkownika i projektu	`~/.codex/config.toml`, `.codex/config.toml` w zaufanym repozytorium	Programiści i zespoły	Tak	Preferencje i konwencje zespołu

Z dwóch luk wynika reszta tej strony. W codex-cli 0.157.1 requirements.toml nie ma listy dozwolonych modeli ani klucza [otel] (sprawdzone w config_requirements.rs na tagu rust-v0.157.1, 2026-09-26). Telemetria jest więc wartością domyślną, którą programista może wyłączyć, a wybór modelu kontrolujesz przez workspace lub bramkę, jak opisuje strona gdzie działa model. Trasę nadal możesz wymusić: model_provider w requirements.toml przypina dostawcę (na przykład waszą bramkę) i nadpisuje konfigurację użytkownika oraz sesji, a model_catalog_json przypina katalog modeli, co sprawdziliśmy w config_requirements.rs na tagu rust-v0.157.1. [models.new_thread] w requirements.toml ustawia domyślny model dla nowych wątków, ale nie ogranicza wyboru.

Wdróż zarządzanie Codexem w sześciu krokach

Kolejność ma znaczenie. Kontrola dostępu idzie przed plikiem polityki, bo plik nie ograniczy kogoś, kto loguje się kluczem API poza twoim workspace. Weryfikacja idzie przed dystrybucją, bo zepsuty requirements.toml zatrzymuje Codexa na każdej maszynie, która go dostanie.

Zapisz politykę jako tabelę, zanim napiszesz choć linijkę TOML. Jeden wiersz na mechanizm kontroli: ryzyko, któremu przeciwdziała, klasa ryzyka z zarządzania i autonomii, punkt egzekwowania i właściciel. Mechanizmy bez punktu egzekwowania opierają się na zaufaniu i tabela powinna to mówić wprost. To tę tabelę zatwierdza CTO i to ona jest wejściem do pierwszego promptu poniżej.

Mechanizm kontroli	Klasa ryzyka	Egzekwowane przez	Właściciel
Logować się mogą tylko konta z workspace	Wysoka	`allowed_login_methods`, `allowed_chatgpt_workspaces`	Bezpieczeństwo
Brak pełnego dostępu do dysku na laptopach	Wysoka	`allowed_sandbox_modes`	Platforma
Brak przebiegów bez zatwierdzeń	Średnia	`allowed_approval_policies`	Platforma
Tylko sprawdzone serwery MCP	Wysoka	`[mcp_servers.*.identity]`	Bezpieczeństwo
Wtyczki tylko z wewnętrznego marketplace’u	Średnia	`[marketplaces]`	Platforma
Agent nie robi force-pusha ani publikacji paczek	Wysoka	`[rules] prefix_rules`	Platforma
Telemetria sesji trafia do kolektora	Średnia	Systemowy `config.toml` (wartość domyślna, niewymuszana)	Platforma

Ogranicz, kto może używać Codexa w workspace. W ustawieniach administratora workspace ChatGPT włącz Codexa lokalnie i w chmurze tylko dla grup z pilotażu, a potem poszerzaj dostęp grupa po grupie. Stron administracyjnych OpenAI nie dało się odczytać przy tej aktualizacji (2026-09-26), więc ta strona nie podaje nazw przełączników. Sprawdź aktualne etykiety w przewodniku administratora enterprise od OpenAI.
Przypnij logowanie do swojego workspace. Ustaw allowed_login_methods = ["chatgpt"] i allowed_chatgpt_workspaces na identyfikator swojego workspace. Bez tych dwóch kluczy programista może zalogować się prywatnym kluczem API, a taka sesja działa poza ustawieniami workspace.
Napisz requirements.toml na podstawie tabeli. Zacznij od pliku bazowego z następnej sekcji, trzymaj go w repozytorium polityk i w pierwszym komentarzu zapisz wersję i właściciela.
Sprawdź plik w CI, zanim trafi na maszyny. Uruchamiaj test opisany w sekcji o dowodzie egzekwowania przy każdej zmianie w repozytorium polityk. Zespół bezpieczeństwa zatwierdza pull request, a test decyduje, czy można go scalić.
Rozdystrybuuj plik i pilnuj rozjazdów. Wypchnij go narzędziem do zarządzania urządzeniami: jako plik /etc/codex/requirements.toml w Linuksie, zarządzane preferencje w macOS albo warstwę enterprise z workspace, jeśli twój plan ją oferuje. Gdy wymagania ustawia kilka źródeł, Codex je składa, a każde ostrzeżenie i każdy błąd wskazuje źródło, które ustawiło wartość. Cotygodniowy raport rozjazdów (trzeci prompt) wyłapuje maszyny, na których pliku brakuje albo jest nieaktualny.

Bazowy requirements.toml, który ładuje się w Codexie 0.157.1

Ten plik ładuje się bez błędów w codex-cli 0.157.1. Zastąp CHATGPT_WORKSPACE_ID identyfikatorem swojego workspace, a acme nazwą swojego marketplace’u wtyczek.

# /etc/codex/requirements.toml  (agent-policy v1.0, owner: platform-security)
allowed_login_methods = ["chatgpt"]
allowed_chatgpt_workspaces = ["CHATGPT_WORKSPACE_ID"]

# The first entry is the fallback when a user's config asks for anything else.
allowed_approval_policies = ["on-request", "untrusted"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
allowed_web_search_modes = ["cached"]

[mcp_servers.github.identity]
url = "https://api.githubcopilot.com/mcp/"

[mcp_servers.linear.identity]
url = "https://mcp.linear.app/mcp"

[marketplaces]
restrict_to_allowed_sources = true

[marketplaces.allowed_sources.acme]
source = "git"
url = "https://github.com/acme/agent-plugins.git"

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }, { token = "--force" }], decision = "forbidden", justification = "Force-push is for humans" },
  { pattern = [{ token = "npm" }, { token = "publish" }], decision = "forbidden", justification = "Releases go through CI" },
  { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Infrastructure changes need a named approver" },
]

Jak każdy klucz działa w praktyce, sprawdzone w binarce i kodzie źródłowym 0.157.1 dnia 2026-09-26:

Kolejność na liście jest częścią polityki. Gdy konfiguracja użytkownika prosi o niedozwoloną wartość, Codex wraca do pierwszej pozycji z listy dozwolonych. Przy ["on-request", "untrusted"] ustawienie approval_policy = "never" zamienia się w on-request; po odwróceniu listy — w untrusted.
allowed_sandbox_modes musi zawierać read-only, inaczej Codex odrzuca wymaganie. Ograniczenie obejmuje też profile uprawnień, a nie tylko starszą flagę --sandbox. Prośba o danger-full-access wraca do read-only.
Tryb wyszukiwania disabled jest zawsze dozwolony. allowed_web_search_modes = ["cached"] dopuszcza cached i disabled, a blokuje live.
Serwery MCP są dopasowywane po nazwie i tożsamości. Serwer spoza listy ma w codex mcp list status disabled: requirements. Zatwierdzona nazwa waży tyle samo co URL, więc opublikuj dokładne nazwy, których programiści mają używać.
Reguły przyjmują tylko prompt albo forbidden. Codex łączy reguły z wymagań z regułami użytkownika i projektu i zostawia najbardziej restrykcyjny wynik, dlatego decision = "allow" jest odrzucane.
Odrzucony plik zatrzymuje Codexa. Jedna reguła allow albo inny niepoprawny wpis kończy się komunikatem Error loading config.toml: invalid rules in requirements (set by /etc/codex/requirements.toml) i Codex się nie uruchamia. Właśnie dlatego krok 5 poprzedza krok 6.

Dwa ostrzejsze klucze pasują tylko do polityki wysyłanej na maszyny (grupy urządzeń), które pracują na danych regulowanych. allow_managed_hooks_only = true ignoruje hooki użytkownika, projektu i sesji, a więc wyłącza też hooki, których zespoły używają jako bramek jakości. enforce_residency = "us" przypina rezydencję danych, a us to jedyna wartość akceptowana przez 0.157.1. Domyślny model zostaw poza tym plikiem, chyba że masz konkretny powód: Codex domyślnie używa GPT-6 Astra, a modele i ceny porównuje hub modeli.

Jak udowodnić, że polityka jest egzekwowana, bez zaglądania do laptopów?

Polityka jest egzekwowana wtedy, gdy wroga konfiguracja nie jest w stanie jej obejść. Przygotuj taką konfigurację raz, uruchamiaj ją przy każdej zmianie polityki, a werdykt zostaw CI. codex doctor nie potrzebuje do tego danych logowania: czyta warstwy konfiguracji, stosuje wymagania i wypisuje każde ostrzeżenie startowe wraz ze źródłem.

Konfiguracja programisty, która próbuje każdego zakazanego ustawienia:

approval_policy = "never"
sandbox_mode = "danger-full-access"
web_search = "live"

[mcp_servers.unapproved-server]
command = "npx"
args = ["-y", "some-mcp"]

Test, który przechodzi tylko wtedy, gdy trzymają się ograniczenia zatwierdzania, sandboxa, wyszukiwania i MCP, i zawodzi, gdy plik się nie ładuje:

#!/usr/bin/env bash
# policy/codex/check.sh — runs in CI; needs no Codex credentials
set -euo pipefail
here="$(cd "$(dirname "$0")" && pwd)"
export CODEX_HOME="$(mktemp -d)"
cp "$here/tests/hostile-config.toml" "$CODEX_HOME/config.toml"

report="$(codex doctor --no-color 2>&1 || true)"
if grep -q "config could not be loaded" <<<"$report"; then
  echo "FAIL: requirements.toml does not load"; exit 1
fi
for key in approval_policy sandbox_mode web_search_mode; do
  grep -q "invalid value for \`$key\`" <<<"$report" \
    || { echo "FAIL: $key is not constrained"; exit 1; }
done
codex mcp list 2>/dev/null | grep -Eq '^unapproved-server .*disabled: requirements' \
  || { echo "FAIL: unapproved MCP server is not disabled"; exit 1; }
echo "PASS: policy enforced"

Klucze logowania, marketplace’ów i reguł poleceń test tylko ładuje, ale ich nie sprawdza. Wpisz je do GAPS.md albo przetestuj ręcznie w pilotażu: zaloguj się kontem prywatnym, dodaj wtyczkę z niedozwolonego marketplace’u i uruchom zakazane polecenie.

Uruchamiaj go przy każdym pull requeście do repozytorium polityk. Zadanie nie potrzebuje sekretów, pobiera kod z uprawnieniami tylko do odczytu i przypina wersję Codexa, żeby aktualizacja CLI była osobną, przejrzaną zmianą:

name: codex-policy
on:
  pull_request:
    paths: ["policy/codex/**"]
permissions:
  contents: read
jobs:
  canary:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<full-commit-sha> # v7
        with:
          persist-credentials: false
      - run: npm install -g @openai/codex@0.157.1
      - run: sudo install -D -m 0644 policy/codex/requirements.toml /etc/codex/requirements.toml
      - run: bash policy/codex/check.sh

W repozytorium polityk przypinaj każdą akcję pełnym SHA commita, a nie tagiem, bo tag taki jak v7 można przesunąć na inny kod. <full-commit-sha> powyżej to symbol zastępczy: wstaw w jego miejsce 40-znakowy SHA przejrzanego wydania actions/checkout, a tag zostaw w komentarzu (# v7), żeby czytelnik widział, o które wydanie chodzi.

Ten sam skrypt zawodzi, gdy pliku brakuje, więc służy też jako szybki test świeżo zainstalowanego laptopa. Na maszynie programisty /debug-config w TUI Codexa pokazuje stos warstw konfiguracji i obowiązujące wymagania, a codex doctor --json tworzy raport z zamaskowanymi sekretami, którego sprawdzenie config.load zawiera ostrzeżenia startowe. Narzędzie do zarządzania urządzeniami może zbierać ten raport, razem z sumą sha256 pliku /etc/codex/requirements.toml, na potrzeby kontroli rozjazdów.

Zatwierdzanie odpowiada tabeli z kroku 1: zespół bezpieczeństwa zatwierdza pull request z polityką, test decyduje o scaleniu, platforma odpowiada za dystrybucję, a tech lead przegląda cotygodniowy raport rozjazdów. Nikt nie czyta ręcznie konfiguracji laptopa.

Test decyduje o scaleniu tylko wtedy, gdy pull request nie może go przepisać. Przy wyzwalaczu pull_request GitHub uruchamia workflow, check.sh i wrogą konfigurację z samego pull requesta, więc autor zmiany może osłabić wszystkie trzy w tym samym PR. Obejmij /.github/, policy/codex/check.sh i policy/codex/tests/ plikiem CODEOWNERS z zespołem bezpieczeństwa jako właścicielem i wymuś tę recenzję przez ochronę gałęzi lub ruleset; bez tego test jest tylko doradczy.

Skąd biorą się dowody audytowe

Audytorzy zadają cztery pytania. Każde ma inne źródło, a źródła nie są jednakowo zweryfikowane.

Pytanie	Źródło	Status weryfikacji (2026-09-26)
Jaka polityka obowiązywała na tej maszynie?	Wersjonowany `requirements.toml` w gicie oraz `codex doctor --json` z maszyny	Zweryfikowane w codex-cli 0.157.1
Co robiły sesje?	Logi, ślady i metryki OpenTelemetry z tabeli `[otel]`, wysyłane do twojego kolektora. `log_user_prompt` domyślnie ma wartość `false`	Zweryfikowane w kodzie źródłowym Codexa; konfiguracja na stronie telemetria agentów
Kto używał Codexa, gdzie i ile?	Dashboard analityczny Codexa i Analytics API dla workspace’ów Enterprise	Źródło wtórne: help.openai.com, widziane we fragmentach wyników wyszukiwania 2026-09-26; ścieżki endpointów niezweryfikowane
Jakie były prompty i odpowiedzi, na potrzeby eDiscovery lub DLP?	Compliance API	Źródło wtórne: help.openai.com, widziane we fragmentach wyników wyszukiwania 2026-09-26; pola i endpointy niezweryfikowane

Wiersze oparte na źródłach wtórnych traktuj jako tropy do potwierdzenia z opiekunem konta w OpenAI, zanim oprze się na nich audytor. Ścieżkę OpenTelemetry kontrolujesz od początku do końca, z opisaną już luką: to wartość domyślna, a nie ograniczenie, więc co miesiąc porównuj pokrycie w kolektorze z liczbą miejsc w workspace. Potok audytowy i retencję na poziomie całej organizacji opisuje strona obserwowanie agentów. Retencję danych i zerową retencję w poszczególnych narzędziach omawia strona prywatność danych i polityki firmowe.

Prompty do skopiowania dla zarządzania Codexem

Uruchamiaj je w Codexie, w repozytorium polityk.

Read POLICY.md, which holds our agent policy as a table with the columns
Control, Risk class, Enforced by, and Owner. Write policy/codex/requirements.toml so it
implements every row whose "Enforced by" names a requirements.toml key. Use only keys
that exist in openai/codex codex-rs/config/src/config_requirements.rs at the Codex
version we pin (0.157.1): check each key against that file and list any you could not
find. Order every allowed_* list so the safest value we still allow comes first,
because Codex falls back to the first entry. Include read-only in allowed_sandbox_modes.
Use only "prompt" or "forbidden" in [rules]. For each row that no key can enforce,
add a line to policy/codex/GAPS.md naming the control and a compensating control.
Do not invent keys, and do not touch any file outside policy/codex/.

Create policy/codex/tests/hostile-config.toml and policy/codex/check.sh. The hostile
config must request a value the policy forbids for approval_policy, sandbox_mode and
web_search, and must add one MCP server whose name is not in the allowlist. List the
remaining requirements.toml keys that this canary does not exercise in
policy/codex/GAPS.md. check.sh sets CODEX_HOME to a temporary directory,
copies the hostile config there, runs `codex doctor --no-color`, and fails unless the
output contains "invalid value for `<key>`" for each constrained key and
`codex mcp list` shows the unapproved server as "disabled: requirements". It must also
fail if the output says "config could not be loaded". Add
.github/workflows/codex-policy.yml that runs on pull_request for policy/codex/**, with
permissions: contents: read, persist-credentials: false, no secrets, every action
pinned by full commit SHA, Codex pinned to 0.157.1, and the file installed at
/etc/codex/requirements.toml. Show me a failing run first by removing the file, then
a passing run.

The directory reports/doctor/ holds one `codex doctor --json` report per machine,
named <hostname>.json, collected by our device management tool this week. Write
scripts/codex_drift.py that reads every report and prints a table with one row per
machine: hostname, Codex version, whether any startup warning cites
/etc/codex/requirements.toml, the number of startup warnings, and the config.load
status. Each machine also has <hostname>.sha256, the sha256 of
/etc/codex/requirements.toml collected by the same tool, or no such file when the
policy file is absent. Compare it with the sha256 of policy/codex/requirements.toml
at the release tag we shipped. Flag machines whose Codex version differs from 0.157.1,
machines whose config.load status is "fail", and machines whose policy hash is missing
or does not match. Do not infer a missing policy from the absence of warnings: an
allowed value produces none. Print the flagged machines first. Read the reports only;
never print a token or a path under a user's home directory beyond the hostname.

Co psuje się w zarządzaniu Codexem i jak to naprawić

Po wypchnięciu polityki Codex przestaje startować na wszystkich maszynach. Plik zawiera niepoprawny wpis, najczęściej decision = "allow" w [rules] albo nieznany klucz w ścisłej tabeli, takiej jak [marketplaces]. Wycofaj zmianę narzędziem do zarządzania urządzeniami, a potem dodaj test, żeby następny zepsuty plik zatrzymał się w CI.
Ograniczenie po cichu nic nie robi. Literówka w kluczu najwyższego poziomu, np. allowed_sandbox_mode bez końcowego s, jest w 0.157.1 ignorowana: plik się ładuje, a ograniczenia po prostu nie ma. Wyłapie to tylko test, który próbuje zakazanej wartości — i właśnie to robi test z tej strony dla kluczy, które sprawdza.
Programista zgłasza: „ustawiłem never, a Codex dalej prosi o zatwierdzenie”. Polityka działa. Ostrzeżenie startowe pokazuje wartość, do której Codex wrócił, i plik, który to wymusił. Opublikuj tabelę polityki tam, gdzie programiści ją przeczytają, żeby powrót do wartości dozwolonej nie był zaskoczeniem.
Zatwierdzony serwer MCP ma status disabled: requirements. Programista zarejestrował go pod inną nazwą niż ta w requirements.toml. Opublikuj dokładne nazwy albo dostarczaj wpisy serwerów w systemowym config.toml, żeby nazwy zgadzały się od początku.
Na części laptopów nadal działa wyszukiwanie live albo pełny dostęp. Na tych maszynach nie ma aktualnego pliku. Znajdź w raporcie rozjazdów maszyny z brakującym lub niezgodnym skrótem polityki i napraw pokrycie w zarządzaniu urządzeniami, zanim dodasz kolejne reguły.
Telemetria jednego użytkownika milknie. [otel] to wartość domyślna, którą konfiguracja użytkownika może nadpisać; 0.157.1 nie potrafi jej wymusić. Co miesiąc porównuj pokrycie w kolektorze z liczbą miejsc w workspace i traktuj lukę jako temat do rozmowy, a nie naruszenie.
Polityka dla danych regulowanych zepsuła hooki zespołu. allow_managed_hooks_only = true ignoruje wszystkie hooki projektu, łącznie z bramkami testów i lintera. Przenieś potrzebne bramki do hooków zarządzanych albo wysyłaj ostrzejszy plik tylko do grupy urządzeń, która obsługuje repozytoria regulowane.
Zadanie w chmurze zrobiło coś, czego zabrania polityka lokalna. Plik lokalny nie sięga do Codex cloud. Zaostrz dostęp w workspace i ustawienia środowiska, jak opisuje strona środowiska chmurowe Codexa.

Dokąd dalej w zarządzaniu Codexem

Jedna polityka dla wszystkich agentów kodujących: te same mechanizmy kontroli dla Claude Code, Cursor i GitHub Copilot, z testem zgodności.
Praca zespołowa z Codexem: wspólne ustawienia domyślne, pliki reguł i skills, które działają pod tą polityką.
Rejestry i bramki MCP: jak zdecydować, które serwery MCP trafią na listę dozwolonych.
Zarządzanie kosztami Codexa: budżety i limity użycia, gdy dostęp jest już pod kontrolą.
Telemetria agentów: konfiguracja [otel] stojąca za tabelą dowodów audytowych.
Zarządzanie i autonomia: klasy ryzyka, które wypełniają tabelę polityki.