Omówienie
Codex odpowiada za natywną pętlę modelu, natywne wznawianie wątków, natywną kontynuację narzędzi oraz natywną Compaction. OpenClaw odpowiada za routing kanałów, pliki sesji, dostarczanie widocznych wiadomości, dynamiczne narzędzia OpenClaw, zatwierdzenia, dostarczanie multimediów oraz kopię transkrypcji obejmującą tę granicę. Routing promptów zależy od wybranego środowiska wykonawczego, a nie tylko od ciągu identyfikującego dostawcę. Natywna tura Codex otrzymuje instrukcje deweloperskie serwera aplikacji Codex. Jawna ścieżka zgodności OpenClaw zachowuje zwykły prompt systemowy OpenClaw, nawet jeśli używa uwierzytelniania lub transportu OpenAI w wariancie Codex. OpenClaw uruchamia i wznawia natywne wątki Codex z wyłączoną wbudowaną osobowością Codex (personality: "none"), dzięki czemu nadrzędne pozostają
pliki osobowości przestrzeni roboczej oraz tożsamość agenta OpenClaw. Poza tym
natywny Codex zachowuje bazowe instrukcje i instrukcje modelu należące do Codex
oraz wczytywanie dokumentacji projektu. Lekkie uruchomienia OpenClaw
(np. cron) nadal pomijają wczytywanie dokumentacji projektu.
Instrukcje deweloperskie OpenClaw obejmują zagadnienia środowiska wykonawczego
OpenClaw: dostarczanie do kanału źródłowego, dynamiczne narzędzia OpenClaw,
delegowanie ACP, kontekst adaptera oraz aktywne pliki profilu przestrzeni
roboczej agenta. Katalogi Skills i wskaźniki do MEMORY.md obsługiwane przez
narzędzia są przekazywane jako instrukcje deweloperskie współpracy ograniczone
do danej tury. Gdy narzędzia pamięci są niedostępne, aktywna zawartość
BOOTSTRAP.md oraz pełny plik MEMORY.md są zamiast tego przekazywane jako
zwykły kontekst wejściowy tury.
Większość dynamicznych narzędzi OpenClaw używa przeszukiwalnej przestrzeni nazw
openclaw. Narzędzia oznaczone jako catalogMode: "direct-only" używają
openclaw_direct, którą Codex zachowuje jako bezpośrednio widoczną dla modelu
wartość DirectModelOnly, zamiast udostępniać ją zagnieżdżonemu wykonywaniu
w trybie Code Mode.
Powiązania wątków i zmiany modelu
Gdy sesja OpenClaw jest dołączona do istniejącego wątku Codex, następna tura ponownie przesyła do serwera aplikacji aktualnie wybrany model, zasady zatwierdzania, piaskownicę, recenzenta zatwierdzeń oraz poziom usługi. Zmiana zopenai/gpt-5.5 na openai/gpt-5.2 zachowuje powiązanie wątku, ale nakazuje
Codex kontynuowanie pracy z nowo wybranym modelem.
Wyjątkiem są powiązania nadzorowane. Selektor modelu OpenClaw pozostaje
zablokowany, a wznowienia pomijają nadpisania modelu i dostawcy, dzięki czemu
Codex przywraca utrwalony model i dostawcę kanonicznego wątku. Osobny natywny
mechanizm sterujący Codex może zmienić tę utrwaloną parę, a początkowa migawka
może wywołać standardowe ostrzeżenie Codex o różnicy modeli. Zewnętrzny model
OpenClaw ani łańcuch modeli rezerwowych nigdy nie zastępują żadnego z tych
elementów.
Nadzór i bezpieczna kontynuacja
Nadzór Codex to opcjonalna funkcja tego samego pluginucodex. Wykrywa natywne
wątki przez osobne połączenie i przekazuje do katalogu Gateway wyłącznie
niezarchiwizowane sesje. Bez jawnych ustawień połączenia appServer połączenie
to używa zarządzanego standardowego wejścia i wyjścia w katalogu domowym
użytkownika, natomiast zwykły mechanizm pozostaje ograniczony do agenta.
Wyświetlanie listy i odczyty metadanych są pasywne: nie wznawiają wątku, nie
subskrybują OpenClaw do jego zdarzeń na żywo ani nie odpowiadają na jego prośby
o zatwierdzenie.
W przypadku zapisanej lub bezczynnej sesji na komputerze z Gateway opcja
Kontynuuj jako gałąź tworzy zwykły czat z zablokowanym modelem i kopiuje
ograniczoną historię użytkownika oraz asystenta do ostatniej utrwalonej,
zakończonej tury źródła. Pierwsza zwykła tura czatu instaluje właściwe
procedury obsługi zatwierdzeń i używa tymczasowej natywnej kopii wątku, aby
przypiąć migawkę bez nadpisywania modelu ani dostawcy. Codex App Server używa
swojej bieżącej konfiguracji natywnej i zwraca wybraną parę. Jeśli model różni
się od ostatniego modelu zapisanego dla źródła, emituje standardowe ostrzeżenie.
W ramach tego samego połączenia nadzoru OpenClaw uruchamia kanoniczny wątek
mechanizmu Codex ze źródłem appServer, używając jego katalogu roboczego
i zasad środowiska wykonawczego oraz dokładnie zwróconego modelu i dostawcy dla
tego początkowego uruchomienia, wstrzykuje ograniczoną widoczną historię
i archiwizuje tymczasową kopię wątku. Źródło nigdy nie jest wznawiane.
Kanoniczny wątek ma dostęp do pełnego zestawu narzędzi mechanizmu OpenClaw.
Rozumowanie, wywołania narzędzi i wyniki narzędzi ze źródła nie są do niego
kopiowane. Prywatny zakres połączenia pozostaje zachowany zarówno w oczekującym,
jak i zatwierdzonym stanie powiązania, dlatego każda późniejsza tura nadal
korzysta z tego połączenia wraz z natywnym uwierzytelnianiem i konfiguracją
dostawcy. Wyłączony nadzór lub rozbieżność powiązania bądź połączenia powodują
bezpieczne przerwanie działania zamiast przełączenia na zwykły mechanizm
w katalogu domowym agenta.
Pierwotne źródło CLI lub VS Code nadal może znajdować się w obu katalogach.
Kanoniczna gałąź jest natywnym wątkiem Codex, ale jej rodzaj źródła to
appServer. Klienci natywni mogą filtrować ten rodzaj źródła, dlatego nie ma
gwarancji, że pojawi się ona w Codex Desktop.
Aktywne źródła nie mogą rozpoczynać nowej gałęzi ani być archiwizowane. Nadal
można otworzyć istniejący nadzorowany czat. notLoaded oznacza, że aktywność
jest nieznana, a nie że sesja jest bezczynna. OpenClaw zezwala na archiwizację
lokalnego wiersza idle lub notLoaded dopiero po jawnym potwierdzeniu braku
innego procesu wykonawczego oraz ponownym, lokalnym dla procesu odczycie stanu.
Codex serializuje modyfikacje wątków w obrębie jednego procesu App Server, ale
nie zapewnia wyłącznej dzierżawy między procesami dla procesu wykonawczego ani
właściciela zatwierdzeń, dlatego ten odczyt nie może dowieść, że inny proces nie
korzysta z wątku. OpenClaw blokuje znanego aktywnego właściciela powiązania dla
dokładnie wskazanego celu lub dowolnego niezarchiwizowanego potomka utworzonego
przez ten cel i zwróconego przez stronicowane zapytanie Codex o potomków. Błędy
wyliczania, cykle i wyczerpanie limitu bezpieczeństwa powodują bezpieczne
przerwanie działania. Natywna archiwizacja nadal może wejść w konflikt z nową
turą w innym procesie, dlatego potwierdzenie obejmuje nieznanych klientów oraz
przedział między odczytem stanu a archiwizacją. Nadzorowanego czatu
z zablokowanym modelem nie można usunąć, dopóki chroni natywne powiązanie.
Katalogi sparowanych Node w pierwszym wydaniu zawierają wyłącznie metadane.
Obecna granica wywołań Node działa w modelu żądanie/odpowiedź i nie może
przenosić długotrwałych zdarzeń tury, próśb o zatwierdzenie ani strumieniowego
wyjścia wymaganych przez rzeczywiste powiązanie mechanizmu Codex. Zdalne opcje
Kontynuuj i Archiwizuj pozostają zatem niedostępne nawet wtedy, gdy
wiersz jest bezczynny.
Informacje o konfiguracji dla operatora i widocznym działaniu interfejsu
sterowania zawiera strona Nadzór Codex.
Widoczne odpowiedzi i Heartbeat
Bezpośrednie i źródłowe tury czatu obsługiwane przez mechanizm Codex domyślnie automatycznie dostarczają końcową odpowiedź asystenta do wewnętrznych interfejsów WebChat, zgodnie z kontraktem mechanizmu Pi: agent odpowiada normalnie, a OpenClaw publikuje końcowy tekst w rozmowie źródłowej. Ustawmessages.visibleReplies: "message_tool", aby końcowy tekst asystenta pozostał
prywatny, chyba że agent wywoła message(action="send").
Tury Heartbeat Codex domyślnie otrzymują heartbeat_respond w przeszukiwalnym
katalogu narzędzi OpenClaw, dzięki czemu agent może zapisać, czy wybudzenie ma
pozostać ciche, czy wysłać powiadomienie. Wskazówki dotyczące inicjatywy
Heartbeat są przesyłane jako instrukcja deweloperska trybu współpracy Codex
ograniczona do tury Heartbeat. Zwykłe tury czatu pozostają w domyślnym trybie
Codex. Gdy plik HEARTBEAT.md nie jest pusty, instrukcje Heartbeat wskazują
Codex ten plik zamiast umieszczać jego zawartość bezpośrednio w instrukcjach.
Granice hooków
OpenClaw nie używa projektowych ani globalnych plików Codex
hooks.json do
routingu zachowania pluginów. Dla mostu natywnych narzędzi i uprawnień OpenClaw
wstrzykuje konfigurację Codex dla poszczególnych wątków dotyczącą
PreToolUse, PostToolUse, PermissionRequest i Stop.
Gdy zatwierdzenia App Server Codex są włączone (approvalPolicy nie ma
wartości "never"), domyślna wstrzykiwana konfiguracja natywnych hooków pomija
PermissionRequest, dzięki czemu recenzent App Server Codex i most zatwierdzeń
OpenClaw obsługują rzeczywiste eskalacje po przeglądzie. Dodaj
permission_request do nativeHookRelay.events, aby mimo to wymusić
przekaźnik zgodności. Inne hooki Codex, takie jak SessionStart
i UserPromptSubmit, pozostają mechanizmami sterującymi na poziomie Codex.
W kontrakcie v1 nie są udostępniane jako hooki pluginów OpenClaw.
W przypadku dynamicznych narzędzi OpenClaw to OpenClaw wykonuje narzędzie po
zażądaniu wywołania przez Codex, dlatego zachowanie pluginu i middleware jest
realizowane w adapterze mechanizmu. W przypadku narzędzi natywnych Codex to
Codex jest właścicielem kanonicznego rekordu narzędzia. OpenClaw może kopiować
wybrane zdarzenia, ale nie może zmieniać natywnego wątku, chyba że Codex
udostępni taką możliwość przez App Server lub wywołania zwrotne natywnych
hooków.
Zdarzenia PreToolUse App Server Codex w trybie raportowania odraczają
zatwierdzenie pluginu do odpowiadającego mu zatwierdzenia App Server. Jeśli hook
OpenClaw before_tool_call zwróci requireApproval, gdy natywne dane zawierają
openclaw_approval_mode: "report", przekaźnik natywnego hooka zapisuje wymóg
zatwierdzenia pluginu i nie zwraca natywnej decyzji. Gdy Codex później wyśle
żądanie zatwierdzenia App Server dotyczące tego samego użycia narzędzia,
OpenClaw otwiera monit o zatwierdzenie pluginu i odwzorowuje decyzję z powrotem
do Codex. Zdarzenia Codex PermissionRequest stanowią osobną ścieżkę
zatwierdzania i po skonfigurowaniu tego mostu nadal mogą być kierowane przez
zatwierdzenia OpenClaw.
Powiadomienia o elementach App Server Codex zapewniają także asynchroniczne
obserwacje after_tool_call dotyczące zakończenia działania natywnych narzędzi,
które nie zostały już obsłużone przez natywny przekaźnik PostToolUse. Służą
one wyłącznie do telemetrii i zgodności. Nie mogą blokować, opóźniać ani
modyfikować wywołania natywnego narzędzia.
Projekcje Compaction i cyklu życia LLM pochodzą z powiadomień App Server Codex
oraz stanu adaptera OpenClaw, a nie z poleceń natywnych hooków Codex.
before_compaction, after_compaction, llm_input i llm_output są
obserwacjami na poziomie adaptera, a nie dokładnymi co do bajtu kopiami
wewnętrznych żądań lub danych Compaction Codex.
Natywne powiadomienia App Server Codex hook/started i hook/completed są
przekazywane jako zdarzenia agenta codex_app_server.hook na potrzeby śledzenia
przebiegu i debugowania. Nie wywołują hooków pluginów OpenClaw.
Kontrakt obsługi wersji V1
Obsługiwane w środowisku wykonawczym Codex v1:
Nieobsługiwane w środowisku wykonawczym Codex v1:
Natywne uprawnienia i żądania pozyskania danych MCP
W przypadkuPermissionRequest OpenClaw zwraca jawne decyzje zezwalające lub
odmawiające tylko wtedy, gdy określa je polityka. Brak decyzji nie oznacza
zezwolenia: Codex traktuje go jako brak decyzji hooka i przechodzi do własnej
ścieżki mechanizmu ochronnego lub zatwierdzenia przez użytkownika.
Tryby zatwierdzania Codex app-server domyślnie pomijają ten natywny hook.
Ma to zastosowanie, chyba że permission_request zostanie jawnie uwzględnione
w nativeHookRelay.events lub zostanie zainstalowane przez zgodnościowe środowisko wykonawcze.
Gdy operator wybierze allow-always dla żądania natywnego uprawnienia Codex,
OpenClaw zapamiętuje dokładny odcisk danych wejściowych dostawcy, sesji,
narzędzia i cwd przez ograniczony czas sesji. Zapamiętana decyzja celowo
obowiązuje tylko dla dokładnego dopasowania: zmiana polecenia, argumentów,
ładunku narzędzia lub cwd powoduje utworzenie nowego żądania zatwierdzenia.
Żądania zatwierdzenia narzędzi Codex MCP są kierowane przez przepływ
zatwierdzania pluginów OpenClaw, gdy Codex oznaczy
_meta.codex_approval_kind jako "mcp_tool_call". Prompty Codex
request_user_input są odsyłane do czatu źródłowego, a następna wiadomość
oczekująca w kolejce odpowiada na to żądanie natywnego serwera, zamiast być
przekazywana jako dodatkowy kontekst. Inne żądania pozyskania danych MCP są
domyślnie odrzucane.
Ogólny przepływ zatwierdzania pluginów, który przenosi te prompty, opisano w
sekcji Żądania uprawnień pluginów.
Sterowanie kolejką
Sterowanie kolejką aktywnego uruchomienia jest odwzorowywane naturn/steer w Codex app-server. Przy domyślnym ustawieniu
messages.queue.mode: "steer" OpenClaw grupuje wiadomości czatu w trybie
sterowania w skonfigurowanym okresie bezczynności i wysyła je jako jedno
żądanie turn/steer w kolejności nadejścia.
Tury przeglądu Codex i ręcznej Compaction mogą odrzucać sterowanie w tej samej turze. W
takim przypadku OpenClaw czeka na zakończenie aktywnego przebiegu przed rozpoczęciem
przetwarzania monitu. Użyj /queue followup lub /queue collect, gdy wiadomości mają być domyślnie
kolejkowane zamiast służyć do sterowania. Zobacz Kolejka sterowania.
Przesyłanie opinii Codex
Gdy/diagnostics [note] zostanie zatwierdzone dla sesji w natywnym środowisku
Codex, OpenClaw wywołuje również feedback/upload serwera aplikacji Codex dla odpowiednich
wątków Codex, dołączając dzienniki każdego wymienionego wątku oraz utworzonych
podwątków Codex, jeśli są dostępne.
Przesyłanie odbywa się zwykłą ścieżką opinii Codex do serwerów OpenAI. Jeśli
opinie Codex są wyłączone na tym serwerze aplikacji, polecenie zwraca błąd
serwera aplikacji. Odpowiedź po zakończeniu diagnostyki zawiera kanały,
identyfikatory sesji OpenClaw, identyfikatory wątków Codex oraz lokalne polecenia
codex resume <thread-id> dla wysłanych wątków.
Jeśli odrzucisz lub zignorujesz zatwierdzenie, OpenClaw nie wyświetli tych identyfikatorów Codex
ani nie wyśle opinii Codex. Przesyłanie nie zastępuje lokalnego
eksportu diagnostyki Gateway. Informacje o zatwierdzaniu, prywatności, lokalnym pakiecie
i działaniu w czatach grupowych zawiera Eksport diagnostyki.
Używaj /codex diagnostics [note] tylko wtedy, gdy chcesz przesłać opinię Codex
dla aktualnie dołączonego wątku bez pełnego pakietu diagnostyki Gateway.
Compaction i kopia transkrypcji
Gdy wybrany model korzysta ze środowiska Codex, natywna Compaction wątku należy do serwera aplikacji Codex. OpenClaw nie uruchamia wstępnej Compaction dla tur Codex, nie zastępuje Compaction Codex kompresją silnika kontekstu ani nie korzysta awaryjnie z podsumowywania OpenClaw lub publicznego podsumowywania OpenAI, gdy nie można uruchomić natywnej Compaction. OpenClaw przechowuje kopię transkrypcji na potrzeby historii kanału, wyszukiwania,/new, /reset oraz przyszłego przełączania modelu lub środowiska.
Jawne żądania Compaction, takie jak /compact lub ręczna operacja
Compaction zażądana przez plugin, uruchamiają natywną Compaction Codex za pomocą thread/compact/start.
OpenClaw utrzymuje żądanie i dzierżawę współdzielonego klienta do czasu, aż Codex wyemituje
pasujący element ukończenia contextCompaction, a następnie zgłasza turę Compaction
jako zakończoną. Jeśli ta końcowa tura przekroczy skonfigurowany limit czasu
Compaction, OpenClaw żąda natywnego przerwania tury. Dzierżawa i blokada
Compaction dla danego wątku pozostają utrzymane, dopóki Codex nie zgłosi stanu końcowego lub nie potwierdzi
wywołania RPC przerwania. Jeśli Codex nie potwierdzi go w okresie karencji
przerwania, OpenClaw wycofuje połączenie przed zwolnieniem blokady. Połączenia
zdalne odłączają również powiązanie odpowiedniego wątku, aby późniejsze operacje nie mogły
nakładać się na niepotwierdzoną zdalną turę. Inne tury w wycofanym połączeniu kończą się
niepowodzeniem i mogą zostać ponowione przy użyciu nowego klienta. Zamknięcie klienta, anulowanie żądania lub
nieudana tura Compaction zwraca operację zakończoną niepowodzeniem. Automatyczna Compaction pod presją
kontekstu należy do Codex; OpenClaw uruchamia natywną Compaction wyłącznie dla ręcznie
żądanych wyzwalaczy.
Gdy silnik kontekstu żąda projekcji inicjalizacyjnej wątku Codex, OpenClaw
projektuje nazwy i identyfikatory wywołań narzędzi, struktury danych wejściowych oraz zredagowaną zawartość
wyników narzędzi do nowego wątku Codex. Nie kopiuje do tej projekcji nieprzetworzonych wartości
argumentów wywołań narzędzi.
Kopia zawiera monit użytkownika, końcowy tekst asystenta oraz uproszczone
rekordy rozumowania lub planu Codex, gdy serwer aplikacji je emituje. OpenClaw
rejestruje rozpoczęcie i końcowy stan natywnej Compaction, ale nie
udostępnia czytelnego dla człowieka podsumowania Compaction ani możliwej do audytu listy wpisów,
które Codex zachował po Compaction.
Ponieważ Codex jest właścicielem kanonicznego natywnego wątku, tool_result_persist nie
przepisuje natywnych rekordów wyników narzędzi Codex. Ma zastosowanie tylko wtedy, gdy OpenClaw
zapisuje wynik narzędzia w transkrypcji sesji należącej do OpenClaw.
Multimedia i dostarczanie
OpenClaw nadal odpowiada za dostarczanie multimediów i wybór ich dostawcy. Generowanie obrazów, wideo, muzyki i plików PDF, TTS oraz rozumienie multimediów używają odpowiednich ustawień dostawcy/modelu, takich jakagents.defaults.imageGenerationModel,
videoGenerationModel, pdfModel i messages.tts.
Tekst, obrazy, wideo, muzyka, TTS, zatwierdzenia i dane wyjściowe narzędzi komunikacyjnych nadal
przechodzą zwykłą ścieżką dostarczania OpenClaw; generowanie multimediów nie wymaga
starszego środowiska uruchomieniowego. Gdy Codex emituje natywny element generowania obrazu z
savedPath, OpenClaw przekazuje ten dokładny plik zwykłą ścieżką multimediów odpowiedzi,
nawet jeśli tura Codex nie zawiera tekstu asystenta.