1 czerwca 2026 r. OpenAI opublikowało Codex CLI 0.136.0, czyli nowe wydanie terminalowego agenta programistycznego, który działa lokalnie na maszynie użytkownika i szczególnie dobrze wpisuje się w codzienną pracę na Linuksie: czytanie repozytoriów, uruchamianie testów, przygotowywanie patchy, analizę logów, obsługę skryptów oraz automatyzację zadań w shellu. Dla administratorów i zespołów DevOps to nie jest tylko kolejny klient do rozmowy z modelem. To narzędzie, które coraz mocniej dotyka realnych granic bezpieczeństwa systemu: sandboxingu, uprawnień do plików, dostępu do sieci, sesji roboczych i audytu działań wykonywanych w terminalu.
Najważniejsza zmiana z perspektywy linuxadmina nie polega na jednej efektownej funkcji, ale na dojrzewaniu całego modelu pracy. Codex CLI 0.136.0 dodaje archiwizację sesji, poprawia obsługę integracji app-server, wzmacnia mechanizmy remote execution, aktualizuje elementy związane z MCP, a także wprowadza poprawki bezpieczeństwa dla wykonywania komend i pracy w sandboxie. W praktyce oznacza to, że agent terminalowy staje się mniej jednorazowym eksperymentem, a bardziej narzędziem, które można wpasować w powtarzalny workflow zespołu.
Co konkretnie pojawiło się w Codex CLI 0.136.0
Wydanie 0.136.0 zostało oznaczone w changelogu Codex 1 czerwca 2026 r. i można je zainstalować jako pakiet npm pod nazwą @openai/codex@0.136.0. Równolegle repozytorium openai/codex udostępnia binaria dla Linuksa, w tym archiwa dla x86_64-unknown-linux-musl oraz aarch64-unknown-linux-musl. To ważne dla administratorów, którzy nie chcą wiązać narzędzia wyłącznie z globalnym npm w systemie, ale wolą dystrybuować konkretny binarny artefakt przez wewnętrzne repozytorium, obraz developerski albo kontrolowany katalog narzędzi.
Wśród nowych funkcji w 0.136.0 szczególnie przydatne są:
- Archiwizacja sesji przez
/archivew TUI oraz komendycodex archiveicodex unarchive. Zarchiwizowane sesje są chronione przed przypadkowym wznowieniem lub forkiem, dopóki nie zostaną przywrócone. - Lepsza obsługa app-server, w tym możliwość uruchomienia trybu stdio przez
codex app-server --stdio, bogatszy status serwerów MCP i wznawianie wątku razem z początkową stroną tur rozmowy. - Zmiany w remote execution: konfiguracja może rejestrować
CODEX_API_KEYdla zatwierdzonych hostów OpenAI, a remote-control websockety używają krótkotrwałych tokenów serwerowych zamiast tokenów dostępowych ChatGPT. - Poprawki TUI: linki w Markdownzie mogą pozostać klikalne dzięki metadanym OSC 8, a ciasne tabele są renderowane czytelniej jako rekordy klucz-wartość.
- Poprawki bezpieczeństwa komend, w tym zabezpieczenie
/diffprzed uruchamianiem repozytoryjnych helperów lub hooków Gita.
Dlaczego to ma znaczenie dla pracy na Linuksie
Linux jest naturalnym środowiskiem dla narzędzi tego typu, bo większość pracy admina i developera i tak dzieje się w terminalu: git, systemctl, journalctl, kubectl, docker, podman, terraform, ansible, pytest, go test, cargo test i setki wewnętrznych skryptów. Codex CLI nie jest tu dodatkiem graficznym, tylko procesem, który może uruchamiać polecenia, czytać pliki i proponować zmiany w repozytorium. To daje dużą produktywność, ale wymusza takie samo myślenie jak przy dopuszczaniu nowego narzędzia CI/CD do środowiska produkcyjnego.
OpenAI w dokumentacji Codex opisuje, że lokalne uruchomienia CLI korzystają z mechanizmów sandboxingu systemu operacyjnego. Na Linuksie i w WSL2 wykorzystywane są bwrap oraz seccomp, a dokumentacja zaleca instalację pakietu bubblewrap z repozytorium dystrybucji. To dobry kierunek: jeżeli agent ma uruchamiać komendy takie jak testy, narzędzia pakietujące albo skrypty migracyjne, powinien mieć ograniczony zakres zapisu i dostępu do sieci. Z punktu widzenia admina kluczowe jest więc nie tylko pytanie „czy Codex umie pomóc?”, ale też „w jakim profilu uprawnień działa?”.
Bezpieczeństwo: poprawki, które warto zauważyć
W 0.136.0 znalazło się kilka zmian, które bezpośrednio dotyczą ryzyka związanego z uruchamianiem poleceń. Pierwsza dotyczy /diff: narzędzie ma zapobiegać sytuacji, w której polecenie do podglądu różnic uruchamia helpery lub hooki skonfigurowane w samym repozytorium. To istotne, bo repozytorium nie powinno móc wykorzystać niewinnego przeglądania diffu jako ścieżki do wykonania kodu.
Druga grupa poprawek dotyczy egzekwowania reguł sandboxa. W changelogu pojawia się m.in. poprawka dla zachowania sprzątania powłoki przy przerwaniu procesu w sandboxie linuksowym oraz utrzymanie reguł deny dla odczytu także w ścieżkach safe-command i approval-bypass. Innymi słowy: jeśli administrator definiuje profil, w którym określone pliki mają być niewidoczne dla agenta, reguły te nie powinny przypadkowo znikać tylko dlatego, że komenda została uznana za bezpieczną albo przebiegła inną ścieżką zatwierdzania.
Trzecia zmiana dotyczy interfejsów zdalnych: exec-server odrzuca websocketowe handshaki pochodzące z przeglądarkowego Origin, a remote-control przechodzi na krótkotrwałe tokeny serwerowe. Dla zespołów, które zaczynają testować zdalne sterowanie sesjami albo integracje z app-serverem, to sygnał, że należy traktować te mechanizmy jak każdy inny zdalny kanał sterowania: z jawnie określonym zasięgiem hostów, rotacją sekretów i logowaniem zdarzeń.
Instalacja i pinning wersji
Najprostszy test na maszynie developerskiej można wykonać przez npm. W środowisku zespołowym lepiej jednak pinować konkretną wersję i nie zostawiać aktualizacji przypadkowemu latest. Przykład dla stacji roboczej lub kontenera narzędziowego:
node --version
npm --version
npm install -g @openai/codex@0.136.0
codex --versionJeżeli w organizacji nie używacie globalnych pakietów npm na hostach, sensowniejszy jest jeden z trzech wariantów: przygotowanie obrazu kontenera z konkretną wersją narzędzia, pobranie binarium z GitHub Releases i umieszczenie go w kontrolowanym katalogu typu /opt/tools/codex/0.136.0/, albo instalacja w katalogu użytkownika przez manager wersji Node. Ważne, aby audyt był prosty: administrator powinien umieć odpowiedzieć, kto używa jakiej wersji i w jakim profilu uprawnień.
Minimalny profil dla bezpieczniejszego startu
Dokumentacja Codex opisuje profile uprawnień jako beta, ale już teraz są one praktycznym punktem startu dla linuxowego workflow. Profile pozwalają ograniczyć system plików i sieć, a wbudowane warianty obejmują m.in. :read-only, :workspace oraz :danger-full-access. Ten ostatni powinien być traktowany podobnie jak uruchamianie losowego skryptu z pełnymi uprawnieniami: tylko wtedy, gdy naprawdę rozumiecie konsekwencje.
Przykładowa konfiguracja startowa dla projektu, w którym Codex może edytować bieżące repozytorium, ale nie powinien czytać plików .env ani sięgać swobodnie do sieci:
# ~/.codex/config.toml
approval_policy = "on-request"
default_permissions = "project-edit"
[permissions.project-edit.workspace_roots]
"~/code/app" = true
[permissions.project-edit.filesystem]
":minimal" = "read"
[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
".devcontainer" = "read"
"**/*.env" = "deny"
"**/*secret*" = "deny"
[permissions.project-edit.network]
enabled = falseTaki profil nie zastąpi przeglądu zmian, ale zmniejsza promień rażenia. Dobrym zwyczajem jest uruchamianie Codex CLI na gałęzi roboczej, przy czystym git status, z małymi commitami i obowiązkowym uruchamianiem testów poza agentem przed mergem. W repozytoriach infrastrukturalnych warto dodatkowo blokować bezpośredni zapis do katalogów z sekretami, stanem Terraform, plikami kubeconfig i prywatnymi kluczami.
Gdzie 0.136.0 może realnie pomóc adminowi
Najbardziej praktyczne scenariusze nie polegają na oddaniu agentowi dostępu do produkcji. Dużo rozsądniej zacząć od zadań lokalnych i odtwarzalnych. Codex CLI może przeanalizować skrypt Ansible, wskazać brak idempotencji, zaproponować test dla roli, uporządkować parser logów, pomóc dopisać walidację do narzędzia w Bashu lub Pythonie, a następnie uruchomić lokalne testy. Przy repozytoriach Kubernetes może przejrzeć manifesty, znaleźć niespójne limity zasobów, porównać wartości Helm albo przygotować checklistę migracji. W projektach observability może pomóc uporządkować reguły alertów, ale wynik nadal powinien przejść normalny code review.
Nowa archiwizacja sesji jest przydatna w dłuższych analizach. Jeżeli agent pracował nad refaktoryzacją roli, migracją pipeline’u albo analizą incydentu, sesję można archiwizować zamiast trzymać ją na liście aktywnych zadań. To drobiazg, ale w zespołach, które pracują równolegle nad wieloma tematami, porządek w sesjach szybko zaczyna mieć znaczenie operacyjne.
Co warto zrobić przed wdrożeniem w zespole
- Ustal jedną wspieraną wersję, np.
0.136.0, i zablokuj przypadkowe aktualizacje do niezweryfikowanegolatest. - Zainstaluj
bubblewrapna linuksowych stacjach roboczych i sprawdź, czy sandbox działa zgodnie z oczekiwaniami. - Zdefiniuj domyślny profil uprawnień z wyłączoną siecią i zapisem ograniczonym do workspace.
- Dodaj reguły
denydla sekretów, plików środowiskowych, kubeconfigów, kluczy prywatnych i lokalnych katalogów z danymi produkcyjnymi. - Wymuś pracę na branchach roboczych oraz standardowy code review zmian przygotowanych w repozytorium.
- Jeśli włączacie zdalne integracje, opiszcie osobną politykę dla hostów, tokenów, logowania i rotacji sekretów.
Podsumowanie praktyczne
Codex CLI 0.136.0 z 1 czerwca 2026 r. to wydanie warte uwagi dla użytkowników Linuksa, bo wzmacnia dokładnie te obszary, które decydują o przydatności narzędzia w realnym środowisku: sesje, app-server, remote execution, sandbox i bezpieczeństwo komend. Najrozsądniejszy model wdrożenia to nie pełny dostęp do systemu, lecz wersja przypięta do konkretnego release’u, profil least privilege, praca na branchu i normalny przegląd diffów. W takim układzie terminalowy agent może być praktycznym wsparciem admina i developera, bez zamieniania stacji roboczej w niekontrolowany automat do uruchamiania poleceń.
