Hooki Codex czynią harness realnym

Według stanu na Codex 0.150.1 (27 sierpnia 2026) hooki Codex rejestrują dwanaście zdarzeń cyklu życia, odmawiają uruchomienia jakiegokolwiek niezarządzanego hooka, dopóki jego dokładna definicja nie zostanie przejrzana i obdarzona zaufaniem, i są domyślnie włączone. Funkcja, która trafiła do ogólnej dostępności w pakiecie premierowym z 14 maja obok mobilnej aplikacji ChatGPT, dojrzała do rangi powierzchni nadzoru: PreToolUse może zablokować lub przepisać wywołanie narzędzia, zanim ono ruszy, PermissionRequest może rozstrzygnąć zatwierdzenie, PostToolUse może podmienić wynik, który widzi model, a Stop może odmówić zakończenia tury.²³

Codex nie wygląda już jak asystent programowania czekający w jednym terminalu. Wygląda jak warstwa operacyjna, która podąża za pracą poprzez maszyny, zatwierdzenia, projekty, czaty, diffy, testy, zrzuty ekranu, pluginy, poświadczenia i lokalne narzędzia.⁴

Hooki Codex czynią harness realnym. Gdy agent potrafi pracować z telefonu, sięgać do zdalnych środowisk deweloperskich i uruchamiać hooki cyklu życia, zespoły potrzebują wokół modelu systemu kontroli: dowodów, zatwierdzeń, nadzoru nad git, dyscypliny źródeł i gustu.

TL;DR

Codex wspiera kształt przepływu pracy, który zespoły agentowe budowały dotąd prywatnie: długotrwałą pracę, zdalne wykonanie, sterowanie z telefonu, zatwierdzenia, hooki, poświadczenia o ograniczonym zakresie i sygnały audytowe.²⁴⁵ Silnik hooków w wersji 0.150.0 rejestruje dwanaście zdarzeń, każdy niezarządzany hook pozostaje pomijany, dopóki nie zostanie zaufany jego aktualny hash, a hooki ładują się z plików hooks.json lub z wpisanych bezpośrednio tabel [hooks] w config.toml.³⁷ Praktyczne pytanie nie brzmi „jak promptować Codex?”. Praktyczne pytanie brzmi „czego Codex musi dowieść, zanim zaufamy wynikowi?”. Zespoły powinny używać hooków i konfiguracji do zakodowania bram przeglądu, granic bezpieczeństwa, standardów publicznego pisania i dyscypliny wydań. Prywatną maszynerię należy zostawić prywatną, a publikować jedynie wzorzec, kryteria akceptacji i zweryfikowany rezultat.

Najważniejsze wnioski

Dla zespołów inżynieryjnych: - Hooki Codex należy traktować jako infrastrukturę procesu, nie dekorację. Przepływ przeglądu zaufania jest częścią tej infrastruktury, a nie tarciem do obejścia. - Warto zacząć od dowodów, zatwierdzeń, nadzoru nad git i kontroli wydań, zanim dojdzie sprytna automatyzacja.

Dla twórców narzędzi agentowych: - Należy budować wokół rzeczywistych powierzchni Codex: sterowania mobilnego, zdalnych hostów SSH, trybów sandboxa, polityk zatwierdzeń, instrukcji projektowych, hooków, telemetrii i kontroli wersji. - Przenosić należy zadania do wykonania, a nie dawne kształty slash-komend.

Dla piszących publicznie: - Do bieżącego zachowania Codex warto sięgać po oficjalną dokumentację na learn.chatgpt.com, a gdy dokumentacja nie nadąża za wydaniem, sprawdzać źródła silnika. - Prywatną praktykę należy opisywać jako analizę autora, a prywatne prompty, treści hooków, ścieżki plików, listy źródeł, poświadczenia i wewnętrzne mechanizmy oceniania zostawić poza publicznym tekstem.

Skąd wzięły się hooki Codex?

OpenAI opublikowało „Work with Codex from anywhere” 14 maja 2026.¹ Wpis changelogu dokumentacji z tej daty odnotowuje pakiet premierowy: Codex stał się dostępny z mobilnej aplikacji ChatGPT po połączeniu z komputerem Mac, na którym działa aplikacja Codex, hooki osiągnęły ogólną dostępność, a dla zaufanej automatyzacji pojawiły się tokeny dostępu Codex.² Codex działa z połączonego hosta, więc z telefonu dostępne są te same projekty, pliki, poświadczenia, pluginy, umiejętności i konfiguracja.²

Zdalne połączenia wydłużają zasięg poza jedno biurko. Zapowiedziana w ogłoszeniu funkcja Remote SSH ląduje w dokumentacji jako hosty SSH: aplikacja desktopowa ChatGPT może dodawać zdalne projekty z hosta SSH i prowadzić czaty na zdalnym systemie plików i zdalnej powłoce. Ujęcie jest konkretne: “Remote access uses the connected host’s projects, chats, files, credentials, permissions, plugins, Computer Use, browser setup, and local tools.” (zdalny dostęp korzysta z projektów, czatów, plików, poświadczeń, uprawnień, pluginów, Computer Use, konfiguracji przeglądarki i lokalnych narzędzi połączonego hosta).⁴

Same hooki poprzedzają premierę jako eksperyment, a po niej z niego wyrosły. Dokumentacja definiuje je jako framework rozszerzalności uruchamiający skrypty lub narzędzia MCP podczas pętli agentowej i nazywa zwyczajne zadania: wysyłanie czatów do silnika logowania, blokowanie przypadkowo wklejonych kluczy API, streszczanie czatów do trwałych wspomnień, uruchamianie kontroli walidacyjnej, gdy tura się zatrzymuje, oraz dostosowywanie promptowania per katalog.³ Hooki są teraz domyślnie włączone; features.hooks w config.toml działa jako wyłącznik awaryjny, a features.codex_hooks przetrwał już tylko jako przestarzały alias.³⁶

Te szczegóły mają znaczenie, bo zamieniają pracę agenta z wymiany zdań na czacie w nadzorowane operacje.

Jak wyglądają hooki Codex w konfiguracji?

Wpis o hookach powinien pokazać hooka. Codex odkrywa hooki obok aktywnych warstw konfiguracji, najużyteczniej w ~/.codex/hooks.json, <repo>/.codex/hooks.json lub w tabelach wpisanych bezpośrednio w config.toml którejkolwiek warstwy; gdy istnieje kilka źródeł, ładują się i działają wszystkie pasujące hooki.³ Minimalny hooks.json z bramą narzędzi i bramą ukończenia:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "^Bash$",
        "hooks": [
          {
            "type": "command",
            "command": "python3 ~/.codex/hooks/pre_tool_use_policy.py",
            "timeout": 30,
            "statusMessage": "Checking Bash command"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python3 ~/.codex/hooks/evidence_gate.py"
          }
        ]
      }
    ]
  }
}

Ten sam kształt zapisany bezpośrednio w config.toml:

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 ~/.codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking Bash command"

Każdy hook porządkują trzy poziomy: zdarzenie, grupa matcherów decydująca, kiedy zdarzenie ma zastosowanie, oraz jeden lub więcej handlerów (command lub mcp_tool).³ Bieżące zdarzenia, z dwunastoelementową listą silnika jako autorytetem:³⁷

Aktualna dokumentacja hooków wciąż opisuje jedenaście z tych zdarzeń; nie ma jeszcze sekcji Interrupt. Dwunaste niosą wpis changelogu 0.150.0 (#40511) oraz HOOK_EVENT_NAMES: [&str; 12] w źródłach silnika przy rust-v0.150.0.²⁷ Gdy strona i silnik się nie zgadzają, należy ufać silnikowi.

Które wywołania narzędzi hooki faktycznie widzą?

Wcześniejsze wersje dokumentacji ostrzegały, że PreToolUse obejmuje niewiele poza wywołaniami powłoki i MCP. Bieżący dokument poszerza tę powierzchnię: “PreToolUse and PostToolUse can observe more than shell and MCP calls. Most local function tools use the same hook path,” (PreToolUse i PostToolUse widzą więcej niż wywołania powłoki i MCP; większość lokalnych narzędzi funkcyjnych używa tej samej ścieżki hooków), więc matcher może wskazać bezpośrednio narzędzia takie jak update_plan, a spawn_agent dopasowuje się też jako Agent.³ Polecenia powłoki dopasowują się jako Bash, edycje plików przez apply_patch jako apply_patch, Edit lub Write, a narzędzia MCP jako nazwy w rodzaju mcp__filesystem__read_file.³

Narzędzia hostowane pozostają na zewnątrz: WebSearch i jego odpowiedniki nigdy nie przechodzą lokalną ścieżką hooków narzędzi funkcyjnych.³ Dokument zachowuje złagodzone zastrzeżenie warte zacytowania w całości: “Some specialized tool paths can opt out of the default hook path. Treat tool hooks as a useful guardrail, not a complete enforcement boundary.” (niektóre wyspecjalizowane ścieżki narzędzi mogą wypisać się z domyślnej ścieżki hooków; hooki narzędzi należy traktować jako użyteczną barierę ochronną, a nie kompletną granicę egzekwowania).³ Twardą granicę wciąż wyznacza sandboxing; hooki odpowiadają za przegląd i sterowanie wewnątrz niej.

Jak Codex decyduje, które hooki mogą działać?

Hooki to kod, który steruje agentem, więc Codex nadzoruje same hooki. System kontroli wokół modelu zaczyna się właśnie tutaj.

Zanim jakikolwiek niezarządzany hook się uruchomi, Codex wymaga przejrzenia i zaufania jego dokładnej definicji. Zaufanie jest zapisywane względem aktualnego hasha hooka, więc nowy lub zmieniony hook zostaje oznaczony do przeglądu i jest pomijany, dopóki nie zostanie ponownie obdarzony zaufaniem.³ Polecenie /hooks w CLI otwiera powierzchnię przeglądu: można obejrzeć źródła hooków, przejrzeć nowe lub zmienione, zaufać im albo wyłączyć pojedyncze. Gdy przy starcie hooki wymagają przeglądu, Codex drukuje ostrzeżenie wskazujące na /hooks.³

Hooki zarządzane, pochodzące ze źródeł systemowych, MDM, chmurowych lub z requirements.toml, stoją ponad tym przepływem: są zaufane z mocy polityki i nie da się ich wyłączyć z przeglądarki hooków użytkownika.³ Pluginy siedzą wewnątrz niego: instalacja lub włączenie pluginu nie ufa jego dołączonym hookom, które pozostają pomijane do czasu przeglądu jak każde inne.³ Hooki lokalne projektu ładują się tylko wtedy, gdy warstwa .codex/ projektu jest zaufana; niezaufany projekt nadal ładuje hooki użytkownika i systemowe.³

Automatyzacja podlega tej samej regule. Uruchomienie codex exec nie ma UI przeglądu, więc niezaufany hook jest pomijany po cichu, dopóki nie zostanie najpierw zaufany w sesji interaktywnej; dokumentacja jeszcze tego nie mówi, ale startowa powierzchnia przeglądu silnika istnieje wyłącznie w interaktywnym TUI.⁷ Dla potoków, które weryfikują źródła hooków gdzie indziej, --dangerously-bypass-hook-trust uruchamia włączone hooki bez utrwalonego zaufania na czas jednego wywołania.³ Zaufanie trzeba nadawać świadomie albo patrzeć, jak brama nie odpala: harness decyduje, który kod może sterować agentem, zanim jakikolwiek z nich ruszy.

Co się dzieje, gdy hook blokuje, i kiedy jest już za późno?

O tym, co hook może jeszcze zmienić, decyduje moment. Większość hooków działa synchronicznie z domyślnym timeoutem 600 sekund; SessionEnd i Interrupt mają domyślnie jedną sekundę i limit trzech: SessionEnd odpala, gdy sesja właśnie się zwija, a Interrupt, gdy użytkownik czeka.³⁷

PreToolUse działa, zanim cokolwiek się wydarzy, więc trzyma najmocniejsze karty: odmówić wywołania albo przepisać je, zwracając permissionDecision: "allow" z updatedInput. Kształt odmowy:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Destructive command blocked by hook."
  }
}

Blokuje też kod wyjścia 2 z powodem na stderr.³

PostToolUse działa po uruchomieniu narzędzia, więc nie cofnie skutków ubocznych. decision: "block" podmienia wynik narzędzia na przekazaną informację zwrotną i prowadzi model dalej od tej wiadomości, co koryguje kurs bez udawania, że polecenia nigdy nie było.³ Stop zamienia odmowę w kontynuację: zablokowanie ukończenia sprawia, że Codex pracuje dalej, z podanym powodem jako nowym promptem.³

Dla kontroli, które nigdy nie powinny siedzieć na ścieżce krytycznej, można ustawić async = true na handlerze poleceń. Hooki w tle działają, podczas gdy Codex kontynuuje, dostarczają wynik w najbliższym bezpiecznym punkcie i jawnie nie mogą niczego blokować, zatwierdzać ani przepisywać; polityki narzędzi, decyzje o uprawnieniach, odrzucanie promptów i kontynuację tury należy trzymać synchronicznie.

Co zmieniło się w wersjach 0.149 i 0.150?

Dwa stabilne wydania z końca sierpnia zacieśniły historię nadzoru.

Codex CLI 0.149.0 (20 sierpnia 2026) wycofał politykę zatwierdzeń untrusted (#39630); konfiguracja, która wciąż ją wymienia, kończy się teraz czytelnym błędem z instrukcją usunięcia ustawienia.²⁷ Codex CLI 0.150.0 (26 sierpnia 2026) dodał zdarzenie hooka Interrupt (#40511): “New Interrupt hooks can run commands or MCP handlers when an active top-level turn is interrupted.” (nowe hooki Interrupt mogą uruchamiać polecenia lub handlery MCP, gdy aktywna tura najwyższego poziomu zostaje przerwana). Hooki Interrupt nigdy nie działają dla subagentów.²⁷ To samo wydanie odebrało niezaufanym projektom możliwość dostarczania projektowych instrukcji AGENTS.md (#39837), co współgra z istniejącą regułą, że hooki lokalne projektu ładują się tylko z zaufanej warstwy .codex/.²³

Kierunek jest spójny: niezaufany katalog dostaje coraz mniej władzy nad agentem, który do niego wchodzi. Instrukcje, hooki i skróty zatwierdzeń przepływają teraz przez jawne decyzje o zaufaniu.

Dlaczego hooki znaczą więcej niż dostęp mobilny?

Dostęp mobilny zmienia to, gdzie człowiek może interweniować. Hooki zmieniają to, co system może egzekwować.

Telefon pozwala operatorowi odpowiedzieć na pytanie z dala od biurka. Hook potrafi złapać agenta przed ryzykowną akcją, po edycji pliku, przed ukończeniem albo podczas kontroli wydania. Telefon rozwiązuje opóźnienie. Hook rozwiązuje standardy.

Codex ma już firmowe powierzchnie kontroli wokół sandboxingu i zatwierdzeń. Dokumentacja bezpieczeństwa łączy tryb sandboxa, który definiuje, co agent technicznie może zrobić, z polityką zatwierdzeń, która definiuje, kiedy Codex musi się zatrzymać i zapytać przed działaniem.⁵ Agent działa z domyślnie wyłączonym dostępem do sieci, a domyślny lokalny tryb workspace-write trzyma dostęp do sieci wyłączony, dopóki użytkownik go nie włączy.⁵ Hooki siedzą obok tych kontroli jako warstwa przeglądu i sterowania, a nie zamiennik sandboxingu.

Hooki potrafią uczynić lokalne standardy wykonywalnymi:

Model może zapomnieć regułę. Hook może uruchomić ją ponownie w chwili, w której reguła ma znaczenie.

Co należy do harnessu, a nie do dostawcy?

Harness agenta to warstwa operacyjna wokół modelu: uprawnienia, pamięć, narzędzia, hooki, kontrole źródeł, bramy wydań, pakiety przeglądowe i dyscyplina rollbacku. Termin może brzmieć prywatnie lub ozdobnie, ale zadanie jest zwyczajne. Ta warstwa zamienia intencję w rozliczalną pracę.

Codex udostępnia już dość oficjalnej powierzchni, by uczynić tę warstwę jawną. Zdalne połączenia niosą środowisko hosta. Tryby sandboxa i polityki zatwierdzeń definiują granice działania. Pliki konfiguracyjne definiują modele, projekty, uprawnienia, serwery MCP, umiejętności, hooki, telemetrię i funkcje.⁶ Eksport OpenTelemetry pozostaje opcjonalny i domyślnie wyłączony; po włączeniu Codex emituje ustrukturyzowane zdarzenia obejmujące czaty, żądania API, aktywność strumieni, prompty użytkownika (domyślnie redagowane), decyzje o zatwierdzaniu narzędzi i wyniki narzędzi.⁵⁸

Ten zestaw powierzchni tworzy użyteczny podział:

Dostawca powinien dalej ulepszać środowisko uruchomieniowe. Osąd wciąż należy do zespołu.

Co zespoły powinny zakodować najpierw?

Warto zacząć od czterech bram. Zwracają się natychmiast.

Brama dowodów

Oryginalny wpis premierowy Codex podkreślał weryfikowalne dowody: logi terminala, wyniki testów i możliwe do prześledzenia kroki podczas realizacji zadania.⁹ To oczekiwanie należy uczynić niepodważalnym. Sensowne ukończenie powinno wymieniać zmienione pliki, uruchomione polecenia, zaobserwowane zachowanie, nieudane kontrole i pozostałe luki.

Dla pracy publicznej dowody obejmują linki do źródeł i zgodność twierdzeń ze źródłami. Dla wydań webowych dowody obejmują wyrenderowane trasy, metadane, schemę, pliki odkrywania, stan wdrożenia, świeżość cache i żywe znaczniki zmian. Dla tłumaczeń dowody obejmują pokrycie locale, bramy jakości, wiersze magazynu lub pliki cache oraz status przeglądu przez rodzimego użytkownika języka, gdy jest wymagany.

Brama zatwierdzeń

Nie należy używać jednej postawy zatwierdzania do każdej akcji. Aktualna tabela kombinacji w dokumentacji zatwierdzeń biegnie od presetu Auto (sandbox workspace-write z zatwierdzeniami on-request) przez bezpieczne przeglądanie tylko do odczytu, nieinteraktywne CI tylko do odczytu, tryb auto-review, aż po niebezpieczny pełny dostęp.⁵ Jeden wiersz nie nadąża za rzeczywistością: polityka untrusted wciąż widnieje na stronie, ale 0.149.0 ją wycofał i jawne konfiguracje kończą się teraz błędem.²⁵ Dla postawy „zawsze pytaj” łączy się dziś sandbox read-only z zatwierdzeniami on-request. Mocna lokalna polityka trzyma ten sam kształt: odczyty niskiego ryzyka przechodzą cicho, praca ze skutkami ubocznymi dostaje przegląd, a praca destrukcyjna lub widoczna na zewnątrz dostaje jawne dowody.

Brama nadzoru git

Praca agenta potrzebuje uchwytów rollbacku. Własna dokumentacja bezpieczeństwa Codex mówi, że Codex działa najlepiej z kontrolą wersji: utrzymywać czysty status przed delegowaniem, commitować często, uruchamiać celowaną weryfikację, przeglądać diffy i dokumentować decyzje w komunikatach commitów.⁵

Ta rada powinna stać się procesem. Commit po spójnych, zweryfikowanych punktach zapisu. Do stage’a trafiają wyłącznie dokładne ścieżki. Commity dzieli się według niezależnie odwracalnych zagadnień. Przed pushem należy pytać, chyba że przepływ wydania już przyznaje prawo publikacji. Żadnego zgarniania niepowiązanych brudnych plików do commita tylko dlatego, że agent akurat je zobaczył.

Brama gustu

Kodowanie z AI czyni implementację tańszą. Tańsza implementacja podnosi wartość gustu.

Gust nie oznacza dekoracyjnych preferencji. Oznacza, że praca ulepsza cały produkt. Oznacza, że agent potrafi odmówić technicznie możliwej ścieżki, która osłabia rezultat. Oznacza, że publiczny tekst unika prywatnej maszynerii, twierdzeń bez pokrycia i wypełniacza. Oznacza, że poprawna lokalna łatka może wciąż przepaść, jeśli ścieżka widoczna dla użytkownika pozostaje zepsuta.

Brama gustu powinna pytać:

Czego dowodzą prace Mozilla nad Firefoksem?

Wpis Mozilla z 7 maja o hartowaniu Firefoksa z Claude Mythos Preview robi ten sam wywód z innego stosu. Zespół pisze, że wczesne próby audytu kodu przez LLM były obiecujące, ale miały zbyt wiele fałszywych alarmów, by się skalować. Harnessy agentowe zmieniły ekonomię, bo umiały tworzyć i uruchamiać odtwarzalne przypadki testowe, by dynamicznie sprawdzać hipotezy o błędach.¹⁰

Najważniejsze zdanie Mozilla nie dotyczy samego modelu. Zespół pisze, że odkrywanie było konieczne, ale niewystarczające. Użyteczny system musiał zintegrować się z pełnym cyklem życia błędów bezpieczeństwa: celami, deduplikacją, śledzeniem błędów, triage’em, poprawkami i wydaniem.¹⁰ Autorzy piszą też, że potok odzwierciedlał semantykę kodu, narzędzia i procesy Firefoksa.¹⁰

To jest lekcja dla Codex. Lepsze modele mają znaczenie. O tym, czy praca stanie się zaufanym wynikiem, decyduje system operacyjny wokół modelu.

Co powinno pozostać poza publicznymi tekstami?

Publiczny artykuł o Codex nie powinien zrzucać na stół prywatnego systemu pracy.

Poza publicznym tekstem należy trzymać:

• prywatne prompty i treści hooków;
• wrażliwe lokalne ścieżki;
• dokładne mapy źródeł i wewnętrzne mechanizmy oceniania;
• identyfikatory kont i obsługę poświadczeń;
• prywatne skróty przepływu pracy;
• niewydane zachowania pluginów;
• wszystko, co pomaga obcemu odtworzyć wewnętrzne operacje.

Zamiast tego należy publikować wzorzec: co chroni brama, jakich dowodów wymaga, jaką awarię łapie i jak zespół może wdrożyć pomysł przy użyciu oficjalnych powierzchni Codex.

Ta linia chroni zaufanie. Poprawia też samo pisanie. Prywatna maszyneria zwykle czyta się jak folklor. Publiczne kryteria akceptacji pomagają innym zespołom rozumować o własnych systemach.

Jak wygląda minimalna mapa harnessu Codex?

Warto zbudować najmniejszą mapę kontroli, która dowodzi użytecznej pracy.

Zaczynać jawnie. Uruchomić jedno prawdziwe zadanie. Zanotować, gdzie brama pomogła, a gdzie przeszkadzała. Awansować tylko te części, które poprawiają rezultat widoczny dla użytkownika.

Krótkie podsumowanie

Hooki Codex, Remote SSH, sterowanie mobilne, sandboxing, zatwierdzenia, konfiguracja, telemetria i kontrola wersji wskazują ten sam kierunek: agenci kodujący potrzebują wokół siebie systemów operacyjnych.²⁴⁵⁶ Agent umie pisać kod. Harness decyduje, co liczy się jako praca.

Najlepsze zespoły nie wygrają, produkując najwięcej agentowego wyniku. Wygrają, czyniąc pracę agentów możliwą do inspekcji, odwracalną, opartą na źródłach, gustowną i godną wydania.

FAQ

Czym są hooki Codex?

Hooki Codex uruchamiają skrypty lub narzędzia MCP podczas pętli agentowej, ładowane z plików hooks.json lub tabel [hooks] wpisanych bezpośrednio w config.toml. Dokumentacja nazywa zadania wprost: wysyłanie czatów do silnika logowania, blokowanie przypadkowo wklejonych kluczy API, streszczanie czatów do trwałych wspomnień, walidacja przy zatrzymaniu tury i dostosowywanie promptowania per katalog.³ Silnik w 0.150.0 rejestruje dwanaście zdarzeń, od PreToolUse, PermissionRequest i PostToolUse przez Stop po nowe Interrupt; strona dokumentacji wciąż wymienia jedenaście, póki nie nadgoni.³⁷

Dlaczego hooki Codex mają znaczenie?

Hooki pozwalają zespołom umieszczać standardy w punktach decyzji, zamiast polegać wyłącznie na promptach. Hook może sprawdzić dowody, jakość źródeł, stan git lub gotowość wydania, gdy agent działa lub próbuje skończyć.

Dlaczego hook się nie uruchomił?

Zwykła odpowiedź brzmi: zaufanie. Codex pomija każdy niezarządzany hook, którego aktualnego hasha nie przejrzano, drukuje ostrzeżenie przy starcie w sesjach interaktywnych i pomija po cichu w automatyzacji codex exec.⁷ Należy otworzyć /hooks, by przejrzeć hooka i mu zaufać, albo przekazać --dangerously-bypass-hook-trust wyłącznie w potokach, które weryfikują źródła hooków gdzie indziej.³

Czy mobilny Codex zastępuje lokalny przepływ pracy agenta?

Nie. Sterowanie mobilne pozwala kierować pracą z dala od biurka, ale to połączony host wciąż dostarcza projekty, czaty, pliki, poświadczenia, uprawnienia, pluginy i lokalne narzędzia.⁴ Zespoły nadal potrzebują lokalnej polityki, bezpiecznych poświadczeń, kontroli wersji i weryfikacji.

Co harness Codex powinien zawierać najpierw?

Na początek: instrukcje projektu, postawę sandboxa i zatwierdzeń, granicę sekretów, bramę stop na dowody, nadzór git po dokładnych ścieżkach, weryfikację źródeł dla publicznych twierdzeń i bramę wydania dla pracy widocznej dla użytkownika.

Czy zespoły powinny publikować swoje hooki Codex?

Publikować należy wzorce i kryteria akceptacji, a nie prywatne treści hooków ani wrażliwe szczegóły przepływu pracy. Użyteczny publiczny wpis może wyjaśnić zadanie hooka bez ujawniania prywatnych ścieżek, map źródeł, promptów, poświadczeń czy reguł oceniania.

Przypisy