Przewodnik migracji z Claude Code do Codex 2026

3 maja 2026 roku zinwentaryzowałem 744 lokalne wpisy konfiguracji agentów, a następnie uszeregowałem 691 z nich według znaczenia operacyjnego.¹ Sama liczba wyglądała na dużą. Ważniejszy był jednak kształt systemu: mniej więcej 20 plików niosło całość.

Migracja z Claude Code do Codex powinna przenosić kontrakty operacyjne, a nie kopiować drzewo plików. Reguły z CLAUDE.md należy przenieść do warstwowych AGENTS.md, procedury wielokrotnego użytku do umiejętności Codex, deterministyczne bramki do wyspecjalizowanych punktów zaczepienia, postawę wobec ryzyka do profili, a narzędzia przeglądarkowe i źródłowe do jawnego MCP. Nie należy kopiować siatki punktów zaczepienia z epoki Claude do Codex; trzeba przenieść obowiązki dowodowe.

TL;DR

Prywatny stos pisania i weryfikacji już istnieje w moim świecie Codex. Brakującym elementem nie była treść umiejętności. Brakowało publicznego podręcznika operacyjnego: gdzie powinny mieszkać umiejętności wielokrotnego użytku, jak Codex ma je wybierać, który profil powinien obsługiwać publiczne pisanie i które bramki z epoki Claude powinny stać się natywnymi regułami Codex bez ujawniania prywatnych szczegółów przepływu pracy.

Pierwsze uruchomienie Codex na żywo zmieniło zasadę migracji: prywatny przepływ pracy nie powinien stawać się domyślnym tłem tylko dlatego, że został przeniesiony. Trzeba go wdrażać etapami. Moja ścieżka pisania specyficzna dla tej witryny zaczyna teraz jako wyłącznie jawnie wywoływana, natomiast przepływ migracji działa jako umiejętność użytkownika do aktywnego lokalnego użycia i jako kandydat na prywatny pakiet Codex do testów lokalnych. Ten pakiet nie jest open source ani ogólnie dostępny; jeśli chce Pan/Pani przetestować przepływ migracji, proszę się ze mną skontaktować. Pakiet nie powinien stać się domyślną ścieżką środowiska wykonawczego tylko dlatego, że istnieje lokalny wpis instalacyjny. Prawdziwy pilotaż instalacji nadal wymaga walidacji pakietu, weryfikacji instalacji wtyczki, wykrywania umiejętności w przestrzeniach nazw, usunięcia duplikatów i świeżej sesji Codex, zanim cokolwiek będzie to znaczyć. Dzięki temu system uczy się na realnej pracy, zanim przepływ stanie się zachowaniem domyślnym.¹⁸¹⁰¹⁴

Nie należy zaczynać od klonowania każdego punktu zaczepienia Claude do Codex. Najpierw trzeba napisać kontrakt Codex:

• Trwałą politykę między repozytoriami umieścić w ~/.codex/AGENTS.md.
• Politykę repozytorium umieścić w AGENTS.md, a węższe nadpisania blisko miejsca pracy.
• Procedury wielokrotnego użytku umieścić w .agents/skills albo $HOME/.agents/skills.
• Publiczne pisanie awansować do careful-review albo dedykowanego profilu public-writing.
• Deterministyczne bramki pozostawić jako punkty zaczepienia, ale traktować je jako jedną barierę ochronną, a nie cały model bezpieczeństwa.

Pierwszym udanym artefaktem migracji powinien być samoopisujący się wpis. Taki artefakt dowodzi, że system potrafi opisać samego siebie, cytować aktualną dokumentację, użyć oczyszczonej lokalnej inwentaryzacji i wytworzyć publiczną pracę pod kontrolą Codex bez publikowania prywatnej maszynerii stojącej za kulisami.

Stronę stosu dotyczącą Claude opisałem w tekście Claude Code jako infrastruktura, stronę plików instrukcji w Wzorcach AGENTS.md, a problem starzenia się umiejętności w Statyczne umiejętności są martwymi umiejętnościami. Poniższa migracja łączy te wątki ze środowiskiem wykonawczym Codex, którego rzeczywiście używam.

Dla szerszego kontekstu warto przeczytać przewodnik po Codex CLI, Claude Code kontra Codex, Codex kontra Claude Code 2026, samouczek punktów zaczepienia dla Claude Code, budowanie własnych umiejętności oraz filozofię jakości Jiro. Te wpisy wyjaśniają elementy, które ta migracja składa w całość.

Co pokazała inwentaryzacja migracji?

Lokalny system miał trzy środki ciężkości.

Dane użycia prowadziły do tego samego wniosku. Logi routingu profili pokazały, że rutynowe wykonanie było zdominowane przez prace wymagające intensywnego przeglądu.¹ Prawdziwym sercem nie był najdłuższy plik ani najsprytniejszy skrypt. Była nim warstwa decyzyjna, która wybierała poziom ryzyka, ładowała doktrynę i wymuszała dowody przed zakończeniem.

To ustalenie zmienia sposób przenoszenia.

Gdyby najważniejsze było to, że „Claude ma dużo punktów zaczepienia”, migracja skopiowałaby punkty zaczepienia. Gdyby najważniejsze było to, że „system ma filozofię”, migracja skopiowałaby prozę. Inwentaryzacja pokazała inną odpowiedź: kluczowy jest mały kontrakt, który uruchamia się we właściwym momencie.

Co zrobiliśmy przed publikacją?

Sam artykuł stał się pierwszym ćwiczeniem migracyjnym.

Najpierw zmapowałem kształt dojrzałej konfiguracji Claude Code: które elementy sterowały zachowaniem, które jedynie dokumentowały preferencje i które powinny pozostać prywatne. Następnie sprawdziłem obecne zachowanie Codex względem oficjalnej dokumentacji i lokalnego CLI, ponieważ przewodniki migracyjne szybko się starzeją, gdy dziedziczą stare flagi albo niewspierane kształty konfiguracji. Potem napisałem ten artykuł z myślą o realnej migracji, ale publiczny poziom szczegółu ograniczyłem do oczyszczonej architektury, a nie prywatnej implementacji.

Kolejny krok następuje przed publikacją: użyć tego przewodnika do rozbudowy konfiguracji Codex, a następnie poprawić artykuł zgodnie z tym, co naprawdę się zmieniło. Publiczny artykuł powinien pokazywać wzorzec migracji i kryteria akceptacji. Nie powinien publikować prywatnych poleceń, prywatnych przepływów pisania, dokładnych wnętrz punktów zaczepienia, wrażliwych ścieżek ani niczego, co pozwoliłoby czytelnikowi odtworzyć prywatny system.

Uruchomienie na żywo dało publicznie bezpieczną tabelę dowodową. Publikuję wyłącznie kontrakt, stan aktywacji i sygnał akceptacji, a nie prywatne polecenia, dokładne treści punktów zaczepienia ani wnętrza przepływu pisania.

Czy migrację Codex należy zaczynać od punktów zaczepienia?

Claude nauczył mnie myśleć zdarzeniami cyklu życia. Punkt zaczepienia UserPromptSubmit może wstrzyknąć kontekst projektu. Punkt zaczepienia PreToolUse może blokować wrażliwe ścieżki. Punkt zaczepienia Stop może odmówić słabego zakończenia. Ten wzorzec działa w Claude, ponieważ mój lokalny stos wyrósł wokół dyspozytorów, które zmieniają wiele małych skryptów w jeden uporządkowany potok zdarzeń.¹¹

Codex także ma punkty zaczepienia, ale obecny Codex traktuje je jako system cyklu życia za bramką funkcji, a nie jako zawsze aktywny katalog punktów zaczepienia. Dokumentacja punktów zaczepienia OpenAI pokazuje [features] codex_hooks = true w config.toml, a moje lokalne codex features list raportuje hooks jako stabilne i włączone w Codex CLI 0.130.0.²⁸ OpenAI dokumentuje wejście punktu zaczepienia jako JSON na stdin, ze wspólnymi polami takimi jak identyfikator sesji, katalog roboczy, nazwa zdarzenia i aktywny model.² Codex obsługuje zdarzenia takie jak SessionStart, PreToolUse, PermissionRequest, PostToolUse, UserPromptSubmit i Stop; PreToolUse może przechwytywać Bash, apply_patch oraz wywołania narzędzi MCP.²

Ta sama dokumentacja zawiera ostrzeżenie najważniejsze dla migracji: PreToolUse pozostaje barierą ochronną, nie pełną granicą egzekwowania. Dokumenty wskazują, że przechwytywanie nie obejmuje każdej ścieżki powłoki i nie przechwytuje wyszukiwania w sieci ani innych wywołań narzędzi, które nie są powłoką ani MCP.²

To ograniczenie nie oznacza, że punkty zaczepienia Codex są słabe. Oznacza, że punkty zaczepienia nie powinny nieść całego portu. OpenAI zauważa też, że wiele pasujących poleceń punktów zaczepienia dla tego samego zdarzenia uruchamia się współbieżnie, więc port Codex wymagający kolejności nadal potrzebuje dyspozytora albo jednego złożonego polecenia punktu zaczepienia.²

W Codex chcę punktów zaczepienia do wąskich kontroli deterministycznych:

• Blokować oczywiście destrukcyjne polecenia powłoki.
• Ostrzegać przy ścieżkach przypominających poświadczenia.
• Dodawać mały kontekst na początku sesji.
• Zapisywać dowody z przebiegów public-writing.
• Kończyć zdarzenie stop niepowodzeniem, gdy brakuje wymaganego artefaktu albo polecenia weryfikacyjnego.

Nie chcę, aby punkty zaczepienia niosły głos pisania, politykę cytowań, filozofię, routing czy doktrynę projektu. Codex ma dla nich lepsze miejsca.

Jak artefakty Claude mapują się na Codex?

Migracja staje się czystsza, gdy każdy artefakt Claude trafia do tej prymitywnej części Codex, która najlepiej odpowiada jego zadaniu.

Dokumentacja AGENTS.md OpenAI czyni pierwszy wiersz kręgosłupem migracji. Codex czyta pliki AGENTS.md przed pracą, warstwuje globalne wytyczne z katalogu domowego Codex, a następnie przechodzi od katalogu głównego projektu do bieżącego katalogu, pozwalając bliższym plikom nadpisywać wcześniejsze wskazówki.³ To zachowanie odpowiada temu, czego rzeczywiście potrzebuję od CLAUDE.md: trwałych ustaleń roboczych oraz lokalnych konkretów projektu.

Najważniejszy ruch: przepisać reguły jako operacje. „Pisz starannie” nie należy do AGENTS.md. „Dla publicznych wpisów najpierw zbierz cytowania, zweryfikuj URL-e, uruchom kontrolę zakazanych fraz i zgłoś wszystkie niezweryfikowane twierdzenia” już tam należy.

Jak prywatne umiejętności pisania powinny przejść do Codex?

Stos pisarza blogowego portuje się czysto, ponieważ już ma właściwy kształt. Umiejętność Codex to folder z plikiem SKILL.md, który zawiera frontmatter i instrukcje. Codex może aktywować umiejętności, gdy użytkownik wywołuje je jawnie albo gdy zadanie pasuje do opisu umiejętności.⁴ Codex czyta umiejętności z lokalizacji repozytorium, użytkownika, administratora i systemu, w tym z repo .agents/skills, $HOME/.agents/skills oraz /etc/codex/skills.⁴

Tutaj migracja Claude Code może subtelnie pójść źle. Umiejętności Codex nie są slash commands z Claude. Oficjalną ścieżką jawnego wywołania umiejętności Codex jest selektor umiejętności albo wzmianka $skill-name, natomiast slash commands w Codex CLI są osobną interaktywną powierzchnią sterowania dla wbudowanych działań, takich jak status, uprawnienia, zmiany modelu, wtyczki i kontrola sesji.⁴¹⁵ Polecenie takie jak /cave nadal może być użytecznym skrótem, jeśli opis umiejętności je rozpoznaje albo wrapper zmienia je w Use $cave ..., ale sam tekst slash nie jest trwałym kontraktem. Dla dowodu migracji należy testować $skill-name; potem osobno testować /name tylko wtedy, gdy obiecuje się taką kompatybilność.

To oznacza, że nowe natywne umiejętności pisarskie Codex powinienem normalizować do oficjalnych ścieżek umiejętności bez publikowania prywatnych nazw ani treści umiejętności:

$HOME/.agents/skills/source-verifier/SKILL.md
$HOME/.agents/skills/public-post-writer/SKILL.md
$HOME/.agents/skills/site-specific-writer/SKILL.md

Moje lokalne środowisko wykonawcze ma także działające umiejętności użytkownika w starszej lokalizacji.¹ Nie powinienem ich usuwać tylko dlatego, że publiczne dokumenty wymieniają .agents/skills. Bezpieczna migracja wygląda tak:

1. Skopiować albo dowiązać symbolicznie jedną umiejętność do $HOME/.agents/skills.
2. Zrestartować Codex.
3. Potwierdzić, że Codex listuje i aktywuje umiejętność.
4. Uczynić umiejętność wyłącznie jawnie wywoływaną, gdy jest w pilotażu.
5. Przenieść resztę dopiero po tym, jak wykrywanie i użycie pilotażowe zadziałają.
6. Zostawić starą ścieżkę do czasu, aż istniejące sesje i skrypty przestaną od niej zależeć.

Tę ścieżkę obrałem dla pierwszego prywatnego przepływu pisania. Przygotowałem pisarza specyficznego dla witryny jako prywatną umiejętność wyłącznie jawnie wywoływaną, zamiast czynić go domyślnym pisarzem dla każdego zadania treściowego. Dało to migracji lepszy test: jeśli umiejętność ulepszy ten artykuł i następny przebieg public-writing bez wycieku prywatnego procesu, może przejść z trybu wyłącznie jawnego do pilotażu. Jeśli doda zamieszania, pozostanie ograniczona.

Pisarze specyficzni dla marki nie powinni stawać się domyślnymi pisarzami witryny. Prywatny pisarz produktowy może dzielić te same standardy cytowania i przeglądu, ale jego odbiorcy, fakty o produkcie, wezwania do działania i reguły głosu powinny pozostać związane z tym produktem. Poprawny port oddziela adaptery marki i tworzy cienkiego pisarza specyficznego dla blakecrosley.com.

Taka umiejętność witryny powinna pozostać cienka:

---
name: site-specific-writer
description: Pisz publiczne posty techniczne dla konkretnej witryny. Używaj przy artykułach wymagających zweryfikowanych źródeł, linków wewnętrznych, głosu witryny i kontroli publikacji.
---

# Pisarz Specyficzny Dla Witryny

Używaj prywatnych umiejętności pisania, weryfikacji źródeł i wykrywalności przez AI dla każdego publicznego artykułu technicznego.

Wymagany dowód przed finałem:
- Zewnętrzne twierdzenia techniczne mają cytowania.
- Aktualne twierdzenia o Codex cytują dokumentację OpenAI.
- Twierdzenia wewnętrzne linkują do istniejących wpisów albo analizy autora.
- Wpis zawiera TL;DR, wnioski dla konkretnych ról i pytania czytelników, gdy są przydatne.

Dokumentacja umiejętności Codex pokazuje name i description jako pola frontmatter ręcznej umiejętności i wskazuje opis jako wyzwalacz niejawnej aktywacji.⁴ Treść może powiedzieć Codex, aby użył prywatnych umiejętności towarzyszących; kompozycja należy do instrukcji, chyba że lokalny toolchain dodaje dodatkowe metadane. Ogólny stos jest właścicielem reguł pisania. Wrapper witryny jest właścicielem głosu, wzorców linków i dowodu.

Ten sam podział dotyczy samego przepływu migracji. Dokumentacja wtyczek OpenAI zaleca rozpoczęcie od lokalnej umiejętności, gdy nadal iteruje się nad jednym osobistym przepływem pracy, a dopiero potem budowanie wtyczki, gdy chce się udostępnić stabilny pakiet zespołom albo związać więcej integracji.¹⁰ To uczyniło aktywną ścieżkę oczywistą: najpierw umiejętność użytkownika, potem pilotaż prywatnego pakietu. Nie opublikowałem umiejętności migracyjnej jako open source ani nie obiecałem publicznego wydania; jeśli chce Pan/Pani ją przetestować, proszę się ze mną skontaktować. Sonda pamięci podręcznej wtyczek pokazała, że zainstalowana umiejętność wtyczki pojawia się w przestrzeni nazw wtyczki, a nie pod gołą nazwą umiejętności, więc dokumentacja pakietu powinna rozróżniać bezpośrednie użycie umiejętności od użycia umiejętności zainstalowanej przez wtyczkę.⁸

Prywatny pakiet potrzebuje walidatora bardziej niż historii startowej. W najnowszym przebiegu dodałem walidator, który sprawdza marketplace JSON, manifest wtyczki, frontmatter umiejętności, wymagane odniesienia, składnię citation-checker, politykę instalacji, brak aktywnych manifestów punktów zaczepienia albo MCP, wygenerowane pliki oraz oczywiste wycieki prywatnych ścieżek lub fixtures sekretów. Ta kontrola należy przed każdą szerszą aktywacją, ponieważ dokumentacja wtyczek OpenAI czyni marketplace powierzchnią instalacji, a nie brudnopisem dla niestabilnego prywatnego przepływu pracy.⁸¹⁰

Jak AGENTS.md powinien przenosić reguły publicznego pisania?

Najmocniejsza zmiana migracji Codex należy do AGENTS.md, nie do punktu zaczepienia. Publiczne pisanie potrzebuje domyślnej klasy ryzyka.

Oto reguła, którą chcę mieć blisko początku pliku globalnego albo projektowego:

## Publiczne Pisanie Jest Pracą Produktową

Publiczne artykuły, przewodniki, landing page, dokumenty kształtujące rozumienie użytkownika i copy produktowe używają co najmniej profilu `default`. Awansuj do `careful-review`, gdy w grę wchodzą twierdzenia, cytowania, marka, pieniądze, bezpieczeństwo, zabezpieczenia albo zaufanie użytkownika.

Przed zakończeniem publicznego pisania:
- Zbierz cytowania przed szkicowaniem.
- Cytuj oficjalną dokumentację produktu dla aktualnego zachowania narzędzi.
- Wyraźnie oznacz analizę autora.
- Uruchom skan zakazanych fraz.
- Zweryfikuj linki wewnętrzne.
- Zgłoś każde twierdzenie, którego nie udało się zweryfikować.

Ta reguła naprawia wadę znalezioną w inwentaryzacji routera. Część prac treściowych dryfowała w stronę szybkiego wykonania, ponieważ router traktował „treść” jako tanią pracę. Publiczne pisanie nie jest tanie, gdy zmienia to, w co ludzie wierzą, co kupują, co instalują albo uruchamiają. Szkice blogowe, przewodniki i strony produktowe zasługują na większy przegląd niż rutynowe edycje kodu, ponieważ trybem awarii jest zaufanie publiczne, nie lokalnie nieprzechodzący test.

Przykładem jest wpis, który Pan/Pani czyta. Cytuje aktualne dokumenty Codex dla obecnego zachowania Codex. Oznacza twierdzenia z lokalnej inwentaryzacji jako analizę autora. Używa realnego stosu zamiast udawać, że migracja zaczyna się od pustej maszyny, ale trzyma prywatne szczegóły implementacji poza publicznym artykułem.

Jak profile Codex powinny kodować ryzyko?

Dokumentacja konfiguracji OpenAI definiuje profile jako domyślny profil przy starcie i obsługuje nadpisania dla wspieranych kluczy konfiguracji w zakresie profilu.⁵ Ta sama dokumentacja definiuje model_reasoning_effort, approval_policy i sandbox_mode jako jawne kontrolki konfiguracji.⁵

To daje Codex naturalne miejsce do zakodowania ryzyka.

[profiles.public-writing]
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
sandbox_mode = "workspace-write"
approval_policy = "on-request"
web_search = "live"

Konkretny model może się zmienić. Polityka nie powinna. Publiczne pisanie potrzebuje mocniejszego rozumowania, sprawdzania źródeł na żywo, gdy fakty mogą się zmieniać, wykonania ograniczonego do workspace i zgody człowieka na działania wychodzące poza bezpieczną ścieżkę pracy.

Router powinien mapować takie zadania do public-writing albo careful-review:

• Wpis blogowy, przewodnik albo zmiana strony głównej.
• Każdy artykuł z cytowaniami.
• Każda treść porównująca narzędzia albo dostawców.
• Każdy wpis wymieniający obecne Codex, Claude Code, OpenAI, Anthropic, Apple, Google albo inny szybko zmieniający się produkt.
• Każda praca dotykająca schema, llms.txt, SEO, analytics albo publicznych metadanych.

Profil nie jest nastrojem. Profil jest budżetem ryzyka.

Które punkty zaczepienia Codex nadal mają znaczenie?

Punkty zaczepienia Codex powinny egzekwować małe rzeczy, które muszą wydarzyć się w środowisku wykonawczym.

Punkt zaczepienia stop dla public-writing mógłby sprawdzać zmienione pliki i odmówić zakończenia, jeśli publiczny wpis Markdown zawiera odwołania do przypisów bez definicji. Punkt zaczepienia pre-tool mógłby ostrzec, jeśli agent próbuje edytować .env, poświadczenia analytics albo wygenerowane pamięci podręczne tłumaczeń podczas pisania artykułu. Punkt zaczepienia startu sesji mógłby dodać bieżącą datę i przypomnieć Codex, że twierdzenia typu „najnowsze” wymagają weryfikacji.

Ładunek punktu zaczepienia powinien pozostać mały. OpenAI dokumentuje kształty wyjścia JSON dla punktów zaczepienia, w tym systemMessage, continue i pola specyficzne dla zdarzenia.² Tych pól należy używać do blokowania albo ostrzegania przy dokładnych awariach. Nie należy odbudowywać całej siatki dyspozytorów Claude, dopóki dane o awariach Codex nie udowodnią, że jest potrzebna.

Testy konfiguracji nie zasługują na awans. Punkt zaczepienia wychodzi z pilotażu dopiero po obserwacji realnego użycia, która pokazuje trzy rzeczy: uruchamia się w zamierzonych sytuacjach, przepuszcza zwykłą pracę i zapisuje bezpieczną telemetrię zagregowaną zamiast prywatnej treści. Jeśli blokada się uruchomi, powód musi powiedzieć użytkownikowi, co zrobić dalej.²⁸

Po pierwszych przebiegach na żywo praktyczny backlog punktów zaczepienia wygląda tak:

1. SessionStart: utrzymać w pilotażu zwarty kontekst bieżącej daty, aktualności, projektu i granicy publiczne/prywatne.
2. PreToolUse:Bash: utrzymać w pilotażu wąską blokadę destrukcyjnych poleceń i odczytów poświadczeń.
3. PostToolUse:apply_patch: utrzymać nieblokujący cień jakości na zmienionych liniach patchy kodu/konfiguracji.
4. Stop: utrzymać w pilotażu bramkę cytowań dla zmienionego publicznego Markdown.
5. Stop: utrzymać kontrakt końcowej weryfikacji złożony do istniejącego pilotażu jakości Stop; nie tworzyć osobnego punktu zaczepienia podsumowania, dopóki realne awarie nie dowiodą potrzeby.

Taki zestaw przenosi zachowanie bezpieczeństwa bez importowania miesięcy ceremonii specyficznej dla Claude.

Jak powinny pasować MCP i narzędzia przeglądarkowe?

Moja obecna konfiguracja Codex już używa prywatnej ścieżki automatyzacji przeglądarki opartej na MCP.¹ Codex obsługuje też serwery MCP przez CLI i config.toml: codex mcp add może zarejestrować serwer stdio, a tabele [mcp_servers.<server-name>] mogą definiować command, args, environment, URL-e, enabled_tools, disabled_tools i timeouty.⁶

Dla publicznego pisania MCP należy do dwóch miejsc:

• Automatyzacji przeglądarki do sprawdzania renderowanych stron na żywo, screenshotów i lokalnych podglądów.
• Odkrywania źródeł albo pobierania dokumentacji, gdy konkretny dostawca udostępnia wiarygodny serwer MCP.

MCP nie powinien ukrywać ścieżki źródłowej. Pisarz blogowy potrzebuje cytowań, które czytelnik może kliknąć, a nie prywatnego wyniku narzędzia istniejącego tylko w sesji. MCP może pomóc znaleźć fakt. Końcowy wpis nadal potrzebuje publicznego źródła.

Jak zainicjować migrację z Claude Code do Codex?

Pierwszy natywny artefakt Codex powinien opisywać port, jednocześnie używając portu.

Oto interaktywna pętla bootstrap:

codex -p careful-review --search \
  "Inventory the local Codex and Claude migration surface, then create a citation bank for a sanitized post about moving the setup to Codex."

codex -p careful-review \
  "Draft content/blog/claude-code-to-codex-migration.md using the local inventory, official Codex docs, and existing internal posts. Label author analysis clearly."

codex -p careful-review \
  "Review the draft for unsupported claims, stale Codex flags, broken internal links, and AGENTS.md operational value."

Dla pracy nieinteraktywnej należy używać codex exec i uczynić wyszukiwanie na żywo kwestią konfiguracji/profilu zamiast kopiować interaktywną flagę --search. OpenAI dokumentuje codex exec dla uruchomień skryptowych albo w stylu CI, z nadpisaniami --profile, --sandbox i --config; moja lokalna pomoc Codex CLI 0.130.0 potwierdza te flagi i odrzuca codex exec --search.⁷⁸

codex exec -p careful-review -c 'web_search="live"' \
  "Create a citation bank for content/blog/claude-code-to-codex-migration.md from official Codex docs and sanitized local inventory."

codex exec -p careful-review \
  "Review content/blog/claude-code-to-codex-migration.md for unsupported Codex claims, stale flags, broken internal links, and AGENTS.md operational value."

Szczegóły wiersza poleceń mają znaczenie. OpenAI oznacza --full-auto jako przestarzałą flagę zgodności i zaleca zamiast niej --sandbox workspace-write.⁷ Stare przewodniki skupione na --full-auto nie powinny sterować nową automatyzacją.

Wpis staje się testem akceptacyjnym. Jeśli Codex potrafi:

• Załadować umiejętności pisarskie.
• Użyć careful-review.
• Cytować aktualną dokumentację OpenAI.
• Użyć lokalnej inwentaryzacji bez ujawniania prywatnych szczegółów implementacji.
• Wyjaśnić, co zmienia się w AGENTS.md, umiejętnościach, punktach zaczepienia, profilach i MCP.
• Wytworzyć czysty artykuł Markdown w repozytorium witryny.

Wtedy port pisarski działa.

Lista kontrolna migracji z Claude Code do Codex

Dla konfiguracji Codex:

• Dodać albo zaktualizować ~/.codex/AGENTS.md z globalnymi ustaleniami roboczymi.
• Dodać repozytoryjne reguły AGENTS.md dla publicznego pisania.
• Utworzyć public-writing albo kierować publiczne pisanie do careful-review.
• Sprawić, aby careful-review rzeczywiście używał wysokiego albo xhigh reasoning dla publicznych twierdzeń.
• Dodać regułę routera, która traktuje przewodniki, wpisy blogowe, dokumenty i copy produktowe jako pracę na powierzchni publicznej.

Dla umiejętności:

• Przenosić albo mirrorować prywatne umiejętności pisarskie do $HOME/.agents/skills pojedynczo.
• Aktywnie testowane przepływy migracyjne utrzymać jako umiejętności użytkownika, zanim pakiet wtyczki zostanie potraktowany jako ścieżka środowiska wykonawczego.
• Używać $skill-name jako kanonicznego testu jawnego wywołania; traktować /name jako wygodny wrapper albo nawyk selektora, nie jako dowód załadowania umiejętności Codex.
• Dodać walidator gotowości pakietu przed aktywacją marketplace.
• Dodać bramkę zdrowia mechanizmu agenta, która potwierdza odwołania AGENTS, profile, umiejętności, punkty zaczepienia, stan pakietu, kształt rejestru i stan aktywacji przed awansem.
• Dla pilotaży instalacji zweryfikować marketplace add, odczyt/instalację wtyczki, listowanie wtyczek, listowanie umiejętności, widoczność umiejętności w świeżej sesji i czyszczenie duplikatów marketplace.
• Pilotażowe umiejętności utrzymywać jako wyłącznie jawne przed dopuszczeniem niejawnej aktywacji.
• Oddzielać ogólne standardy pisania od głosu specyficznego dla witryny.
• Zachować weryfikację źródeł jako twardą bramkę faktograficzną.
• Oddzielić kontrole wykrywalności przez AI od głosu autora.
• Utworzyć cienką umiejętność pisarza specyficznego dla witryny zamiast ponownie używać pisarza specyficznego dla marki.
• Po każdym przeniesieniu potwierdzić, że Codex wykrywa umiejętności.

Dla współpracy między agentami:

• Utrzymać Codex jako właściciela pętli.
• Kotwiczyć przeglądy w realnych plikach albo artefaktach kontekstu.
• Zamykać bezpiecznie, gdy brakuje kotwic, wyjście jest puste albo drugi agent przekracza limit czasu.
• Odrzucać niepoparte ustalenia drugiego agenta z lokalnym dowodem.
• Przyjmować tylko ugruntowane ustalenia, zastosować najmniejszą poprawkę, ponownie uruchomić przegląd statyczny, a potem kontrole należące do Codex.

Dla punktów zaczepienia:

• Najpierw portować tylko kontrole deterministyczne.
• Używać SessionStart, PreToolUse, PostToolUse i Stop dla wąskich bramek.
• Logować awarie przed dodawaniem kolejnych bramek.
• Dla punktów zaczepienia w cieniu logować kategorie zamiast surowej prywatnej treści.
• Przed awansem przetestować jeden znany wadliwy fixture i jeden znany hałaśliwy fixture.
• Oddzielić czyste awarie od długu porządkowego przed egzekwowaniem migrowanej kontroli.
• Traktować punkty zaczepienia jako kontrole środowiska wykonawczego, nie jako kanoniczny magazyn doktryny.

Dla przepływu pisania:

• Zbierać cytowania przed szkicowaniem.
• Używać oficjalnych dokumentów dla obecnego zachowania Codex.
• Używać analizy autora dla lokalnej inwentaryzacji i doświadczenia.
• Linkować wewnętrzne wpisy tam, gdzie już wyjaśniają pojęcie.
• Przeprowadzać weryfikację przed finałem.
• Przy utrzymaniu przewodników weryfikować twierdzenia źródłowe i dotyczące środowiska wykonawczego, synchronizować pochodne powierzchnie publiczne, regenerować pliki wykrywania i nazywać pominięte kontrole tłumaczeń, wdrożenia oraz działania na żywo.
• Dla tłumaczonych przewodników zapisywać wybranego dostawcę tłumaczeń, różnicową partię albo liczbę sekcji, stan poświadczeń bez wartości, informację, czy wystąpiły zapisy/uploady, weryfikację locale i powód braku zapisu, gdy wykonanie jest zablokowane.
• W zakresie higieny sekretów i logów oddzielać źródła wykonywalne, dokumenty, wygenerowane pamięci podręczne, transkrypty sesji, migawki powłoki, logi i celowe magazyny sekretów; redagować historię i przestawiać helpery na konfigurację wymaganą przez środowisko, zanim migrowany przepływ zostanie uznany za bezpieczny.
• Po wdrożeniu zweryfikować kanoniczny URL, dane strukturalne, sitemap, llms-full.txt, stan wdrożenia, świeżość CDN i znaczniki zmienionej treści na produkcji.
• Jeśli cache CDN serwuje przestarzałą treść, wyczyścić tylko dotknięte publiczne URL-e istniejącą ścieżką wdrożeniową, a potem ponownie sprawdzić zmienione znaczniki.

FAQ

Czy prywatne umiejętności pisarskie muszą być publiczne?

Nie. Artykuł migracyjny może opisać kształt systemu pisania bez publikowania prywatnych nazw umiejętności, poleceń, szczegółów punktacji ani adapterów specyficznych dla marek. Publiczną lekcją jest to, gdzie te umiejętności powinny mieszkać i jak Codex powinien je aktywować.

Umiejętność migracyjna podlega tej samej regule. Dziś jest prywatna, nie jest pakietem open source. Jeśli chce Pan/Pani przetestować przepływ, proszę się ze mną skontaktować.

Czy migracja z Claude Code do Codex powinna ponownie używać pisarzy specyficznych dla marki?

Nie. Pisarze specyficzni dla marki powinni pozostać specyficzni dla marki. Witryna osobista albo firmowa potrzebuje cienkiego adaptera witryny, który dzieli standardy weryfikacji, ale nie dziedziczy odbiorców, faktów ani wezwań do działania innego produktu.

Czy należy skopiować każdy punkt zaczepienia Claude Code do Codex?

Nie. Kopiować należy zachowanie dopiero po zidentyfikowaniu stojącego za nim kontraktu. Blokada poświadczeń należy do punktu zaczepienia. Rubryka pisarska należy do umiejętności. Reguła ryzyka należy do profilu albo routera. Filozofia należy do AGENTS.md plus skupionej umiejętności.

Gdzie powinny mieszkać umiejętności Codex?

Dla nowej pracy natywnej dla Codex należy używać oficjalnych lokalizacji umiejętności: repo .agents/skills dla umiejętności projektowych i $HOME/.agents/skills dla umiejętności użytkownika.⁴ Jeśli istniejąca lokalna konfiguracja używa także ~/.codex/skills, należy ją zachować, dopóki wykrywanie Codex nie potwierdzi działania nowej lokalizacji.

Dlaczego polecenia /skill czasem zawodzą w Codex?

Ponieważ /skill nie jest kanonicznym kontraktem wywołania umiejętności Codex. Umiejętności Codex aktywują się, gdy wybiera się albo jawnie wspomina umiejętność, w tym $skill-name, albo gdy zadanie pasuje do opisu umiejętności.⁴ Slash commands w Codex CLI są własną wbudowaną powierzchnią poleceń.¹⁵ Gdy potrzebna jest deterministyczna aktywacja umiejętności, należy używać $skill-name. /name warto zachować wyłącznie jako wygodny wrapper, nawyk selektora albo frazę polecenia, która nadal wymaga własnego dowodu.

Co jest sercem migracji z Claude Code do Codex?

Sercem nie są same punkty zaczepienia, umiejętności ani profile. Sercem jest warstwa decyzyjna, która odpowiada na cztery pytania przed rozpoczęciem pracy: jaki rodzaj pracy właśnie przyszedł, jaki profil ryzyka powinien ją obsłużyć, jakie instrukcje nią rządzą i jaki dowód musi istnieć przed zakończeniem?

Kluczowe wnioski

Dla użytkowników Codex: Portować kontrakty, nie katalogi. AGENTS.md, profile, umiejętności, MCP i punkty zaczepienia mają osobne zadania. Każdą regułę należy umieścić tam, gdzie Codex najbezpośredniej ją uszanuje.

Dla użytkowników Claude Code przechodzących dalej: Punkty zaczepienia Codex należy traktować jako bariery ochronne, a nie pełny zamiennik dojrzałego systemu dyspozytorów Claude. Zacząć od AGENTS.md i umiejętności, potem dodać punkty zaczepienia tam, gdzie liczy się egzekwowanie w środowisku wykonawczym.

Dla publicznych pisarzy: Pisanie bloga należy do profilu o wysokim poziomie przeglądu. Aktualne twierdzenia potrzebują aktualnych źródeł. Wypolerowany błędny artykuł niszczy zaufanie szybciej niż uszkodzony lokalny skrypt.

Dla mojego własnego stosu: Prywatny system pisania nie jest już tylko przeniesiony w treści; pierwszy pisarz specyficzny dla witryny jest przygotowany jako wyłącznie jawny, przepływ migracji działa jako umiejętność użytkownika, a prywatny pakiet wtyczki przeszedł lokalny pilotaż instalacji bez stawania się publicznym wydaniem. Doktryna Codex czyni teraz jakość i wyczucie regułą operacyjną. Podsumowanie końcowej weryfikacji pozostało ręcznym przeglądem w cieniu, a jego wąska deterministyczna kontrola została złożona do istniejącego pilotażu jakości Stop zamiast osobnego punktu zaczepienia. Zwarty punkt zaczepienia kontekstu SessionStart jest w pilotażu, pierwszy aktywny punkt zaczepienia jakości obserwuje zmiany apply_patch w trybie cienia, pierwsza pre-Bash bariera bezpieczeństwa działa jako wąski pilotaż blokujący, checker cytowań działa teraz jako pilotaż Stop dla zmienionego publicznego Markdown, przebiegi utrzymania przewodników potwierdziły pętlę od źródła do renderu na realnych publicznych dokumentach, jeden przebieg poprawił przestarzałe twierdzenia o dokładnych liczbach zamiast zachowywać stare liczby mechanizmu źródłowego, inny złapał rozbieżność między wygenerowaną a serwowaną trasą AI-discovery, ostatnie przebiegi poprawiły zgodność modeli/parametrów, dryf benchmarków i kart modeli, dryf szybko zmieniających się wydań wtyczek, dryf renderowanych danych strukturalnych FAQ, dryf rozliczania kredytów, twierdzenia o API/prawie/minimalnych funkcjach oparte wyłącznie na źródłach trzecich oraz dryf tras slugów z frontmatter, a najnowsze przebiegi przewodnika Codex uczyniły tłumaczenie przewodników wybieralnym według dostawcy, użyły Codex jako domyślnego dostawcy dla pracy należącej do Codex, odrzuciły ucięte wyjście tłumaczenia przed zapisem pamięci podręcznej, ukończyły zapisy locale, zweryfikowały trasy locale i rozwiązały przestarzałe odpowiedzi CDN ukierunkowanym czyszczeniem cache zamiast milcząco zależeć od ścieżki wyłącznie Claude. Ograniczony przebieg higieny sekretów/logów oddzielił źródła, dokumenty, wygenerowane pamięci podręczne, zapisy sesji, migawki powłoki, logi i celowe magazyny sekretów przed zapisaniem rotacji, redakcji i luk w prewencyjnych punktach zaczepienia. Pętla wydania traktuje teraz lokalne kontrole, stan wdrożenia, świeżość CDN i dowód zmienionych znaczników na żywo jako osobne bramki. Przebieg analizy źródeł potwierdził dyscyplinę dry-run/wolumenu zapisu przed zapisami do prywatnej pamięci, ścieżka onboardingu bloga firmowego zatrzymuje się teraz przed generowaniem plików, jeśli docelowa firma, ścieżka i dowody wejściowe nie są jawne, translator bloga zatrzymuje się przed wykonaniem zapisu, gdy brakuje poświadczeń D1 albo jawnego celu, i odmawia wyjścia Codex z dużą ilością pozostałości przed publikacją, gdy poświadczenia są obecne, pętla współpracy między agentami potwierdziła review/fix/re-verify bez oddawania autorytetu drugiemu agentowi, a ręczna bramka zdrowia mechanizmu agenta sprawdza deterministyczną powierzchnię awansu przed jakąkolwiek szerszą aktywacją. Następna praca polega na dalszym dowodzeniu pozostałych rytuałów produkcyjnych wyłącznie jawnych, utrzymaniu publicznej granicy wydania w miejscu i dalszym przepuszczaniu realnego public-writing oraz pracy inżynierskiej przez etapowane ścieżki przed rozszerzeniem jakiejkolwiek bramki.

Źródła