AI dla programistów: agenci programistyczni, koszty i bezpieczne przekazywanie zadań

Jak to zrobić

1. 1Zanim przekażesz zadanie, napisz albo wskaż sprawdzenie: niezaliczony test albo polecenie i jego oczekiwany wynik.
2. 2Przekaż zadanie promptem z tej strony, razem z plikami, które agent może zmieniać, i tymi, których nie może.
3. 3Niech agent sam uruchomi sprawdzenie i wklei końcowy wynik.
4. 4Przejrzyj diff jak pull request od współpracownika; zaliczone sprawdzenie rozpoczyna przegląd, a nie go kończy.

Wbudowane

• ChatGPT · Codex
• Claude · Claude Code

Prompt do skopiowania

Zadanie: [zmiana].
Zadanie jest gotowe, gdy: [test lub polecenie] przechodzi i wypisuje [oczekiwany wynik]. Uruchom to, zanim skończysz, i wklej wynik.
Możesz zmieniać: [ścieżki]. Nie zmieniaj: [ścieżki], zależności ani testów.
Jeśli nie uda ci się sprawić, żeby przechodziło, zatrzymaj się i wyjaśnij dlaczego, zamiast obchodzić sprawdzenie.

Gdzie coś idzie nie tak

• Agenci czasem sprawiają, że test przechodzi, bo go osłabiają. Zabroń zmieniania testów i wypatruj tego w diffie.
• Zadanie zbyt duże na jedno sprawdzenie jest zbyt duże na jedno przekazanie. Podziel je.

Jak to zrobić

1. 1Wybierz ten, który jest najbliżej twojego kodu: Codex Cloud, agenta Copilot w chmurze w serwisie GitHub albo Claude Code on the web.
2. 2Upewnij się, że w jego środowisku da się zainstalować zależności i uruchomić testy; bez nich agent zgaduje.
3. 3Wysyłaj małe, niezależne zadania, każde z własnym sprawdzeniem, jak w zadaniu powyżej.
4. 4Niech każdy pull request najpierw przeczyta automatyczny recenzent, a potem przejrzyj go samodzielnie.

Wbudowane

• Codex · Codex Cloud
• GitHub Copilot · Copilot cloud agent
• Claude Code · Claude Code on the web (cloud sessions)

Prompt do skopiowania

W tym repozytorium: [zadanie].
Kontekst: [gdzie w kodzie, powiązane zgłoszenie].
Gotowe, gdy: [test lub polecenie] przechodzi w twoim środowisku; wklej jego wynik do opisu pull requesta.
Pull request ma mieć mniej niż [liczba] zmienionych linii. Jeśli potrzeba więcej, zatrzymaj się i zaproponuj, jak go podzielić.

Gdzie coś idzie nie tak

• Testy, które wymagają sekretów lub usług, których nie skonfigurowano, są pomijane albo nie przechodzą. Zielony wynik bez nich niewiele dowodzi.
• Kilku agentów pracujących nad powiązanym kodem tworzy pull requesty, które są ze sobą w konflikcie. Równoległe zadania trzymaj w osobnych obszarach.

Jak to zrobić

1. 1Wpisz polecenia do budowania, testów i lintowania do pliku z instrukcjami, który agent czyta na początku każdej sesji; nazwę tego pliku podaje dokumentacja każdego agenta.
2. 2W Claude Code dodaj hooki, które uruchamiają formatter i testy po każdej edycji, żeby agent widział błędy i je naprawiał.
3. 3Niech bot przegląda każdy pull request: włącz „Automatic review” w Codex albo dodaj Copilot jako recenzenta.
4. 4Kiedy agent popełni ten sam błąd dwa razy, zamień go w test albo regułę w pliku z instrukcjami.

Wbudowane

• Claude Code · Hooks
• Codex · Codex code review
• GitHub Copilot · Copilot code review

Prompt do skopiowania

Przeczytaj to repozytorium i napisz plik z instrukcjami dla agentów programistycznych:
1. Dokładne polecenia do instalacji, budowania, testów, lintowania i formatowania.
2. Strukturę projektu w maksymalnie 10 linijkach.
3. Konwencje, które nowe osoby w tym projekcie stosują źle, z jednym przykładem każdej.
4. Czego agent nigdy nie może tu robić, np. zmieniać migracji albo edytować wygenerowanych plików.
Wypisz tylko polecenia, które udało ci się uruchomić; resztę oznacz jako „niezweryfikowane”.

Gdzie coś idzie nie tak

• Plik z instrukcjami, w którym są polecenia, które już nie działają, uczy agenta, żeby go ignorował. Uruchom je ponownie, gdy zmienia się konfiguracja.
• Boty recenzujące też popełniają błędy z pełnym przekonaniem. Traktuj ich komentarze jako sugestie.

Jak to zrobić

1. 1Wypisz, co najczęściej wklejasz do czatów, np. zgłoszenia, logi błędów, dokumentację albo schemat. Te źródła połącz najpierw.
2. 2Dla każdego dodaj oficjalny serwer MCP z tokenem, który pozwala tylko na odczyt. W Gemini CLI rozszerzenie może zawierać serwer MCP razem z jego konfiguracją.
3. 3Daj agentowi zadanie, które ich wymaga, i sprawdź, czy wywołał właściwy.
4. 4Co kilka tygodni usuwaj serwery, z których już nie korzystasz.

Wbudowane

• Gemini CLI · Extensions

Prompt do skopiowania

Zanim cokolwiek zmienisz: przeczytaj zgłoszenie [id] w trackerze, znajdź błąd w logach i sprawdź dokumentację [biblioteka].
Napisz, czego dowiadujesz się z każdego z tych źródeł i w którym pliku, twoim zdaniem, jest błąd.
Nie zapisuj niczego w żadnym połączonym narzędziu.

Gdzie coś idzie nie tak

• Strona internetowa, zgłoszenie albo dokument mogą zawierać tekst napisany po to, żeby sterować agentem. Nie dawaj uprawnień do zapisu narzędziom, które czytają treści z zewnątrz.
• Tokeny w plikach konfiguracyjnych wyciekają. Korzystaj z magazynu sekretów klienta albo zmiennych środowiskowych, nigdy z repozytorium.

Jak to zrobić

1. 1Sprawdź, za co już płacisz: plany ChatGPT obejmują Codex, a płatne plany Claude obejmują Claude Code.
2. 2Zanotuj zużycie tokenów w kilku typowych sesjach, w miejscu, gdzie agent je pokazuje.
3. 3Wyceń to zużycie na naszej stronie z cenami API i porównaj z subskrypcją.
4. 4Do automatyzacji i CI używaj kluczy API z limitem wydatków, żeby zapętlony proces nie nabił rachunku.

Wbudowane

• ChatGPT · Codex
• Claude · Claude Code

Prompt do skopiowania

Oto moje zużycie z [liczba] typowych sesji: [tokeny wejściowe i wyjściowe]. Pracuję około [liczba dni] dni w tygodniu.
Oszacuj mój miesięczny koszt przy płaceniu za tokeny według tych cen: [wklej ze strony z cenami API].
Porównaj go z subskrypcją za [cena] miesięcznie. Pokaż obliczenia, żeby dało się je sprawdzić.

Gdzie coś idzie nie tak

• Subskrypcje też mają limity użycia. Trafienie na limit w środku zadania kosztuje czas; sprawdzaj limit, a nie tylko cenę.
• Model wpływa na rachunek bardziej niż cokolwiek innego. Porównuj ceny dla modelu, którego naprawdę używasz.

Jak to zrobić

1. 1Uruchom /init w repozytorium: polecenie analizuje kod i pisze startowy CLAUDE.md albo proponuje ulepszenia istniejącego pliku.
2. 2Zasady zespołu, takie jak polecenia budowania i testów oraz standardy kodowania, trzymaj w ./CLAUDE.md i dodaj ten plik do commita. Własne preferencje wpisz do ~/.claude/CLAUDE.md, jeśli mają dotyczyć każdego projektu, albo do CLAUDE.local.md, jeśli tylko tego.
3. 3Zamiast wklejać dłuższe dokumenty, odsyłaj do nich: @path/to/file importuje inny plik przy uruchomieniu.
4. 4Za każdym razem, gdy Claude dwa razy pomyli się w tej samej sprawie, dodaj jedną linijkę, która by temu zapobiegła.

Prompt do skopiowania

Przeczytaj to repozytorium i ulepsz CLAUDE.md. Plik ma mieć mniej niż 60 linijek:
1. Dokładne polecenia do budowania, testów i lintowania.
2. Struktura projektu w kilku linijkach.
3. Konwencje, które nowa osoba w tym projekcie stosuje źle.
4. Pliki i foldery, których nigdy nie wolno edytować.
Usuń wszystko, co już nie jest prawdą. Polecenia, które nie zostały przez ciebie uruchomione, oznacz jako „niezweryfikowane”.

Gdzie coś idzie nie tak

• Wszystko, co jest w CLAUDE.md, jest wczytywane w każdej sesji i zajmuje kontekst. Szczegóły przenieś do plików, które ten plik importuje.
• Nieaktualne instrukcje są gorsze niż żadne. Gdy zmienia się konfiguracja, sprawdź polecenia ponownie.

Z oficjalnej dokumentacji: Claude Code docs: How Claude remembers your project

Jak to zrobić

1. 1Naciskaj Shift+Tab, aż pasek stanu pokaże „plan mode on”, albo zacznij prompt od /plan.
2. 2Opisz zmianę i to, co nie może się zmienić. Claude nadal może uruchamiać polecenia, żeby zbadać kod, ale podczas planowania nie edytuje plików.
3. 3Czytaj plan jak notatkę projektową: zły plik, brakujący przypadek, zbyt duża zmiana. Proś o poprawki, aż plan będzie dobry, a potem go zatwierdź.
4. 4Przed kolejnym, niezwiązanym zadaniem zacznij od nowa poleceniem /clear.

Prompt do skopiowania

/plan Zmień [co], żeby [cel]. Ograniczenia: [co nie może się zmienić].
Wypisz pliki, które zmienisz, kolejność zmian, test, który potwierdza każdy krok, i wszystko, co do czego masz wątpliwości. Nie edytuj niczego, dopóki nie zatwierdzę.

Gdzie coś idzie nie tak

• Sygnałem ostrzegawczym jest plan, który obejmuje więcej plików, niż się spodziewasz. Zanim go zatwierdzisz, zapytaj dlaczego.
• Tryb planowania nadal uruchamia polecenia, żeby zbadać kod. Nie sprawia, że uruchamianie nieznanego repozytorium staje się bezpieczne.

Z oficjalnej dokumentacji: Claude Code docs: Choose a permission mode · Claude Code docs: Commands · Claude Code docs: Best practices

Jak to zrobić

1. 1Otwórz /permissions, żeby zobaczyć każdą regułę i plik ustawień, z którego pochodzi.
2. 2Reguły zespołu wpisz do .claude/settings.json i dodaj ten plik do commita. Osobiste reguły trafiają do ~/.claude/settings.json albo .claude/settings.local.json.
3. 3Reguły są sprawdzane w kolejności: najpierw deny, potem ask, potem allow, więc jedna reguła deny wygrywa z każdą regułą allow.
4. 4Przełączaj tryby klawiszami Shift+Tab: acceptEdits zatwierdza edycje plików w katalogu roboczym. bypassPermissions wyłącza pytania i zabezpieczenia; według dokumentacji należy go używać tylko w odizolowanych kontenerach lub maszynach wirtualnych bez dostępu do internetu.

Prompt do skopiowania

Spójrz na polecenia uruchomione w tej sesji. Zaproponuj reguły uprawnień dla .claude/settings.json: zezwól (allow) na polecenia tylko do odczytu i testy, których używamy na co dzień, zablokuj (deny) wszystko, co czyta sekrety lub usuwa coś poza projektem, a całą resztę zostaw z pytaniem (ask). Każdą regułę wyjaśnij w jednej linijce.

Gdzie coś idzie nie tak

• Reguła allow pasująca do każdego polecenia oznacza to samo co brak pytań. Zezwalaj na konkretne polecenia.
• Reguły w .claude/settings.json po commicie obowiązują cały zespół. Przeglądaj je jak kod.

Z oficjalnej dokumentacji: Claude Code docs: Configure permissions · Claude Code docs: Settings files and precedence · Claude Code docs: Choose a permission mode

Jak to zrobić

1. 1Między niezwiązanymi zadaniami /clear rozpoczyna nową rozmowę z pustym kontekstem.
2. 2W długim zadaniu /compact ze wskazaniem, na czym się skupić, np. „/compact zachowaj plan i test, który nie przechodzi”, streszcza to, co było wcześniej.
3. 3Szerokie wyszukiwania przekazuj subagentowi: każdy działa we własnym oknie kontekstowym, więc do twojej sesji wraca tylko jego odpowiedź.
4. 4Claude Code sam kompaktuje kontekst, gdy zbliża się do limitu; jeśli zrobisz to samodzielnie w dobrym momencie, zachowasz to, co wybierzesz.

Wbudowane

• Claude Code · Subagents

Prompt do skopiowania

/compact Zachowaj: cel, plan, pliki zmienione do tej pory i test, który nadal nie przechodzi. Pomiń eksplorację.

Gdzie coś idzie nie tak

• /clear zapomina rozmowę. Wszystko, czego jeszcze będziesz potrzebować, najpierw wpisz do CLAUDE.md.
• Odpowiedź subagenta to wszystko, co do ciebie wraca. Proś o ścieżki plików i numery linii, a nie tylko o wnioski.

Z oficjalnej dokumentacji: Claude Code docs: Commands · Claude Code docs: Best practices · Claude Code docs: Create custom subagents

Jak to zrobić

1. 1Uruchamiaj każdą sesję poleceniem claude --worktree <name> (albo -w). Tworzy ono git worktree w .claude/worktrees/<name>/ na gałęzi worktree-<name>.
2. 2Dodaj .claude/worktrees/ do .gitignore, jak zaleca dokumentacja.
3. 3Daj każdej sesji jedno zadanie z własnym sprawdzeniem, żeby przeglądać je po kolei.
4. 4Przeglądaj i scalaj każdą gałąź jak każdy inny pull request.

Prompt do skopiowania

Pracujesz w worktree na gałęzi worktree-[nazwa]. Zadanie: [jedna zmiana]. Gotowe, gdy: [test lub polecenie] przechodzi. Commituj tylko na tej gałęzi; nie scalaj innych gałęzi i nie rób na nich rebase.

Gdzie coś idzie nie tak

• Każdy worktree to osobny folder, więc zależności i wyniki budowania nie są współdzielone. Instaluj je w każdym.
• Dwa zadania, które zmieniają te same pliki, i tak wejdą w konflikt przy scalaniu, z worktree czy bez.

Z oficjalnej dokumentacji: Claude Code docs: Run parallel sessions with worktrees

Jak to zrobić

1. 1Naciśnij dwa razy Esc przy pustym prompcie albo wpisz /rewind (działają też /checkpoint i /undo).
2. 2Wybierz punkt sprzed problemu i przywróć rozmowę, kod albo jedno i drugie.
3. 3Znaj ograniczenia: pliki zmienione poleceniami powłoki, takimi jak rm, mv czy cp, nie są przywracane, podobnie jak zmiany wprowadzone poza Claude Code albo w innej sesji.
4. 4Przed ryzykownymi krokami rób commit. Punkty kontrolne służą do szybkiego powrotu w obrębie sesji, a nie zastępują systemu git.

Prompt do skopiowania

Zanim zaczniesz, zrób commit obecnego stanu z komunikatem „punkt kontrolny przed [zadanie]”. Potem [zadanie]. Zapytaj mnie przed każdym poleceniem, które usuwa lub przenosi pliki.

Gdzie coś idzie nie tak

• Rewind nie przywróci pliku usuniętego przez polecenie. Zrobi to tylko git.
• Zmiany wprowadzone w międzyczasie ręcznie też nie są zapisywane. Zrób z nich commit przed cofnięciem.

Z oficjalnej dokumentacji: Claude Code docs: Checkpointing · Claude Code docs: Commands

Jak to zrobić

1. 1claude -p "..." działa nieinteraktywnie. --output-format json albo stream-json daje wynik, który skrypt może sparsować.
2. 2Przy powodzeniu kończy się kodem 0, a przy błędzie kodem innym niż 0, więc CI może od tego uzależnić dalsze kroki.
3. 3W CI dodaj --bare, żeby uruchomienia nie zależały od lokalnej konfiguracji.
4. 4Dla pull requestów /install-github-app konfiguruje Claude Code GitHub Actions (tylko repozytoria na github.com); potem oznacz @claude w komentarzu do pull requesta lub zgłoszenia.

Prompt do skopiowania

claude -p "Przeczytaj diff względem main. Wypisz każdą zmianę, która dodaje zależność, dotyczy uwierzytelniania albo zmienia migrację bazy danych, jako JSON: {\"files\": [], \"reason\": \"\"}. Jeśli nie ma żadnych, zwróć pustą listę." --output-format json

Gdzie coś idzie nie tak

• Skrypt działa z uprawnieniami, które mu nadasz. Daj CI tylko tyle, ile potrzebuje.
• /install-github-app działa tylko z repozytoriami na github.com.

Z oficjalnej dokumentacji: Claude Code docs: Run Claude Code programmatically · Claude Code docs: GitHub Actions

Jak to zrobić

1. 1Uruchom /init w CLI, żeby utworzyć startowy AGENTS.md w bieżącym folderze.
2. 2Osobiste wskazówki wpisz do ~/.codex/AGENTS.md, a reguły projektu trzymaj w repozytorium. Podfolder może mieć własny plik; pierwszeństwo mają pliki bliżej miejsca, w którym pracuje Codex.
3. 3Pliki powinny być krótkie: ich łączny rozmiar jest ograniczony, domyślnie do 32 KiB.
4. 4Dodaj sekcję „## Code Review Rules”: recenzje Codex w serwisie GitHub się do niej stosują.

Prompt do skopiowania

Przeczytaj to repozytorium i napisz AGENTS.md:
1. Dokładne polecenia do instalacji, budowania, testów i lintowania.
2. Struktura projektu w kilku linijkach.
3. Konwencje, które nowa osoba w tym projekcie stosuje źle.
4. Sekcja „## Code Review Rules” z tym, co recenzent musi zawsze zgłaszać.
Wypisz tylko polecenia, które udało ci się uruchomić; resztę oznacz jako „niezweryfikowane”.

Gdzie coś idzie nie tak

• Długie pliki działają na twoją niekorzyść: łączny rozmiar jest domyślnie ograniczony do 32 KiB.
• Plik w podfolderze, który bez słowa przeczy plikowi głównemu, myli ludzi tak samo jak Codex. Napisz, co nadpisuje.

Z oficjalnej dokumentacji: Codex docs: AGENTS.md · Codex docs: CLI commands · Codex docs: GitHub integration

Jak to zrobić

1. 1W CLI /permissions przełącza tryb, a /status pokazuje obowiązującą zasadę zatwierdzania i foldery z prawem zapisu.
2. 2„Ask for approval”, zalecany tryb domyślny, edytuje i uruchamia polecenia w obrębie obszaru roboczego i zatrzymuje się, zanim wyjdzie poza niego.
3. 3„Approve for me” zachowuje tę samą piaskownicę, ale prośby o zatwierdzenie wysyła do automatycznej weryfikacji, a nie do ciebie.
4. 4„Full access” usuwa ograniczenia systemu plików i sieci. Dokumentacja dodaje ostrzeżenie; zostaw ten tryb dla środowisk, które możesz wyrzucić.

Prompt do skopiowania

Zanim zaczniesz, uruchom /status i podaj mi zasadę zatwierdzania i foldery z prawem zapisu. Potem [zadanie]. Zapytaj przed każdym poleceniem, które potrzebuje sieci albo zapisuje coś poza tym repozytorium.

Gdzie coś idzie nie tak

• W trybie „Approve for me” żaden człowiek nie czyta poszczególnych próśb. Używaj go tam, gdzie złe działanie łatwo cofnąć.
• „Full access” dotyczy całego komputera, a nie tylko repozytorium.

Z oficjalnej dokumentacji: Codex docs: Permission modes · Codex docs: Sandboxing · Codex docs: Approvals and security · Codex docs: CLI commands

Jak to zrobić

1. 1codex exec "..." działa nieinteraktywnie i domyślnie używa piaskownicy tylko do odczytu.
2. 2Dodaj --sandbox workspace-write, gdy musi edytować pliki; opcja --full-auto jest przestarzała.
3. 3--json wypisuje strumień zdarzeń w formacie JSON Lines dla skryptów, które potrzebują każdego kroku.
4. 4W GitHub Actions openai/codex-action@v1 uruchamia codex exec za ciebie.

Prompt do skopiowania

codex exec "Przeczytaj zmiany od taga [v1.2.0]. Napisz informacje o wydaniu w grupach Dodane, Zmienione i Poprawione: jedna linijka na zmianę, słowami zrozumiałymi dla użytkownika, bez hashy commitów."

Gdzie coś idzie nie tak

• Starsze poradniki nadal używają --full-auto. Ta opcja jest przestarzała; używaj --sandbox workspace-write.
• Zadanie, które tylko czyta, powinno zostać w trybie tylko do odczytu, także w CI.

Z oficjalnej dokumentacji: Codex docs: Non-interactive mode · Codex docs: GitHub Action

Jak to zrobić

1. 1/review w CLI przegląda twoje drzewo robocze. codex review robi to samo bez czatu, względem gałęzi bazowej, commita albo niezacommitowanych zmian.
2. 2W serwisie GitHub napisz w komentarzu do pull requesta @codex review.
3. 3Włącz automatyczne przeglądy w sekcji „Personal preferences” w ustawieniach Codex; wtedy komentarz nie jest potrzebny.
4. 4Zapisz zasady swojego zespołu w sekcji „## Code Review Rules” w AGENTS.md.

Wbudowane

• Codex · Codex code review

Prompt do skopiowania

## Code Review Rules
- Zgłaszaj każdą zmianę uwierzytelniania lub uprawnień.
- Zgłaszaj migracje bazy danych bez możliwości cofnięcia.
- Zgłaszaj nowe zależności i oceniaj, czy są potrzebne.
- Ignoruj formatowanie; tym zajmuje się linter.

Gdzie coś idzie nie tak

• Przeglądy w serwisie GitHub zgłaszają tylko problemy P0 i P1. Brak komentarza nie oznacza, że projekt rozwiązania jest dobry.
• Przegląd to druga opinia, a nie uruchomienie testów. Nie rezygnuj z testów.

Z oficjalnej dokumentacji: Codex docs: CLI commands · Codex docs: GitHub integration

Jak to zrobić

1. 1Utwórz środowisko z repozytoriami, zależnościami, narzędziami i ustawieniami dostępu, których potrzebują zadania. Nowe środowiska zapisują skrypt instalacyjny i skill startowy.
2. 2Ustaw dostęp do internetu osobno dla każdego środowiska: tylko menedżery pakietów, wybrane domeny albo wszystko.
3. 3Uruchamiaj zadania z ChatGPT, z rozszerzenia do IDE przy dłuższych zadaniach albo z terminala przez codex cloud exec; --attempts 1-4 prosi o kilka podejść do porównania.
4. 4Code Review oraz integracje z GitHub i Linear nadal działają na starszej wersji Codex Cloud (Legacy), którą OpenAI planuje wycofać.

Wbudowane

• Codex · Codex Cloud

Prompt do skopiowania

codex cloud exec --attempts 3 "Zadanie: [zmiana]. Kontekst: [pliki]. Gotowe, gdy [test] przechodzi w tym środowisku. Diff ma mieć mniej niż [liczba] linii."

Gdzie coś idzie nie tak

• Nieograniczony internet pozwala zadaniu dotrzeć do dowolnej strony, także do stron napisanych po to, żeby nim sterować. Zezwalaj tylko na to, czego zadanie potrzebuje.
• Jeśli brakuje skryptu instalacyjnego, testy mogły się nie uruchomić. Sprawdź, czy zadanie naprawdę je uruchomiło.

Z oficjalnej dokumentacji: Codex docs: Cloud environments · Codex docs: CLI commands · Codex docs: IDE extension

Jak to zrobić

1. 1Ustaw domyślny model i poziom rozumowania w ~/.codex/config.toml (model i model_reasoning_effort). CLI i rozszerzenie do IDE korzystają z tego samego pliku.
2. 2Utwórz profil jako osobny plik, ~/.codex/<name>.config.toml, i uruchamiaj z --profile <name>.
3. 3Dodawaj serwery MCP poleceniem codex mcp add <name> -- <command>; każdy staje się tabelą [mcp_servers.<name>], a /mcp wypisuje aktywne.
4. 4/status pokazuje, co obecnie obowiązuje, a codex resume --last wznawia ostatnią sesję w tym folderze.

Prompt do skopiowania

Przeczytaj ~/.codex/config.toml i .codex/config.toml tego projektu. Podaj obowiązujący model, poziom rozumowania, piaskownicę i serwery MCP, z którego pliku pochodzi każde ustawienie, i wszystko, co jest ze sobą sprzeczne.

Gdzie coś idzie nie tak

• Ustawienia projektu wczytują się tylko w zaufanych projektach. Jeśli któreś wydaje się ignorowane, najpierw to sprawdź.
• Profile są teraz osobnymi plikami. Poradniki, które umieszczają [profiles.name] w config.toml, są nieaktualne.

Z oficjalnej dokumentacji: Codex docs: MCP · Codex docs: Config basics · Codex docs: Advanced config · Codex docs: CLI commands