Claude Code en Codex in Dezelfde Repository: Mijn Echte Setup

Claude Code en Codex in Dezelfde Repository: Mijn Echte Setup

Ik was altijd een Claude Code-loyalist. Niet op een tribale manier — meer op een "dit is de agent die ik vertrouw, dit is degene die ik heb afgestemd, het spiergeheugen is opgebouwd" manier. Anthropic bracht een update uit, ik installeerde het. Anthropic had een storing, ik wachtte. Het idee om een tweede CLI parallel te draaien voelde als vreemdgaan van een tool dat mijn workflow had verdiend.

Toen ging vorige maand, op een woensdagmiddag, Claude's API-statuspagina oranje. Daarna rood. Aria — mijn content-agent — was halverwege een batch van vier berichten. Ik zat 47 minuten naar de draaiende spinner te staren. Tegen de tijd dat de API weer werkte, had ik de ochtend verloren en het geduld om een one-CLI-engineer te blijven.

Dus deed ik wat ik had vermeden. Ik opende een tweede terminalpaneel, draaide codex in dezelfde repo, en begon mezelf te leren hoe ik daadwerkelijk in beide ecosystemen tegelijk kon leven. Niet de marketingversie waarin je de twee tools "vergelijkt" en een winnaar kiest. De saaie, gedetailleerde versie waarin je beide draait, op dezelfde codebase, met dezelfde projectcontext, met skills die meestal in beide CLI's werken, en een sessie-overdrachtskunst waarmee je werk tussen ze kunt doorgeven als een van hen vastloopt.

Dat is wat dit bericht is. Niet "Claude Code vs Codex." Het is "Claude Code en Codex, in dezelfde projectmap, met één gedeeld brein en een overdrachts-skill die storingen overleeft." Ik draai deze setup nu ongeveer zes weken. De eerste drie weken waren ruw. De laatste drie zijn de meest veerkrachtige ontwikkelomgeving die ik ooit heb gehad.

Laat me je precies laten zien hoe het is aangesloten.

Waarom Ik Stopte Met Kiezen Tussen Claude Code en Codex

Vóór de setup, een kort woord over de mentaliteitsverandering — want de bedrading doet er alleen toe als de filosofie eronder klopt.

Het grootste deel van 2025 was het CLI-agent-gesprek tribaal. Je was een Claude Code-persoon, of een Codex-persoon, of een Cursor-persoon, of een Gemini CLI-persoon. De redenen waren echt: elke tool had andere ergonomie, ander modelgedrag, andere configuratiebestanden, en wisselen kostte echte tijd. Eén kiezen en diep gaan was logisch.

Twee dingen veranderden voor mij in 2026.

Het eerste waren storingen. Niet specifiek Anthropic's schuld — elke grote modelprovider heeft dit jaar minstens één zware dag gehad. OpenAI had een meerdere uren durend incident in februari. Anthropic had de API-hapering die ik hierboven noemde. Google's Gemini-kant had een model-routeringsbug in maart die stilletjes de antwoorden verslechterde urenlang voordat iemand het merkte. Als je hele workflow achter één provider zit, kost één storing je hele dag. Dat is geen technologieprobleem — het is een single-point-of-failure-probleem.

Het tweede was de sleur. Soms raakt Claude Code vast. Niet "kapot" vast — creatief vast. Het kiest een aanpak, gaat ermee aan de slag, en als die aanpak niet werkt, blijft het dezelfde aanpak harder verfijnen. Ik heb Opus 40 minuten zien proberen om een wankele test betrouwbaar te maken door herhaalpogingen toe te voegen terwijl de echte fix was om de test in een andere stijl te herschrijven. Een tweede agent — niet als vervanging, maar als second opinion — doorbreekt de sleur meestal in één prompt. Wisselen van CLI is de goedkoopste manier die ik heb gevonden om een fris modelperspectief te krijgen zonder projectcontext te verliezen.

Dus het doel is niet "kies de beste CLI." Het doel is tool-agnosticisme: bouw een setup waarin Claude Code en Codex allebei op dezelfde codebase kunnen werken, met dezelfde projectkennis, en je kunt tussen ze wisselen zonder je plek te verliezen. De CLI wordt uitwisselbaar. De projectcontext is wat heilig is. Dit is hetzelfde instinct waar ik over schreef in mijn twee-agent supervisor-builder workflow, alleen verder doorgetrokken: niet alleen twee agents, maar twee hele CLI's behandeld als uitwisselbaar.

Nu, de bedrading.

Het Gedeelde Brein: CLAUDE.md en AGENTS.md Bevatten (Bijna) Hetzelfde

Het eerste wat ik leerde toen ik serieus begon met het draaien van beide agents in dezelfde repo is dit: de twee ecosystemen zijn het al meer eens dan de marketing impliceert. Zowel Claude Code als Codex lezen bij het opstarten een project-level markdown-bestand. Claude Code leest CLAUDE.md. Codex leest AGENTS.md. De inhoud is bijna uitwisselbaar. Het formaat is platte markdown. De bedoeling is dezelfde: vertel de agent wat dit project is, wat de conventies zijn, welke tools te gebruiken, welke tests te draaien, en wat niet aan te raken.

Toen ik de parallelle workflow voor het eerst opzette, maakte ik de beginnersfout om twee aparte bestanden te schrijven en ze handmatig synchroon te houden. Dat duurde ongeveer vier dagen voordat de drift de agents het oneens maakte over basisdingen — Codex dacht dat we pnpm gebruikten, Claude Code dacht dat we npm gebruikten, en een muntworp bepaalde welk op elk willekeurig moment gelijk had.

De fix is een van twee patronen, en beide werken:

Patroon A — Symlink de een naar de ander. Kies het bestand dat je als bron van waarheid wilt (ik koos AGENTS.md omdat het de cross-vendor standaard aan het worden is) en symlink de andere ernaar:

# vanuit de projectroot, met AGENTS.md als canoniek
mv CLAUDE.md AGENTS.md   # als je begint vanuit CLAUDE.md
ln -s AGENTS.md CLAUDE.md

Nu lezen beide agents hetzelfde bestand. Bewerk AGENTS.md, beide CLI's zien de update bij de volgende start. Dit is wat de Onur Solmaz migratiegids aanbeveelt en wat ik in de meeste van mijn repo's draai.

Patroon B — Houd ze apart maar dwing synchronisatie af. Als je wilt dat elk bestand een paar tool-specifieke regels heeft (sommige skills gedragen zich anders in de ene versus de andere), houd beide bestanden en schrijf een pre-commit hook die het gedeelde gedeelte vergelijkt en waarschuwt als ze uit de pas lopen. Dit is zwaarder, maar het stelt je in staat om een # Claude Code-specifiek blok onderaan het ene te hebben en niet het andere.

Ik begon met Patroon B en migreerde alles naar Patroon A binnen twee weken. De onderhoudskosten van het synchroon houden van twee bestanden waren hoger dan de waarde van een paar tool-specifieke regels.

Welk patroon je ook kiest, dit is wat er daadwerkelijk in dat gedeelde bestand moet staan. Dit is het gedeelte van mijn echte AGENTS.md voor de repo waar ik al deze content schrijf:

# Project: my-ai-crew

## Wat dit is
Multi-merk contentgeneratiesysteem. Vier merken, elk met een
onderscheidende stem. Berichten worden opgeslagen in content/{merk}/[slug].md.
Geen buildsysteem, geen tests — de workflow is agent-gestuurd.

## Conventies
- Alle artikelbestanden beginnen met `**BRAND:**` — nooit YAML frontmatter.
- META DESCRIPTION moet 150-160 tekens zijn. Tel voor het opslaan.
- Minimumaantal woorden: 3.000.
- Merkstemmen zijn gedefinieerd in .claude/agents/aria.md (niet bewerken
  zonder expliciete instructie).

## Beschikbare tools
- WebSearch — gebruik voor feitverificatie, raad nooit versies/prijzen
- Glob — scan content/{merk}/*.md voor het schrijven
- Read, Write, Edit — standaard bestandsbewerkingen

## Wat NIET te doen
- Voer geen git commit uit tenzij expliciet gevraagd.
- Voeg geen Co-Authored-By-regels toe zonder instructie.
- Genereer geen placeholder-metrics — gebruik echte cijfers of laat weg.

## Merkmappen
- content/mejba.me/ — persoonlijke praktijkstem
- content/ramlit.com/ — bureau, zakelijk gericht
- content/colorpark.io/ — designbureau, eigenwijs
- content/xcybersecurity.io/ — beveiliging, gezaghebbend

Beide CLI's lezen dit. Beide agents kennen nu de conventies. De eerste keer dat je dit bestand goed schrijft, is de eerste keer dat je twee-CLI-setup daadwerkelijk coherent aanvoelt in plaats van schizofreen.

Er is één subtiliteit die het vermelden waard is. Claude Code ondersteunt geneste CLAUDE.md-bestanden in submappen — wanneer de agent een bestand leest in content/colorpark.io/, kan het extra instructies oppikken van een CLAUDE.md die in die submap is geplaatst. Codex heeft een soortgelijk mechanisme: wanneer je cd doet naar een submap, voegt het de AGENTS.md-bestanden samen van de huidige map tot aan de repo-root, waarbij dichterbije bestanden eerdere overschrijven (dit is gedocumenteerd in de Codex AGENTS.md-gids). Als je symlinkt op het rootniveau, kun je ook symlinken op het submapniveau. Beide ecosystemen werken goed samen.

De Bestands- en Mappenkaart: Waar Elke CLI Kijkt

Als het gedeelde brein eenmaal is aangesloten, is de volgende vraag: waar staat al het andere? Skills, agents, configuratie, slash-commando's. Beide CLI's hebben hun eigen mappenstructuur, en je hebt een mentale kaart nodig.

Dit is degene die ik vastgepind houd in mijn eigen notities:

Een paar kanttekeningen bij deze tabel omdat ze me de eerste keer in de war brachten:

Configuratieformaat is het grootste formaatgap. Claude Code gebruikt JSON voor settings.json. Codex gebruikt TOML voor config.toml. Als je nog nooit TOML hebt geschreven, het is halverwege YAML en INI — sleutels, waarden, secties in vierkante haken. Niet moeilijk, maar je kunt je settings.json niet in config.toml plakken en verwachten dat het werkt. Conversie is mechanisch maar handmatig. (Of, zoals ik zo laat zien, je laat Claude Code het voor je doen.)

Slash-commando's en skills convergeren in Codex. OpenAI's officiële documentatie zegt nu dat custom prompts zijn verouderd ten gunste van skills. Dus in 2026, als je herbruikbare instructies schrijft voor Codex, schrijf je ze als skills, niet als custom prompts. Claude Code maakt nog steeds onderscheid tussen commando's (in .claude/commands/) en skills (in .claude/skills/), maar het verschil wordt kleiner. Beide ecosystemen komen uit op "een skill is een markdown-bestand met frontmatter dat beschrijft wanneer het moet activeren." Goed nieuws voor portabiliteit.

Sub-agents wijken meer af dan je zou verwachten. Claude Code's sub-agents dispatchen automatisch — de hoofdagent leest de beschrijvingen van elk .claude/agents/*.md-bestand bij het opstarten, en routeert werk ernaar wanneer een taak overeenkomt. Codex vereist expliciete aanroep. Je kunt agents bouwen in .codex/agents/, maar Codex routeert niet automatisch naar ze; jij vertelt Codex welke agent te gebruiken. Ik kom terug op dit verschil omdat het het ding is dat het meest verandert hoe je werkt.

Skills Zijn Meestal Overdraagbaar. Agents Hebben een Conversie Nodig.

De reden dat deze hele setup werkt is dat de meeste markdown-bestanden in .claude/ en .codex/ structureel hetzelfde zijn. Een skill is een map met een SKILL.md erin. De SKILL.md heeft YAML-frontmatter met name en description, dan een markdown-body met instructies. Die specificatie is aan beide kanten hetzelfde. Wat betekent dat een skill die ik voor Claude Code heb geschreven, in Codex valt met meestal nul wijzigingen.

Ik heb dit direct getest. Mijn caveman-skill — de ultra-gecomprimeerde communicatiemodus die tokengebruik met ~75% vermindert (ik schreef eerder over het bouwen van de caveman-skill voor Claude Code) — was oorspronkelijk geschreven voor Claude Code. Ik kopieerde de caveman/-map van .claude/skills/ naar .codex/skills/, herstartte Codex, en de skill activeerde correct bij de eerste prompt. Geen formaatwijzigingen. Geen frontmatter-herschrijvingen. Het werkte gewoon.

De skills die niet schoon overgaan zijn degenen die verwijzen naar Claude-Code-specifieke toolnamen. Als je skill zegt "gebruik de Glob-tool" — Codex heeft geen tool genaamd Glob. Het heeft shell-toegang, dus de agent kan nog steeds bestanden globben via find of ls, maar je zult de skill moeten herschrijven om naar shell-bewerkingen te verwijzen of accepteren dat de skill minder betrouwbaar zal werken. Ongeveer 80% van de skills die ik heb gemigreerd hadden nul wijzigingen nodig. De andere 20% had lichte bewerkingen aan toolverwijzingen nodig.

Sub-agents zijn waar de conversie echt wordt. De frontmatter is vergelijkbaar (name, description, model, tools) maar het dispatch-model is anders — en dat verandert hoe je de body van de agent schrijft. Een Claude Code-agent is geschreven in de veronderstelling dat het automatisch wordt aangeroepen wanneer een taak overeenkomt met zijn beschrijving. Een Codex-agent is geschreven in de veronderstelling dat je het expliciet zult aanroepen. Dus:

• Claude Code-agentbeschrijvingen zijn geschreven voor het dispatchende model om te lezen. Ze zeggen "gebruik deze agent wanneer X nodig is" omdat de hoofdagent moet weten wanneer te delegeren.
• Codex-agentbeschrijvingen zijn geschreven voor de menselijke gebruiker om te lezen. Ze zeggen "deze agent behandelt X" omdat de mens degene is die werk routeert.

Wanneer je een agent migreert van de ene naar de andere, kopieer je niet gewoon het bestand. Je herschrijft de beschrijving vanuit het juiste perspectief. De body — de daadwerkelijke systeemprompt — draagt meestal over zonder wijzigingen.

Dit is het enige grootste praktische verschil tussen de twee ecosystemen, en het is de reden dat ik beide naast elkaar draai in plaats van ze als drop-in vervangingen te behandelen. Claude Code is beter in multi-agent-orkestratie omdat de dispatching automatisch is — ik behandelde de dispatch-mechanica in detail in mijn Claude Code agent teams playbook. Codex is beter in gecontroleerd, deterministisch agentgebruik omdat jij beslist welke agent draait. Verschillende sterktes, dezelfde bouwstenen.

De Conversieprompt Die Ik in Claude Code Plak om Codex op te Starten

Wanneer ik een nieuwe repo start en ik wil beide CLI's vanaf dag één klaar hebben, converteer ik niets handmatig. Ik schrijf eerst de Claude Code-setup (omdat dat het spiergeheugen is) en dan plak ik deze prompt in Claude Code en laat het het Codex-equivalent genereren.

Dit is de daadwerkelijke prompt. Kopieer het, plak het in Claude Code, en het doet de conversie voor je:

Ik wil dat deze repo in zowel Claude Code als Codex CLI naast elkaar werkt.
Op dit moment is de Claude Code-setup compleet. Ik heb je nodig om de
parallelle Codex-setup te genereren. Specifiek:

1. Lees CLAUDE.md en maak AGENTS.md met dezelfde inhoud, vervang dan
   CLAUDE.md met een symlink naar AGENTS.md. Gebruik:
     mv CLAUDE.md CLAUDE.md.bak
     # kopieer CLAUDE.md.bak-inhoud naar AGENTS.md
     ln -s AGENTS.md CLAUDE.md
     rm CLAUDE.md.bak  (alleen na verificatie dat de symlink werkt)

2. Lees .claude/settings.json en maak .codex/config.toml die de
   relevante instellingen spiegelt. Converteer JSON-syntax naar TOML.
   Sla Claude-Code-specifieke sleutels over die geen Codex-equivalent
   hebben (bijv. permissions, hooks) en voeg een opmerking toe die
   vermeldt wat is overgeslagen.

3. Kopieer voor elk bestand in .claude/skills/<naam>/SKILL.md naar
   .codex/skills/<naam>/SKILL.md. Controleer de body op verwijzingen
   naar Claude-Code-specifieke tools (Glob, Read tool, etc) en
   herschrijf ze als shell-equivalenten of markeer ze in een opmerking
   bovenaan het bestand.

4. Port NIET automatisch voor elk bestand in .claude/agents/<naam>.md
   naar .codex/agents/. Vermeld in plaats daarvan de agents en vraag me
   welke ik beschikbaar wil in Codex. Herschrijf voor de geselecteerde
   het description-veld zodat het geschikt is voor menselijke routing
   (Codex vereist expliciete aanroep, geen auto-dispatch) en kopieer
   de body ongewijzigd.

5. Schrijf na alle conversies een CONVERSION_LOG.md in de repo-root
   die elk aangemaakt of gewijzigd bestand vermeldt, elke overgeslagen
   sleutel, en elke toolverwijzing die is herschreven. Ik wil dit in
   30 seconden kunnen auditen.

Commit niets. Maak alleen de bestanden en het logboek aan.

De eerste keer dat ik dit draaide, deed Claude Code er ongeveer vier minuten over. Het meeste daarvan was de agent die elke skill las en besliste of elk Claude-Code-specifieke toolverwijzingen had. Het conversielog was nuttig omdat het twee skills ving die de Glob-tool bij naam verwezen — ik herschreef die om shell find te gebruiken, en nu werken beide versies van de skill in hun respectieve CLI's zonder verdere wijzigingen.

Je kunt ook de omgekeerde conversie draaien, van een Codex-setup naar een Claude Code-setup. De prompt is symmetrisch — wissel gewoon bron en doel om. Ik heb meestal één conversierichting als de canonieke setup-pipeline en de andere als eenmalige bootstrap.

De Sessie-Overdrachts-Skill: Context Verplaatsen Tussen Agents

Dit is het stuk waar niemand over praat: zelfs met een gedeelde AGENTS.md delen de agents zelf geen gespreksstatus. Wanneer je halverwege een taak wisselt van Claude Code naar Codex, weet de nieuwe agent niet wat je net aan het doen was. Het kent de projectconventies, maar niet de actieve intentie.

Dit is het moment waarop de meeste mensen de parallelle-CLI-setup opgeven. Ze proberen het een dag, botsen tegen een contextmuur wanneer ze van tool wisselen, en concluderen dat beide draaien "meer moeite is dan het waard is." Dat is het niet — maar alleen als je een bewuste overdracht hebt.

Ik heb een skill gebouwd die dit oplost. Het vangt de vier dingen op die er echt toe doen bij het overdragen van werk tussen agents: de actieve bestanden waar je aan hebt gewerkt, de huidige intentie (wat je probeert te doen), de blokkades (wat vastzit of mislukte), en de volgende stap (wat de ontvangende agent als eerste moet doen). Het schrijft die vier velden naar een .handoff.md-bestand in de repo-root. De ontvangende agent leest dat bestand bij de volgende prompt en weet precies waar op te pakken.

Dit is de daadwerkelijke skill, die zich bevindt op .claude/skills/session-handoff/SKILL.md:

---
name: session-handoff
description: Leg de actieve sessiestatus vast in .handoff.md zodat een andere CLI-agent (Codex, Gemini, etc.) het werk kan overnemen. Gebruik wanneer de gebruiker zegt "overdracht", "pass naar codex", "wissel agents", of "context voor volgende agent".
allowed-tools: Read, Write, Bash
---

# Sessie-Overdracht

Wanneer deze skill activeert, schrijf `.handoff.md` in de repo-root met deze
exacte vier secties. Wees kort. De ontvangende agent leest dit en
moet er direct naar handelen.

## Formaat

```markdown
# Sessie-Overdracht — [ISO-tijdstempel]
Van: [claude-code | codex | anders]

## Actieve bestanden
- [pad/naar/bestand:regelbereik] — [één-regel reden]
- [pad/naar/bestand] — [één-regel reden]

## Huidige intentie
[1-3 zinnen: wat we proberen te bereiken in deze werksessie]

## Blokkades
- [Specifiek ding dat vastzit. Inclusief foutmelding indien van toepassing.]
- [Of "geen" als het niet vastzit — gewoon wisselen voor fris perspectief.]

## Volgende stap
[Precies één zin. De enkele actie die de ontvangende agent als
eerste moet uitvoeren.]

Regels

• Neem GEEN volledige bestandsinhoud op. Alleen paden en regelbereiken.
• Vat het gesprek NIET samen. Leg status vast, geen geschiedenis.
• Als .handoff.md al bestaat, overschrijf het (niet toevoegen).
• Print na het schrijven "Overdracht geschreven naar .handoff.md" en sluit af.
• De ontvangende agent moet worden verteld (door de mens) om .handoff.md als eerste actie te lezen.

De spiegelskill in `.codex/skills/session-handoff/SKILL.md` is identiek behalve één wijziging — de beschrijving is herschreven omdat Codex niet automatisch dispatcht. De Codex-versie's beschrijving leest meer als een gebruikshint dan als een routeringssignaal. Hier is het verschil in gewone taal: Claude Code's beschrijving zegt "activeer dit wanneer de gebruiker X zegt." Codex's beschrijving zegt "gebruik deze skill om een overdrachtsbestand te schrijven."

Om een overdracht te activeren in Claude Code, typ ik gewoon "overdracht naar codex" — de skill pikt het sleutelwoord op en schrijft het bestand. Om het in Codex te activeren, typ ik `$session-handoff` (Codex's expliciete aanroepsyntax) en het doet hetzelfde. Dan wissel ik van tabblad, en het eerste wat ik de ontvangende agent vertel is: "Lees .handoff.md en ga verder."

Het overdrachtsbestand is meestal 15 tot 30 regels. De ontvangende agent leest het, heeft volledige context in vijf seconden, en begint te werken. Ik heb deze skill waarschijnlijk 200 keer gebruikt in de afgelopen zes weken. Het is het enige stukje lijm dat de parallelle-CLI-setup coherent laat voelen in plaats van gefragmenteerd.

Als je maar één ding bouwt uit dit hele bericht, bouw deze skill. Het is klein. Het bespaart uren. Als je nog nooit een Claude Code-skill vanuit het niets hebt gebouwd, loopt mijn [gids voor geavanceerde Claude Code-skills](https://www.mejba.me/blog/agent-skills-advanced-claude-code) door het formaat en de valkuilen.

## Hoe de Naast-Elkaar-Opstelling Er Daadwerkelijk Uitziet: VS Code Split Paneel

De bedrading hierboven is de statische setup. Hier is de dynamiek — hoe mijn scherm er daadwerkelijk uitziet tijdens een werksessie.

VS Code, gesplitst terminalpaneel, verticale oriëntatie. Linker paneel: Claude Code, draaiend op Opus 4.7, in de projectroot. Rechter paneel: Codex CLI, draaiend op GPT-5.4, dezelfde projectroot. Beide agents hebben dezelfde `AGENTS.md`. Beide hebben toegang tot dezelfde skills. Beide kunnen dezelfde bestanden bewerken (ze coördineren via het bestandssysteem, niet via cross-CLI-berichten — git is de bron van waarheid op de schijfstatus).

Ik start standaard met Claude Code voor het begin van elke sessie. Dat is de agent die ik het meest heb afgestemd, en het heeft mijn volledige set `.claude/agents/`-sub-agents beschikbaar. Ik plan, ik scaffold, ik maak de eerste 60% van de wijzigingen daar.

Ik wissel naar Codex in specifieke scenario's:

**Claude Code raakt vast op een aanpak.** Veertig minuten verder, het draait rond hetzelfde idee. Ik draai de overdrachts-skill, wissel naar Codex, en vraag het om hetzelfde probleem met verse ogen te bekijken. Ongeveer 70% van de tijd kiest Codex een andere invalshoek en deblokkeert het werk. De overige 30% is het eens met Claude Code's aanpak maar stelt een specifieke aanpassing voor die het laat werken. Hoe dan ook, de sleur doorbreekt.

**Lang, mechanisch refactorwerk.** De terminal-bench-prestaties van Codex CLI zijn oprecht sterker dan die van Claude Code bij routinematige shell-intensieve taken, volgens de [DeployHQ 2026-vergelijking](https://www.deployhq.com/blog/comparing-claude-code-openai-codex-and-google-gemini-cli-which-ai-coding-assistant-is-right-for-your-deployment-workflow) (Codex CLI haalde 77,3% op Terminal-Bench 2.0 vs Claude Code's 65,4%). Wanneer de taak is "hernoem 30 variabelen over 12 bestanden volgens dit patroon" of "draai de testsuite, parseer de fouten, schrijf fixes," is Codex sneller en gebruikt minder tokens.

**Claude API is down.** Dit is de oorspronkelijke reden dat ik de parallelle setup heb gebouwd. Wanneer Anthropic een incident heeft, wissel ik volledig naar het Codex-paneel en blijf werken. De skills dragen over. De projectcontext draagt over. Het enige wat ik verlies is de Aria-agent (omdat Aria Claude-Code-specifiek sub-agentgedrag heeft dat niet volledig vertaalt), en ik gebruikte Aria meestal niet voor het werk waarnaar ik naar Codex wissel.

**Tegensprekende review.** Wanneer ik een code-review wil die *niet* van hetzelfde model komt dat de code schreef, doe ik het werk in Claude Code, en vraag dan Codex om de diff te reviewen. Andere modellijn, andere trainingsdata, andere blinde vlekken. Ik vang zo bugs op die geen van beide agents vindt bij het reviewen van eigen werk. Ik schreef uitgebreid over dit patroon in [het Codex-plugin tegensprekende review-bericht](https://www.mejba.me/blog/codex-plugin-claude-code-adversarial-review) — hetzelfde idee, strakkere integratie wanneer je het wilt.

Het patroon dat na een paar weken opkwam: Claude Code is mijn primaire, Codex is mijn parallelle. Ik zit 70-80% van de tijd in Claude Code. Codex is 20-30%, plus 100% wanneer Claude down is.

## De Twee Setups Synchroon Houden (De Discipline)

Het hele systeem breekt als de twee setups uit de pas lopen. De meest voorkomende faalwijze die ik zie — ook in mijn eigen setup, wanneer ik lui word — is dat je `CLAUDE.md` bewerkt (wat nu de symlink is) en per ongeluk wijzigingen schrijft die alleen Claude Code begrijpt. Of je voegt een nieuwe skill toe aan `.claude/skills/` en vergeet het te spiegelen naar `.codex/skills/`. Twee weken later wissel je van CLI en ontdekt dat de helft van je tooling ontbreekt.

De discipline die daadwerkelijk voor mij werkt, na een paar iteraties:

**Bewerkingen aan het canonieke bestand worden standaard als "tool-agnostisch" beschouwd.** Als ik iets in `AGENTS.md` schrijf dat slechts één CLI zou moeten weten, zet ik het in een duidelijk gemarkeerde sectie onderaan: `# Alleen Claude Code` en `# Alleen Codex` blokken. Beide CLI's lezen het hele bestand, maar de sectiekoppen vertellen mij (de mens) welke regels waar van toepassing zijn. Vermindert onderhoudswerk enorm.

**Skillwijzigingen gaan door een sync-script.** Ik heb een klein shellscript dat nieuwe of gewijzigde bestanden kopieert van `.claude/skills/` naar `.codex/skills/` (en omgekeerd), waarbij toolnaam-overschrijvingen die ik al heb gemaakt behouden blijven. Ik draai het handmatig na het bewerken van een skill, vóór de volgende sessie. Vijf seconden werk, voorkomt de langzame drift.

**Sub-agentwijzigingen synchroniseren niet automatisch.** Ik laat agents in `.claude/agents/` voor Claude Code-gebruik, en port alleen handmatig degenen die ik actief in Codex wil. De meeste van mijn agents zijn alleen voor Claude Code omdat het automatische dispatchgedrag het hele punt is. De twee of drie die ik wel naar Codex port, houd ik handmatig synchroon omdat de beschrijvingen sowieso anders moeten zijn.

**Configuratiebestanden (`settings.json` en `config.toml`) worden nooit automatisch gesynchroniseerd.** Ze driften natuurlijk omdat ze verschillende instellingen blootleggen. Ik behandel ze als onafhankelijk, en ik bekijk ze eens per maand om te controleren dat ik geen onbedoeld gedragsverschil heb geïntroduceerd.

Dat is de operationele overhead, eerlijk gezegd. Ongeveer tien minuten per week aan expliciet syncwerk. In ruil daarvoor krijg ik twee CLI's die allebei mijn project kennen en er allebei uitwisselbaar aan kunnen werken.

## Wanneer de Naast-Elkaar-Setup Het Niet Waard Is

Ik zou liegen als ik zei dat deze setup voor iedereen geschikt is.

Als je nieuw bent met Claude Code, doe dit nog niet. Stem Claude Code eerst af. Zorg dat je `CLAUDE.md` goed is, bouw een handvol skills, raak gewend aan hoe sub-agents werken. Codex toevoegen op dag één betekent dat je twee CLI's tegelijk leert, en je raakt in de war over welk gedrag van welke tool komt. Kies er één, ga diep, voeg dan de andere toe.

Als je werk vooral binnen de tooling van één ecosysteem zit — intensief Claude Skills-gebruik, veel MCP-servers specifiek aangesloten op Claude, sub-agents die afhangen van auto-dispatch — betaalt de parallelle setup zich misschien niet terug. De overdraagbare laag is voor jou kleiner dan voor iemand die beide tools voornamelijk gebruikt via platte markdown-skills.

Als je een solodev bent die een zijproject in het weekend bouwt, doet het veerkracht-argument er minder toe. Een storing kost je zaterdagmiddag. Vervelend, niet catastrofaal. De parallelle setup betaalt zich het hardst terug wanneer je levensonderhoud afhangt van het beschikbaar zijn van de agent — wanneer een storing betekent dat klantwerk niet wordt opgeleverd.

En als je kostenbewust bent, betekent het draaien van twee CLI's dat je abonnementen of API-toegang hebt bij twee providers. Ik draai beide via Pro-abonnementen, wat meer kost per maand dan er één draaien. De moeite waard voor mij omdat de veerkrachtswaarde hoog is. Waarschijnlijk niet de moeite waard voor iemand met licht gebruik.

## De Echte Winst: Veerkracht en Fris Perspectief

De setup is de moeite waard om twee redenen die gemakkelijk te onderschatten zijn totdat je zonder ze hebt geleefd.

Veerkracht eerst. In de zes weken sinds ik beide CLI's draai, heb ik twee aparte Anthropic-incidenten en één langdurige Claude Code CLI-update-bug meegemaakt. In alle drie de gevallen verloor ik ongeveer nul werktijd, omdat ik binnen vijf minuten naar Codex wisselde en bleef werken. Vergeleken met de pre-setup-dagen, toen één slechte middag me een volledig klantoplevering kon kosten, betaalde de parallelle CLI-investering zich terug bij het eerste incident.

Fris perspectief ten tweede. Zelfs op dagen dat geen van beide agents kapot is, is het wisselen van CLI midden in een taak het goedkoopste creativiteitsmiddel dat ik ooit heb gebruikt. Andere modellijn. Andere RLHF. Ander accent op trainingsdata. Dezelfde prompt, verzonden naar Claude Code en naar Codex, zal soms oplossingen produceren die qua aanpak enorm verschillen. Ik ben bewust beide gaan draaien op hetzelfde moeilijke probleem en de beste ideeën samen te voegen. Het is alsof je twee senior engineers op dezelfde taak hebt, behalve dat een van hen bijna niets extra kost en nooit moe wordt.

De tool-agnostische mentaliteit is de echte verschuiving. De CLI is uitwisselbaar. De projectkennis is wat ertoe doet. Behandel `AGENTS.md` (of wat je gedeeld instructiebestand ook is) als het belangrijkste bestand in je repo. Behandel skills als draagbare assets, niet als tool-specifieke scripts. Behandel sub-agents als het ding dat elke CLI op zijn eigen manier doet, en probeer ze niet identiek te forceren over leveranciers.

Als Anthropic morgen een concurrent voor Codex zou uitbrengen, zou mijn workflow het in een middag absorberen. Als OpenAI iets zou uitbrengen dat Claude Code overbodig maakt, hetzelfde. De agents komen en gaan. De projectkennis blijft.

Dat is de winst.

## Veelgestelde Vragen

### Kunnen Claude Code en Codex tegelijkertijd dezelfde bestanden bewerken?
Ja, beide CLI's kunnen tegelijkertijd bestanden bewerken in hetzelfde project, maar ze coördineren niet op in-memory-niveau — ze coördineren via het bestandssysteem. Als beide agents hetzelfde bestand binnen dezelfde minuut aanraken, krijg je een verouderd-leesprobleem. Praktische regel: draai ze parallel op verschillende bestanden, of draag expliciet over met de sessie-overdrachts-skill hierboven.

### Moet ik apart betalen voor zowel Claude Code als Codex?
Ja. Claude Code is Anthropic's CLI en gebruikt Anthropic-facturering (Pro-abonnement of API). Codex is OpenAI's CLI en gebruikt OpenAI-facturering (ChatGPT Plus/Pro of API). Er is geen gedeeld abonnement. De kosten van beide draaien zijn ruwweg 2x de kosten van er één draaien, maar de veerkracht en het verse perspectief maken het de moeite waard voor werkende professionals.

### Wat is het daadwerkelijke verschil tussen CLAUDE.md en AGENTS.md?
Functioneel niets — beide zijn platte markdown-bestanden die de agent bij het opstarten leest om projectconventies te leren. Het verschil is welke CLI standaard welke leest. AGENTS.md wordt de cross-vendor standaard, ondersteund door Codex en anderen, terwijl CLAUDE.md Claude Code's eigen bestandsnaam is. De schoonste setup is om AGENTS.md als het echte bestand te houden en CLAUDE.md ernaar te symlinken.

### Werken mijn Claude Code-skills in Codex zonder wijzigingen?
De meeste wel, ja. Beide ecosystemen gebruiken hetzelfde SKILL.md-formaat (YAML-frontmatter met name/description, markdown-body). De skills die bewerking nodig hebben zijn degenen die verwijzen naar Claude-Code-specifieke toolnamen zoals Glob of specifieke MCP-servers die niet in je Codex-setup zijn geïnstalleerd. Ruwweg 80% draagt over met nul wijzigingen in mijn ervaring; de andere 20% heeft 5-10 regels bewerkingen nodig.

### Heeft Codex sub-agents zoals Claude Code?
Codex ondersteunt nu skills (de moderne vervanging voor custom prompts) en sub-agents via `.codex/agents/`, maar het dispatch-model is anders: Codex vereist dat je een sub-agent expliciet aanroept, terwijl Claude Code automatisch dispatcht op basis van de agentbeschrijving die overeenkomt met de taak. Als je leunt op auto-routing over veel sub-agents, is Claude Code nog steeds de sterkere orchestrator. Als je de voorkeur geeft aan deterministische controle over welke agent draait, is Codex's expliciet-aanroep-model schoner.

## Laten We Samenwerken

Op zoek naar het bouwen van AI-systemen, het automatiseren van workflows, of het opschalen van je tech-infrastructuur? Ik help graag.

* **Fiverr** (maatwerk builds & integraties): [fiverr.com/s/EgxYmWD](https://www.fiverr.com/s/EgxYmWD)
* **Portfolio**: [mejba.me](https://www.mejba.me)
* **Ramlit Limited** (enterprise-oplossingen): [ramlit.com](https://www.ramlit.com)
* **ColorPark** (design & branding): [colorpark.io](https://www.colorpark.io)
* **xCyberSecurity** (beveiligingsdiensten): [xcybersecurity.io](https://www.xcybersecurity.io)