Przejdź do treści

OpenAI Codex uruchamia w tle demona. Jak go znaleźć i wyłączyć

Adam Marzec
Karta testu demona Codex CLI w tle: kopia pakietu 432 MB, pętla aktualizacji raz na godzinę, proces działający po zamknięciu terminala, zero pytań użytkownika; obok terminal z wynikiem ps aux i pieczątka BEZ ZGODY

Codex, narzędzie do programowania z AI od OpenAI, od końca września zostawia na komputerze proces, o którym większość użytkowników nie ma pojęcia. Wystarczy raz uruchomić narzędzie w terminalu, a ono dokopiuje ponad 400 MB danych, odpala w tle usługę działającą bez okna terminala i wystawia jej aktualizator, który godzinę w godzinę sprawdza nowe wydania. Wszystko bez pytania i bez zalogowanego konta. Zgłoszenie o tym siedzi na GitHubie od 25 września, a gdy 12 października trafiło na czołówkę Hacker News, zebrało 497 punktów i ponad 250 komentarzy. OpenAI nie odniosło się do niego do dziś.

Sprawdziliśmy to na własnej maszynie, na świeżej instalacji Codex CLI 0.162.1. Wszystko, co opisuje zgłoszenie, odtworzyło się co do joty, łącznie z błędem w procedurze wyłączania. Najpierw to, co dokładnie się dzieje, na dole ściąga z komendami.

Co dokładnie robi demon

Od strony użytkownika wygląda to tak. Instalujesz Codex CLI przez npm jak każde narzędzie (npm install -g @openai/codex), wpisujesz codex w terminalu i to właśnie ten moment odpala całą resztę.

Najpierw narzędzie kopiuje swój cały pakiet, u nas 432 MB, do katalogu ~/.codex/packages/app-server-daemon/releases/ i stamtąd uruchamia dalszą pracę. Kopia jest bit w bit taka sama jak ta, którą właśnie doinstalowałeś menedżerem pakietów, więc instalacja Codexa zajmuje z dnia na dzień dwa razy więcej miejsca. W tle staje wtedy demon, czyli proces usługi bez przypisanego terminala. W naszych pomiarach jego linia poleceń wyglądała tak:

codex app-server --listen unix:// --analytics-default-enabled --managed-daemon

Demon przeżywa zamknięcie okna terminala i działa, dopóki nie zatrzymasz go ręcznie albo nie zrestartujesz komputera. Obok rusza jeszcze aktualizator (codex app-server daemon pid-update-loop), który według zgłoszenia sprawdza nowe wydania 5 minut po starcie, a potem co godzinę, pobiera je i podmienia działającą usługę. Do tego podczas naszego testu demon samdogrywał jeszcze listę wtyczek, klonując repozytorium OpenAI gitem.

Żeby to wszystko wystartowało, nie trzeba było logować się na konto OpenAI. U nas demon stanął już na ekranie logowania, przy pierwszym uruchomieniu.

Czemu to przeszkadza

Sam w sobie proces w tle nie jest malwarem i komentarze pod zgłoszeniem dzielą się dokładnie w tym miejscu. Część osób pisze, że przeglądarki też aktualizują się same, więc to normalny kierunek. Do Codexa większość użytkowników i tak wchodzi przez plany ChatGPT, od darmowego po Pro, o których cenach pisaliśmy przy okazji wycieku planu za 500 dolarów, więc nie jest to gadżet dla garstki entuzjastów. Problem w tym, że Codex CLI to narzędzie, które ktoś instaluje świadomie, konkretną wersję, często przez menedżer pakietów, a demon tę umowę rozjeżdża w trzech miejscach.

Po pierwsze, wersja. Skoro usługa działa z kopii i aktualizuje się we własnym rytmie, to nie jest już ta wersja, którą zainstalowałeś i którą aktualizujesz menedżerem pakietów. Przy narzędziu programistycznym to realny problem: debugujesz zachowanie jednej wersji, a w tle pracuje inna. Po drugie, demon dziedziczy środowisko z sesji, która go pierwsza uruchomiła. Autor zgłoszenia uruchamia Codexa przez opakowanie ustawiające HTTPS_PROXY i jego demon na stałe poszedł przez proxy z pierwszego uruchomienia, niezależnie od tego, co ustawiały kolejne sesje. Tego przypadku sami nie odtwarzaliśmy, bierzemy go ze zgłoszenia, ale mechanizm jest logiczny: proces bez terminala nie ma skąd wziąć nowych zmiennych. Po trzecie, w linii poleceń demona wisi flaga --analytics-default-enabled. Nie audytowaliśmy ruchu sieciowego, więc nie wiemy, co ta flaga realnie wysyła, i piszemy tylko tyle, ile widać: jest tam.

Dwa drobiazgi mówią zresztą sporo o jakości wykonania. Komenda codex app-server daemon stop, która niby służy do sprzątania, zatrzymała u nas usługę, ale aktualizator zostawiła żywego; zabiliśmy go dopiero osobnym pkill. A flagi daemon_auto_start, czyli przełącznika, który to wszystko włącza, nie ma w oficjalnej referencji konfiguracji Codexa (sprawdzaliśmy 13 października). Jest w codex features list, oznaczona jako stabilna i domyślnie włączona.

Jak sprawdzić, czy masz demona

Na Linuksie i macOS wystarczy zajrzeć na listę procesów:

ps aux | grep "app-server-daemon"

Jeśli widzisz proces ze ścieżką ~/.codex/packages/app-server-daemon/... i fragmentem --managed-daemon, demon u ciebie działa. Drugi proces, z pid-update-loop na końcu, to aktualizator. Na Windowsie ten sam widok dasz w Menedżerze zadań: szukaj procesów codex, których ścieżka wskazuje na .codex\packages\, a nie na katalog npm. Ciekawskim polecam też rzut oka na rozmiar ~/.codex: jeśli packages liczy setki megabajtów, kopia stoi.

Jak go wyłączyć

Wyłączenie to trzy ruchy i jedna pułapka, którą zgłoszenie opisuje wprost i którą potwierdziliśmy. Najpierw przełącznik, żeby demon nie wrócił przy następnym starcie:

codex features disable daemon_auto_start

Komenda dopisuje do ~/.codex/config.toml sekcję [features] z daemon_auto_start = false. U nas po tej zmianie kolejne uruchomienia Codexa zostawiły system w spokoju, a nic nowego nie dokopiórowało się do packages.

Potem sprzątanie tego, co już działa. Komenda daemon stop ubija usługę, ale jak wspomnieliśmy wyżej, aktualizator ją przeżywa, więc potrzebny jest jeszcze osobny rzut na procesy Codexa. Na Linuksie i macOS załatwia to pkill -x codex (celuje po nazwie procesu, nie po fragmencie linii poleceń, co ma znaczenie, bo wzorzec z -f potrafi trafić we własne polecenie). Na Windowsie zakończ procesy codex w Menedżerze zadań. Na koniec można usunąć kopię, która siedzi w ~/.codex/packages/app-server-daemon/; przy wyłączonej fladze nic jej nie odtworzy, a z dysku schodzi pół gigabajta.

Ściąga w jednej tabeli:

CelKomenda
Wyłącz start demona na stałecodex features disable daemon_auto_start
Zatrzymaj działającą usługęcodex app-server daemon stop
Dobij ocalały aktualizatorpkill -x codex (Linux, macOS)
Usuń kopię pakietu (ok. 432 MB)usuń ~/.codex/packages/app-server-daemon/
Stylizowana mapa ścieżki wyłączania demona Codex CLI w trzech krokach: wyłączenie flagi daemon_auto_start, zatrzymanie procesów pkill, usunięcie katalogu packages, na końcu stan oznaczony jako czysto
Ilustracja stylizowana, nie zrzut ekranu. Komendy w tekście i tabeli powyżej.

Groźne czy niewygodne

Uczciwie: to raczej niewygodne niż niebezpieczne. Proces działa lokalnie, kod Codexa jest otwarty na GitHubie, a pomysł na wspólną usługę ma swoje uzasadnienie, z niej korzysta zdalne sterowanie i aplikacja desktopowa. Zgłoszenie wprost sugeruje, żeby zostawić demon tam, gdzie ma sens, i zrobić z niego opcję, a nie wymuszenie.

Przyzwyczailiśmy się trochę, że narzędzia AI traktują nasz komputer jak swój. Tu jest narzędzie wiersza poleceń, instalowane świadomie przez programistów, i ono przy pierwszym uruchomieniu podwaja swoje rozmiary, zostawia usługę bez pytania i podmienia sobie wersje w tle, a jedyny przełącznik jest poza oficjalną dokumentacją. Kto nie chce takich niespodzianek od narzędzi w chmurze, ma zresztą prostą alternatywę: modele działające lokalnie, bez żadnych usług w tle, opisywaliśmy je przy okazji testu lokalnych modeli na własnym komputerze.

Zgłoszenie jest otwarte od 25 września i OpenAI nie odpowiedziało na nim ani słowem przez niemal trzy tygodnie, także po tym, jak wyszło na front Hacker News. Flaga jest jedna komenda od wyłączenia, więc na razie temat zamyka się na poziomie konfiguracji. Gdy OpenAI zmieni domyślne zachowanie albo odpowie, zaktualizujemy ten tekst.

Nota uczciwości

Test przeprowadziliśmy 13 października 2026 na Linuksie x86_64, na Codex CLI 0.162.1 zainstalowanym przez npm, bez zalogowanego konta OpenAI. Nie podsłuchiwaliśmy ruchu sieciowego demona, więc opis flagi analytics ogranicza się do tego, co widać w linii poleceń. Mechanizm dziedziczenia proxy cytujemy za zgłoszeniem, sami go nie odtwarzaliśmy. Szczegóły dla Windowsa pochodzą ze zgłoszenia i komentarzy jego użytkowników. Opisy zachowań demona, jak rytm aktualizacji czy przetrwanie restartu, pochodzą ze zgłoszenia; wszystko, co zaznaczone jako nasz test, odtworzyliśmy sami.

Źródła

Powiązane artykuły