Migracja między Codexem, Cursorem i Claude Code

Migracja między Codexem, Claude Code i Cursorem obejmuje trzy warstwy: instrukcje, MCP i skille oraz uprawnienia. Sprawdzony wzorzec to jeden AGENTS.md jako jedyne źródło instrukcji, wbudowane importery obu CLI dla serwerów MCP, poleceń i skilli oraz przebieg porównawczy, w którym obaj agenci wykonują ten sam zamknięty ticket i są oceniani na tych samych testach.

Twój zespół wiosną przyjął Codex jako standard. Teraz połowa ludzi chce Claude Code w terminalu, jeden zespół pracuje wyłącznie w Cursorze, a pierwsza sesja Claude Code w repozytorium pomija polecenia budowania, których Codex zawsze się trzymał. Nikt nie wie, który plik instrukcji jest nadrzędny, a token MCP leży w trzech konfiguracjach.

Ten przewodnik jest dla programistów, którzy przenoszą repozytorium z jednego z tych agentów do drugiego albo dokładają drugiego agenta obok pierwszego. Obejmuje każdy kierunek. Jeśli jesteś tech leadem i ustalasz jeden standard dla całego zespołu, przeczytaj go, a potem przejdź do strony o wspólnym kontekście i regułach zespołu. Jeśli nie zdecydowałeś jeszcze, który agent ma odpowiadać za jaką pracę, zacznij od strony Codex w porównaniu z Claude Code i Cursorem.

Co zyskujesz, przenosząc repozytorium między agentami

• Jeden AGENTS.md, który Codex czyta natywnie, Claude Code importuje jedną linią, a Cursor dostaje jako regułę projektu.
• Dokładne polecenia importu, które oba CLI mają dla konfiguracji pozostałych narzędzi, i to, czego każde z nich nie przenosi.
• Serwery MCP zapisane poprawnie we wszystkich trzech formatach, z tokenami czytanymi ze zmiennych środowiskowych i nigdy niecommitowanymi.
• Przebieg porównawczy: ten sam zamknięty ticket wykonany przez starego i nowego agenta, porównany na testach, linterze i granicach zamiast czytania diffu linijka po linijce.
• Listę pułapek migracji, które nie dają żadnego błędu.

Co się zmienia, gdy zmieniasz agenta?

Model to najmniejsza różnica. Większa to sama konfiguracja: pliki, formaty i ustawienia, i właśnie tam migracje po cichu się sypią.

Warstwa	Claude Code (v2.1.283)	Codex CLI (0.157.1)	Cursor (linia 3.x, sprawdzone 2026-08-28)
Instrukcje projektu	CLAUDE.md; czyta AGENTS.md tylko wtedy, gdy nie ma CLAUDE.md (v2.1.277+)	AGENTS.md (/init go tworzy)	AGENTS.md i CLAUDE.md w katalogu głównym projektu i w podkatalogach (dokumentacja Cursora, sprawdzone 2026-10-12); reguły w .cursor/rules/ tylko dla Cursora
Import z innych agentów	claude import codex|cursor|gemini albo /import w sesji	/import w TUI (w 0.162.1 opisany jako import z Claude Code, sprawdzone 2026-10-12; z Cursora też, według notatek wydania 0.145.0)	brak potwierdzonego
Konfiguracja MCP	.mcp.json (projekt) przez claude mcp add	[mcp_servers.<name>] w ~/.codex/config.toml przez codex mcp add	.cursor/mcp.json lub ~/.cursor/mcp.json
Skille	.claude/skills/	.agents/skills/	.agents/skills/ (tu npx skills add instaluje skille dla Cursora, skills 1.7.0); Cursor wczytuje też .cursor/skills/, .claude/skills/ i .codex/skills/ (dokumentacja Cursora, sprawdzone 2026-10-12)
Uprawnienia	Tryby uprawnień; tryb auto jest trybem startowym sesji interaktywnych od v2.1.283 (oba kanały)	Polityka zatwierdzeń (-a) plus sandbox lub profil uprawnień	Run modes
Izolowana praca równoległa	--worktree, --bg, /batch	--worktree, codex cloud (eksperymentalne), aplikacja desktopowa	Worktrees, Cloud Agents
Model domyślny	Claude Opus 5.5	GPT-6.1 Sol	brak jednego modelu domyślnego; Hobby używa Auto (Cursor, sprawdzone 2026-10-12)

Ceny i pełną listę modeli znajdziesz w przeglądzie modeli. Zasada przy migracji jest taka sama jak przy każdej zmianie modelu: zacznij od domyślnego modelu nowego narzędzia, najpierw dostrój poziom rozumowania (effort), a model zmieniaj dopiero wtedy, gdy każą ci to twoje własne ewaluacje.

Trzy pułapki wersji w tej tabeli

Fallback AGENTS.md w Claude Code, domyślny Opus 5.5 i tryb auto jako tryb startowy na każdym planie są dostępne na obu kanałach wydań, odkąd stable doszedł do v2.1.287 (sprawdzone 2026-10-12), także w casku claude-code z Homebrew, który śledzi stable. Reguły projektu w Cursorze to pliki .mdc w .cursor/rules, a AGENTS.md jest obsługiwany w katalogu głównym projektu i w podkatalogach (dokumentacja Cursora, sprawdzone 2026-10-12).

Jak przenieść repozytorium z jednego agenta do drugiego

1. Zrób z AGENTS.md jedyne źródło instrukcji. Każde narzędzie albo go czyta, albo da się je na niego wskazać, a z trzech formatów tylko ten jest otwartym standardem. Wybierz swój kierunek poniżej.

2. Uruchom importer, najpierw w trybie dry-run. Oba CLI go mają. Przenosi serwery MCP, polecenia i skille szybciej niż ty ręcznie, a dry-run pokazuje, co zostałoby nadpisane.

3. Przepisz serwery MCP na format docelowy i czytaj każdy sekret ze zmiennych środowiskowych.

4. Zmapuj uprawnienia i pracę równoległą na model nowego narzędzia, żeby agent ani nie pytał o każde polecenie, ani nie działał bez sandboxa.

5. Potwierdź migrację przebiegiem porównawczym, zanim usuniesz cokolwiek ze starej konfiguracji.

Krok 1: scal instrukcje w AGENTS.md

Przechodzisz z Claude Code

Zmień nazwę CLAUDE.md, żeby Codex go czytał, a potem daj Claude Code jednolinijkowy wskaźnik z powrotem:

# terminal, repository root
git mv CLAUDE.md AGENTS.md
printf '@AGENTS.md\n\n## Claude Code only\n' > CLAUDE.md

Linia @AGENTS.md to natywny import. Działa na każdym kanale wydań i w repozytoriach, które trzymają oba pliki. Wbudowany fallback Claude Code tak nie działa: gdy istnieje CLAUDE.md, Claude Code czyta tylko ten plik. Wszystko, co naprawdę dotyczy tylko Claude’a, na przykład uwagę o hooku albo subagencie, umieść pod nagłówkiem Claude Code only.

Przechodzisz z Codexa

Zostaw AGENTS.md tam, gdzie jest. Dodaj CLAUDE.md, który go importuje, żeby plik działał na każdej wersji, także starszej niż v2.1.277:

# terminal, repository root
printf '@AGENTS.md\n' > CLAUDE.md

Cursor nie potrzebuje wygenerowanej reguły: czyta AGENTS.md w katalogu głównym projektu i w podkatalogach, a CLAUDE.md czyta tak samo i zawsze go stosuje (dokumentacja reguł i pomoc Cursora, sprawdzone 2026-10-12). Kopia tego samego tekstu w Rules powtórzyłaby to, co Cursor już czyta, więc .cursor/rules/ zostaw na reguły, których potrzebuje tylko Cursor. Jeśli mimo to chcesz, żeby narzędzie generowało pliki dla poszczególnych narzędzi, kompromisy między rulesync, Rulerem i zwykłym importem @AGENTS.md opisuje strona o jednym źródle reguł dla każdego agenta.

Przechodzisz z Cursora

Cursor trzyma instrukcje w kilku plikach reguł. Scal je w jeden AGENTS.md promptem poniżej, a potem dodaj wskaźnik @AGENTS.md dla Claude Code. Zachowaj reguły Cursora, dopóki przebieg porównawczy nie przejdzie, a potem usuń te, których treść jest już w AGENTS.md: Cursor czyta AGENTS.md bezpośrednio (dokumentacja reguł Cursora, sprawdzone 2026-10-12), więc reguła, która go powtarza, tylko go dubluje. Zostaw w .cursor/rules/ plik tylko dla reguł, które dotyczą samego Cursora.

# terminal, repository root, after the agent has written AGENTS.md
printf '@AGENTS.md\n' > CLAUDE.md

Prompt do skopiowania: scal wszystkie pliki instrukcji w jeden AGENTS.md

Build a single AGENTS.md at the repository root from every instruction file in this repo:
CLAUDE.md, AGENTS.md, everything under .cursor/rules/, and any nested CLAUDE.md or AGENTS.md.

Rules:
1. Sections, in this order: Project overview, Commands, Architecture, Conventions,
   Testing and verification, Boundaries (things the agent must never do), PR rules.
2. Every command you list must exist in package.json, a Makefile, or a script in the repo.
   Run each one once and keep only those that exit 0 or fail for a reason you can explain.
3. Keep only instructions that apply to every agent. Move anything tool-specific
   (slash commands, hooks, IDE shortcuts, @-mentions) into a separate list at the end
   titled "Tool-specific, not migrated", with the source file for each line.
4. Merge duplicates and resolve contradictions by picking the stricter rule; list every
   contradiction you resolved and which side you chose.
5. Do not invent conventions that are not in the source files or visible in the code.
Show me the contradiction list and the not-migrated list before you write the file.

W monorepo powtórz ten wzorzec w każdym katalogu, który ma własne instrukcje: packages/api/AGENTS.md z treścią i packages/api/CLAUDE.md, który zawiera tylko @AGENTS.md.

Krok 2: uruchom importer i przeczytaj dry-run

Oba CLI importują konfigurację pozostałych narzędzi. Żaden import nie jest pełną migracją, więc najpierw uruchom dry-run i potraktuj jego wynik jako listę kontrolną.

Do Claude Code

claude import codex --dry-run     # or: claude import cursor --dry-run
claude import codex               # opens a picker; choose what to bring over

Według dokumentacji poleceń Anthropic (sprawdzone 2026-09-26) /import przenosi pliki instrukcji, serwery MCP, polecenia, subagentów i skille. Ponieważ może przenieść pliki instrukcji, uruchom go po kroku 1 i sprawdź, czy nie odtworzył drugiej kopii twoich reguł w CLAUDE.md.

Do Codexa

Uruchom codex w repozytorium i wpisz /import. W 0.157.1 proponuje „import setup, this project, and recent chats from Claude Code”, a opis polecenia w 0.162.1 brzmi tak samo (sprawdzone 2026-10-12). Żaden nie wymienia Cursora. Według notatek wydań 0.145.0 i 0.147.0 (sprawdzone 2026-09-26) import obejmuje też Cursora: ustawienia, serwery MCP, pluginy, sesje, polecenia i skille zarządzane przez Cursora. Uruchom go i sprawdź, co proponuje, zanim na tym polegniesz.

Zaufaj projektowi, gdy Codex o to zapyta. Od 0.150.0 niezaufane projekty nie dostarczają AGENTS.md na poziomie projektu, więc niezaufany checkout działa bez żadnej z twoich instrukcji.

Do Cursora

Żadne z CLI nie eksportuje do Cursora, a importera w Cursorze nie dało się potwierdzić 2026-09-26. Cursor czyta AGENTS.md bezpośrednio (krok 1, zakładka Codex), więc ręcznie napisz tylko .cursor/mcp.json (krok 3) i zainstaluj skille przez CLI skills (poniżej).

Skille przenoszą się dzięki standardowi Agent Skills: katalog z SKILL.md działa we wszystkich trzech narzędziach, różni się tylko lokalizacja. npx skills add <owner/repo> (npm skills 1.7.0) instaluje skill w każdym wykrytym agencie. Pluginy się nie przenoszą: pluginy Claude Code, Codexa i Cursora pochodzą z różnych marketplace’ów, więc w nowym narzędziu zainstaluj odpowiednik.

Krok 3: przepisz serwery MCP na format docelowy

Serwery są te same, zmienia się tylko opakowanie. Przykład używa dwóch oficjalnych serwerów zdalnych: serwera MCP GitHuba i Context7. Serwer GitHuba czyta token ze zmiennej GITHUB_PAT w twojej powłoce, nigdy z commitowanego pliku; Context7 go nie potrzebuje.

Claude Code

# writes .mcp.json, which is safe to commit because it holds only a variable reference
claude mcp add --scope project --transport http context7 https://mcp.context7.com/mcp
claude mcp add --scope project --transport http github https://api.githubcopilot.com/mcp/ \
  -H 'Authorization: Bearer ${GITHUB_PAT}'
claude mcp list

Pojedyncze cudzysłowy zostawiają ${GITHUB_PAT} dosłownie. Claude Code rozwija zmienną ze środowiska przy każdym starcie serwera.

Codex

codex mcp add context7 --url https://mcp.context7.com/mcp
codex mcp add github --url https://api.githubcopilot.com/mcp/ --bearer-token-env-var GITHUB_PAT
codex mcp list

To zapisuje w ~/.codex/config.toml (przetestowane na 0.157.1):

[mcp_servers.context7]
url = "https://mcp.context7.com/mcp"

[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/"
bearer_token_env_var = "GITHUB_PAT"

Nie kopiuj obiektu JSON headers do TOML. Codex parsuje headers = { … } bez błędu i go odrzuca. Klucze nagłówków, które czyta, to bearer_token_env_var, http_headers, env_http_headers i http_headers_helper (tak wymienia je codex mcp get w 0.157.1).

Cursor

{
  "mcpServers": {
    "context7": { "url": "https://mcp.context7.com/mcp" },
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "Authorization": "Bearer ${env:GITHUB_PAT}" }
    }
  }
}

Zapisz to jako .cursor/mcp.json. Interpolacja ${env:NAME} pochodzi z dokumentacji MCP Cursora cytowanej w naszym researchu, a nie z pobrania strony 2026-09-26, więc sprawdź ją na swojej wersji, zanim zacommitujesz plik.

Jedna różnica protokołu przetrwa tłumaczenie. Claude Code domyślnie negocjuje specyfikację MCP 2026-07-28 z bezpośrednimi serwerami HTTP. Codex 0.157.1–0.162.1 tego nie robi (jego funkcja mcp_2026_07_28 jest wciąż w budowie i wyłączona, sprawdzone 2026-10-12), więc serwer może zachowywać się inaczej w obu narzędziach nawet przy identycznym wpisie.

Krok 4: zmapuj uprawnienia i pracę równoległą

Najwięcej problemów sprawia autonomia agenta. Agent, który w starym narzędziu mógł uruchamiać twoje testy, w nowym zatrzymuje się i pyta, albo odwrotnie: flaga skopiowana z bloga wyłącza sandbox.

Na czym polegasz	Claude Code	Codex	Cursor
Edycja plików, kontrola ryzykownych poleceń	Tryb auto (tryb startowy sesji interaktywnych od v2.1.283); --permission-mode acceptEdits dla autonomii tylko przy edycjach	-a on-request (domyślnie) z --sandbox workspace-write; jeśli zamiast ciebie ma decydować model recenzujący, --approve-for-me	Run modes: Auto-review, Allowlist i Run Everything, w Settings > Agents > Approvals & Execution (dokumentacja Cursora, sprawdzone 2026-10-12)
Przebieg bezobsługowy w skrypcie	claude -p (startuje w trybie Manual, a od v2.1.285 w trybie auto u zewnętrznych dostawców lub z wyłączoną telemetrią; narzędzia dopuść przez --allowedTools)	codex exec (-a przed exec: codex -a never exec …)	tryb print w CLI Cursora (-p) (wg dokumentacji headless Cursora, sprawdzone 2026-08-28)
Izolowane sesje równoległe	claude --worktree albo --bg	codex --worktree albo Codex cloud	Worktrees albo Cloud Agents

Dwie poprawki do porad, które mogłeś stosować. Po pierwsze, codex "prompt" uruchamia interaktywną sesję lokalną w bieżącym checkoucie, a nie sandbox w chmurze. Pięć takich sesji w pięciu terminalach edytuje te same pliki, chyba że każda działa z --worktree. Po drugie, codex --full-auto nie istnieje w 0.157.1; użyj --approve-for-me albo profilu uprawnień. --dangerously-skip-permissions i --dangerously-bypass-approvals-and-sandbox zostaw wyłącznie dla jednorazowych sandboxów z ograniczoną siecią. Pełny model dla każdego narzędzia opisuje strona o uprawnieniach i sandboxingu agentów.

Jak udowodnić, że migracja działa, bez czytania każdego diffu?

Przepuść jeden zamknięty ticket przez obu agentów z tego samego commita i pozwól, żeby rozstrzygnęły bramki samego repozytorium. Wybierz ticket ze scaloną poprawką i testem, który przed nią nie przechodził. Ten test to twoja wyrocznia: tej części żaden agent nie może zmienić.

# terminal: two isolated checkouts of the commit before the fix
git worktree add ../parity-old BASE_SHA
git worktree add ../parity-new BASE_SHA
# dependencies are installed before either agent starts
(cd ../parity-old && npm ci) && (cd ../parity-new && npm ci)

# copy the oracle test from the fix commit into both checkouts and commit it there
for d in ../parity-old ../parity-new; do
  git -C "$d" checkout FIX_SHA -- path/to/oracle.test.ts
  git -C "$d" commit -qm "oracle test"
  # record the oracle commit; the gate diffs against it, so an agent's own commits are still checked
  git -C "$d" tag "oracle-$(basename "$d")"
done
# the oracle must fail before either agent runs
(cd ../parity-old && npx vitest run path/to/oracle.test.ts) && echo "ORACLE PASSES AT BASE: pick another ticket"

# old tool (Codex here), headless, sandboxed to the workspace, transcript kept
(cd ../parity-old && codex exec --json --sandbox workspace-write "$(cat ../parity-task.md)" > ../run-old.jsonl)

# new tool (Claude Code here), headless, edits allowed, the same commands AGENTS.md lists
(cd ../parity-new && claude -p "$(cat ../parity-task.md)" --permission-mode acceptEdits \
  --allowedTools "Bash(npm test *)" "Bash(npm run *)" \
  --output-format stream-json --verbose > ../run-new.jsonl)

# the gate, identical for both
for d in ../parity-old ../parity-new; do
  base="oracle-$(basename "$d")"
  (cd "$d" && git add -A \
    && git diff --cached --quiet "$base" -- path/to/oracle.test.ts \
         ':(glob)**/*.test.*' ':(glob)**/*.spec.*' 'test/**' 'tests/**' \
    && npm test && npm run lint && git diff --cached --stat "$base") || echo "FAILED: $d"
done

# did each agent run the commands AGENTS.md lists?
for f in ../run-old.jsonl ../run-new.jsonl; do
  grep -q 'npm test' "$f" && grep -q 'npm run lint' "$f" || echo "MISSING COMMANDS: $f"
done

Zastąp FIX_SHA scaloną poprawką, a BASE_SHA jej rodzicem. Test-wyrocznia pochodzi z commita poprawki, więc w BASE_SHA go nie ma: skopiuj go, zanim ruszą agenci, i sprawdź, że tam nie przechodzi, bo inaczej npm test może przejść, choć ticket nie jest rozwiązany. Zamień npx vitest run na własne polecenie uruchamiające jeden test, wpisz do pathspec bramki każde miejsce, w którym twoje repozytorium trzyma testy (testy obok kodu, katalogi snapshotów, fixtures), dopasuj listę poleceń do tego, co wymienia twój AGENTS.md, a w parity-task.md umieść treść ticketu, kryteria akceptacji i zdanie „do not edit the test files”. Zanim cokolwiek uruchomisz, sprawdź przez codex mcp list, czy Codex widzi twoje wpisy MCP, a przez codex --strict-config exec "Reply OK", czy rozpoznaje każdy klucz (wskazuje każdy nieznany klucz; --strict-config nie działa z codex mcp, sprawdzone na 0.157.1).

Oba checkouty muszą być dla Codexa zaufanymi projektami, inaczej ignoruje w nich AGENTS.md, a codex exec nie potrafi wyświetlić pytania o zaufanie. Najpierw oznacz je jako zaufane: uruchom raz interaktywnie codex w każdym worktree i zaakceptuj pytanie albo dopisz obie ścieżki bezwzględne do ~/.codex/config.toml (format klucza sprawdzony na 0.157.1):

[projects."/abs/path/to/parity-old"]
trust_level = "trusted"

[projects."/abs/path/to/parity-new"]
trust_level = "trusted"

Potem dopisz do parity-task.md zdanie Before you start, list the instruction files you loaded. i odrzuć przebieg, który nie wymieni żadnego pliku.

Migracja przechodzi, gdy bramka nie wypisuje ani FAILED, ani MISSING COMMANDS: oba przebiegi są zielone na tych samych testach, żaden agent nie zmienił pliku testowego, a oba zapisy przebiegu pokazują polecenia wymienione w AGENTS.md. grep trafia też na polecenie, które agent tylko przeczytał, więc otwórz zapis przebiegu, gdy któryś przebieg skończył się podejrzanie szybko. Potem porównaj statystykę zmian z sekcją Boundaries. Claude Code dostaje Bash(npm test *) i Bash(npm run *), żeby mógł uruchomić każde polecenie wymienione w AGENTS.md; dodaj każde inne polecenie, które wymienia twój AGENTS.md, bo inaczej porównanie faworyzuje Codexa, który w swoim sandboxie workspace może uruchomić cokolwiek. Podpisujesz się pod tymi dowodami, a nie pod diffem. Jeśli chcesz drugiej opinii o obu diffach, użyj promptu poniżej.

Prompt do skopiowania: porównaj przebiegi dwóch agentów na tym samym tickecie

Two agents implemented the same ticket from the same commit. Their checkouts are ../parity-old
and ../parity-new. The ticket and acceptance criteria are in ../parity-task.md, and
AGENTS.md in each checkout holds the project rules.

Do not fix anything. Produce a table with one row per check and one column per checkout:
1. Each acceptance criterion: met / not met, with the file and line that shows it.
2. Test files modified (list them; any modification is a failure).
3. Paths touched that AGENTS.md lists under Boundaries.
4. Commands from the Commands section of AGENTS.md that the change would break.
5. New dependencies added.
6. Diff size (files, lines added, lines removed).
End with the one difference most likely to be caused by the instructions rather than the
model, and the AGENTS.md line you would change to remove it.

Powtarzaj przebieg porównawczy w obu kierunkach po każdej istotnej zmianie AGENTS.md. Najtańszym zabezpieczeniem przed późniejszym rozjazdem jest krok CI, który kończy się błędem, gdy CLAUDE.md przestaje importować wspólny plik:

# CI step
grep -qx '@AGENTS.md' CLAUDE.md || { echo "CLAUDE.md must import AGENTS.md"; exit 1; }

Prompt do skopiowania: test dymny serwerów MCP po przeniesieniu

List every MCP server and tool you can see in this session. For each server, call exactly
one read-only tool (for GitHub: read the latest release of this repository; for Context7:
resolve the library id for the main framework in package.json) and report the result in
one line. For any server that fails, give the exact error and say whether it looks like
authentication, transport, or a missing server. Do not change any configuration.

Co się psuje przy przenoszeniu repozytorium między Codexem, Claude Code i Cursorem?

Claude Code ignoruje AGENTS.md. Repozytorium ma CLAUDE.md (więc fallback nigdy się nie włącza), kolega ma wersję starszą niż v2.1.277 albo przełącznik w Project instructions w /config jest wyłączony. Naprawa: ustaw @AGENTS.md jako pierwszą linię CLAUDE.md. To działa we wszystkich trzech przypadkach.

Codex działa tak, jakby nie było instrukcji. Projekt jest niezaufany, a od 0.150.0 niezaufany projekt nie dostarcza AGENTS.md na poziomie projektu. Naprawa: zaufaj projektowi, gdy Codex zapyta, a potem zapytaj go, które pliki instrukcji wczytał.

Serwer MCP traci token tylko w Codexie. Ktoś wkleił obiekt JSON headers do config.toml, a Codex odrzucił go bez błędu. Naprawa: dodaj serwer ponownie z --bearer-token-env-var i uruchom codex --strict-config exec "Reply OK", żeby wyłapać inne nieznane klucze.

Serwer działa w Claude Code, ale w Codexie zachowuje się inaczej. Oba narzędzia negocjują różne wersje protokołu MCP. Naprawa: przetestuj serwer konkretnie w Codexie i sprawdź w jego README uwagę o zgodności ze specyfikacjami sprzed 2026-07-28.

Importer zdublował reguły. claude import albo /import w Codexie zapisał drugą kopię instrukcji, które już scaliłeś. Naprawa: najpierw uruchamiaj dry-run, usuń duplikat i zostaw AGENTS.md jako jedyny plik z treścią.

Token trafił do gita. Ktoś przy debugowaniu zastąpił ${GITHUB_PAT} dosłowną wartością. Naprawa: najpierw unieważnij i zrotuj token, a dopiero potem usuń go z historii. Samo przepisanie historii nie chroni tokenu, który już został wypchnięty.

Wyniki pogorszyły się po zmianie. Prompty i AGENTS.md były dostrojone do starego modelu. Naprawa: nie zmieniaj najpierw modelu. Podnieś effort na modelu domyślnym, powtórz przebieg porównawczy i zmień instrukcję, którą wskazuje prompt porównujący.

Sesje równoległe nadpisały sobie nawzajem pracę. Kilka sesji działało w jednym checkoucie. Naprawa: daj każdej sesji własne worktree (--worktree w obu CLI, Worktrees w Cursorze) i scalaj przez pull requesty.

Dokąd dalej po zmianie agenta

Codex w porównaniu z Claude Code i Cursorem Zdecyduj, który agent odpowiada za jaki rodzaj pracy, zanim cokolwiek przeniesiesz.

Jedno źródło reguł dla każdego agenta AGENTS.md, Ruler i rulesync w porównaniu, z kontrolą rozjazdu w CI.

Wspólny kontekst i reguły zespołu Zamień przeniesioną konfigurację w standard zespołu.

Przewodnik po migracji narzędzi Lista kontrolna zmiany głównego agenta, narzędzie po narzędziu.

Uprawnienia i sandboxing agentów Ustaw autonomię w nowym narzędziu bez wyłączania sandboxa.

Playbook konwersji projektu Przygotuj resztę repozytorium do pracy z agentami.