Codex-functies: plan mode, goal mode, skills, MCP, subagents en cloud-taken

Waar het draait

Codex bestaat op vier plekken, en niet elke functie zit overal

De belangrijkste reden dat oudere uitleg niet meer klopt: op 9 juli 2026 is de losse Codex-app opgegaan in de ChatGPT desktop-app voor macOS en Windows. Codex houdt daar een eigen codeerervaring naast Chat en Work, met inline bewerken in diffs, pull request-review in het zijpaneel, snellere Computer Use aangedreven door GPT-5.6 en projecten met meerdere repositories. Daaromheen bestaan de CLI, de IDE-extensie en de cloud. Bij elke functie hieronder staat expliciet waar hij werkt, want dat verschilt per oppervlak.

Zo kies je waar een chat draait

Je downloadt de desktop-app via chatgpt.com/download en kiest na inloggen waar je werkt: een chat, een project of een map. Daarna kies je ChatGPT of Codex; binnen ChatGPT schakel je met de toggle boven de composer tussen Chat en Work, binnen Codex start je met New chat. Bestaande gebruikers van de oude Codex-app kunnen normaal updaten, Codex als standaardweergave instellen, het Codex-logo als app-icoon gebruiken en hun desktop-projecten benaderen vanuit de mobiele app.

Remote: je Mac bedienen vanaf je telefoon

Remote laat je vanaf de ChatGPT-app op iOS of Android werken met ChatGPT- of Codex-chats op een verbonden Mac of Windows-apparaat. Die host levert alles: de projecten, chats, bestanden, credentials, permissies, plugins, Computer Use, browseropzet en lokale tools. Voorwaarden: de host draait de nieuwste desktop-app, is wakker en online, en is ingelogd op hetzelfde account en dezelfde werkruimte. De koppeling start je in de mobiele app, niet vanuit de CLI of de IDE-extensie. Werk je via een ChatGPT-werkruimte, dan moet je beheerder Remote Control-toegang mogelijk eerst aanzetten.

De documentatie is verhuisd

Handig als je zelf naslaat: elke URL onder developers.openai.com/codex/ geeft een 308-redirect naar learn.chatgpt.com/docs/. Zo wordt developers.openai.com/codex/features.md automatisch learn.chatgpt.com/docs/features.md. Het volledige documentatie-indexbestand staat nog wel op developers.openai.com/llms.txt, met een Codex-sectie van ruim tachtig pagina's. Plak .md achter een pagina-URL en je krijgt de verbatim markdown, ideaal om aan een agent te voeren.

Plan mode

Plan mode: eerst context verzamelen, dan pas bouwen

Plan mode laat Codex context verzamelen, verhelderende vragen stellen en een sterker plan bouwen voordat de implementatie begint. De officiele best practices noemen het voor de meeste gebruikers de makkelijkste en meest effectieve optie. Je zet het aan en uit met /plan of met Shift+Tab.

Het gebruiksmoment: als het gewenste resultaat nog onduidelijk is

De documentatie beschrijft het scenario letterlijk: weet je zelf nog niet precies wat er moet gebeuren, begin dan met /plan. Vraag Codex je te interviewen, de beperkingen te benoemen en het resultaat om te zetten in een doel met meetbare succescriteria. Dat verfijnde doel start je daarna met /goal. In de praktijk is dat het verschil tussen een agent die vijf bestanden aanraakt die je niet had bedoeld, en een agent die eerst laat zien wat hij van plan is.

Direct een prompt meegeven

In de CLI zet /plan de actieve chat in plan mode en kun je inline prompttekst meegeven, bijvoorbeeld "/plan Propose a migration plan for this service". Content plakken of afbeeldingen bijvoegen werkt gewoon terwijl je inline argumenten gebruikt. Terwijl Codex al aan het werk is, is /plan tijdelijk niet beschikbaar; je wacht dus tot de beurt klaar is. In de IDE-extensie staat hetzelfde command in de lijst, omschreven als "Toggle plan mode for multi-step planning".

Twee alternatieven die de docs noemen

Naast plan mode noemt de documentatie twee andere aanpakken. De eerste is Codex vragen jou eerst te interviewen en je aannames uit te dagen. De tweede is voor geavanceerdere workflows: laat Codex een PLANS.md- of execution-plan-sjabloon volgen voor langer lopend, meerstaps werk. Dat tweede is nuttig als meerdere mensen hetzelfde plan moeten kunnen lezen en aanpassen.

Goal mode

Goal mode: een doel dat blijft staan tot het af is

Goal mode geeft Codex een blijvend doel om naartoe te werken tijdens langlopend werk. Je typt /goal in de desktop-app, de CLI of de IDE-extensie. Het bijzondere zit in de dubbele rol van je tekst: de doelomschrijving is zowel de eerste prompt als het voltooiingscriterium voor de taak.

De drie ingredienten van een doel dat werkt

De documentatie is hier concreet. Een goed doel bevat Outcome (het gewenste resultaat, niet alleen de activiteit), Constraints (vereiste tools, grenzen, compatibiliteitseisen of te vermijden benaderingen) en Verification (tests, metingen of reviewcriteria die bewijzen dat het werk af is). Het voorbeeld uit de docs: "Migrate this codebase from JavaScript to TypeScript. Preserve existing behavior, compile in strict mode without explicit any types, and make the full test suite pass." Merk op dat de verificatie daarin zit ingebakken, zodat Codex zelf kan vaststellen of het klaar is.

Het gebruiksmoment: werk dat langer duurt dan je aandacht

Een migratie, het wegwerken van deprecated calls of een testsuite die weer groen moet. In de desktop-app verschijnt bij een lopend doel een voortgangsrij boven de composer waarmee je pauzeert, hervat, het doel bewerkt of wist. Je kunt vervolgberichten sturen terwijl het doel loopt om context toe te voegen of beperkingen bij te stellen. Praktische regel uit de docs: pauzeer het doel voordat je verwacht je verbinding te verliezen, en hervat het wanneer je weer klaar bent.

Een doel geeft Codex geen extra rechten

Belangrijk misverstand om weg te nemen: een doel starten rekt de sandbox niet op. Het behoudt hetzelfde sandbox- en goedkeuringsbeleid en pauzeert wanneer er een beslissing nodig is. Met automatische goedkeuringsreviews kan een aparte reviewer in aanmerking komende verzoeken beoordelen, maar ook dat verandert alleen wie beoordeelt, niet wat mag. Wat de sandbox precies toestaat staat op Codex en privacy.

De grenzen van het veld

Doelomschrijvingen mogen niet leeg zijn en mogen maximaal 4.000 tekens bevatten. Heb je langere instructies, zet de details dan in een bestand en laat het doel daarnaar verwijzen. In ChatGPT op het web bestaat geen /goal-commando: voor gehost langlopend werk gebruik je daar ChatGPT Work en zet je uitkomst, beperkingen en reviewcriteria rechtstreeks in je prompt, waarna je in dezelfde chat doorgaat om context toe te voegen of om een statusupdate te vragen.

Skills

Skills: je werkwijze vastleggen in een mapje met SKILL.md

Een skill verpakt instructies, resources en optionele scripts zodat ChatGPT of Codex een workflow betrouwbaar volgt. Skills bouwen voort op de open agent skills-standaard van agentskills.io. Technisch is het simpel: een map met een verplicht SKILL.md-bestand dat minstens de velden name en description bevat, plus optionele mappen scripts/, references/, assets/ en agents/.

Het gebruiksmoment: elke taak waarbij het format consistent moet blijven

De docs noemen als voorbeelden een wekelijkse update, een campagnebrief, een meeting-follow-up, een release-procedure en een reviewroutine. Het technische voorbeeld dat ze uitwerken is een commit-skill die wijzigingen in semantische groepen stageert en commit in de volgorde feat, test, docs, refactor, chore. Het patroon is steeds hetzelfde: je legt vast wat je anders elke keer opnieuw uitlegt.

Progressive disclosure: waarom honderd skills je context niet opvreten

ChatGPT en Codex beginnen met alleen de naam en beschrijving van elke skill, en laden de volledige SKILL.md-instructies pas wanneer ze besluiten die skill te gebruiken. In Codex bevat die eerste lijst ook het bestandspad van elke skill. De lijst gebruikt maximaal 2 procent van het contextvenster van het model, of 8.000 tekens wanneer dat contextvenster onbekend is. Heb je heel veel skills geinstalleerd, dan verkort Codex eerst de beschrijvingen en kan het skills weglaten met een waarschuwing. Dat is meteen het argument om beschrijvingen kort te houden.

Expliciet aanroepen of vanzelf laten aanslaan

Expliciet: in ChatGPT typ je @ om een skill te kiezen, in de Codex CLI of de IDE-extensie draai je /skills of typ je $ gevolgd door de naam. Impliciet: ChatGPT of Codex kiest zelf een skill wanneer je taak overeenkomt met de description. Omdat die matching volledig op de description draait, hoort je scope daar duidelijk in te staan en zet je triggerwoorden vooraan. Een description als "Schrijft opvolgmails na een uitgebrachte offerte. Gebruik bij offertes opvolgen en herinneringsmails" slaat aan; "Helpt met sales" niet.

Waar Codex skills vandaan haalt

Codex laadt lokale skills uit vier scopes: REPO, USER, ADMIN en SYSTEM. De regels hieronder beschrijven hoe dat scannen werkt en hoe je skills maakt, installeert of uitzet; de tabel onderaan deze sectie zet de paden per scope op een rij.

Plugins

Plugins: skills, connectors, MCP en hooks in een pakket

Waar een skill een werkwijze is, is een plugin een pakket. Een plugin kan zes soorten onderdelen bevatten en installeer je in een keer, inclusief de koppelingen die eronder zitten. ChatGPT en Codex delen daarbij een universele plugin directory: dezelfde publieke plugins zijn vindbaar vanaf de ondersteunde oppervlakken van beide producten, en publiceer je er een, dan is diezelfde vermelding vanuit beide producten vindbaar.

Het gebruiksmoment, met de plugins die de docs zelf noemen

De Codex Security-plugin scant geautoriseerde code en bevestigt plausibele kwetsbaarheidsbevindingen. De Gmail-plugin werkt met Gmail, de Google Drive-plugin met Drive, Docs, Sheets en Slides, en de Slack-plugin vat kanalen samen of stelt antwoorden op. Zit je werk grotendeels in die systemen, dan is een plugin sneller opgezet dan een eigen MCP-server voor hetzelfde.

Installeren in vier stappen

Zoek of blader naar een plugin en open de details, klik de plus-knop om te installeren, verbind een connector als daarom gevraagd wordt (sommige plugins vragen tijdens de installatie om authenticatie, andere pas bij eerste gebruik), en start daarna een nieuwe chat. Dat laatste is de valkuil: gebundelde skills komen pas beschikbaar nadat je een nieuwe chat of CLI-sessie start. Aanroepen doe je door de taak gewoon te beschrijven en ChatGPT zelf de juiste tools te laten kiezen, of door @ te typen om expliciet een plugin of een van de gebundelde skills te kiezen.

De directory: tabbladen op web en desktop, een browser in de CLI

De Plugins Directory in de desktop-app en op het web ordent plugins in tabbladen: OpenAI (door OpenAI gebouwde plugins), de naam van je werkruimte (wat je werkruimte levert) en Personal (persoonlijke marketplace-plugins, met secties Created by me en Shared with me wanneer die er zijn). Een aparte rij Installed toont wat je al hebt. In de CLI open je met /plugins een browser die per marketplace groepeert: je wisselt met de marketplace-tabbladen tussen bronnen, opent een plugin voor details, installeert of deinstalleert, en drukt op de spatiebalk bij een geinstalleerde plugin om die aan of uit te zetten.

Zelf bouwen en binnen je team delen

Het snelst gaat dat met de ingebouwde skill @plugin-creator in ChatGPT Work of $plugin-creator in Codex. Die maakt het vereiste manifest .codex-plugin/plugin.json, ordent de pluginmap en kan de plugin aan een lokale marketplace toevoegen. Een minimale skills-only plugin bestaat uit .codex-plugin/plugin.json plus minstens een skill onder skills/<naam>/SKILL.md; het manifest bevat de velden name, version, description en skills. Delen doe je via een marketplace-bron, bijvoorbeeld een repo-marketplace voor een project of team. Vanaf de terminal beheer je dat met codex plugin marketplace (bronnen uit Git of lokaal toevoegen, opsommen, upgraden of verwijderen) en codex plugin (installeren, opsommen, verwijderen). De desktop-app kent bovendien deeplinks, zoals codex://plugins/install/<plugin-name>?marketplace=<marketplace-name>.

Wat een plugin met je rechten doet

Draait een plugin-capaciteit via een Codex-host, dan geldt het sandbox- en goedkeuringsbeleid van die host. Verbindingen met externe diensten gebruiken de eigen authenticatie en toegangscontroles van die dienst, en stuurt ChatGPT data via een gebundelde connector, dan gelden de voorwaarden en het privacybeleid van die dienst. Verwijderen doe je met Uninstall plugin; bij door de werkruimte geinstalleerde of standaardplugins ontbreekt die knop mogelijk omdat je beheerder ze bestuurt. Let op de nasleep: na deinstallatie blijven gebundelde connectors verbonden totdat je ze in ChatGPT zelf beheert.

Met een API-sleutel in plaats van een ChatGPT-account

Log je op Codex in met een OpenAI API-sleutel, dan kun je ondersteunde, door OpenAI gecureerde plugins bekijken, installeren en beheren in de Codex CLI en in Codex in de desktop-app. Sommige plugins zijn dan niet beschikbaar, omdat hun verbindingsflows OAuth-mogelijkheden vereisen die met API-sleutel-authenticatie niet ondersteund worden.

MCP

MCP: je eigen systemen als tools, een keer instellen voor drie clients

Model Context Protocol verbindt modellen met tools en context. ChatGPT op het web kan externe MCP-tools gebruiken die plugins leveren. De lokale Codex-clients kunnen daarnaast rechtstreeks verbinden met MCP-servers, en dat is de winst: de desktop-app, de CLI en de IDE-extensie delen de MCP-configuratie voor dezelfde Codex-host, dus je stelt een server een keer in en wisselt daarna van client zonder opnieuw te configureren.

Het gebruiksmoment: als de agent iets moet weten dat niet in je repo staat

Een agent die je changelog schrijft heeft je issues nodig, een agent die een bug fixt heeft je logs nodig, en een agent die tegen een externe API bouwt heeft actuele documentatie nodig. Dat is waar MCP zit. De praktische volgorde: bestaat er een plugin voor het systeem, gebruik die; is er geen plugin, dan is een MCP-server de route.

Twee transporten en hoe je ze aanmeldt

STDIO-servers draaien als lokaal proces dat door een commando wordt gestart, met ondersteuning voor omgevingsvariabelen. Streamable HTTP-servers benader je op een adres, met bearer token-authenticatie, OAuth-authenticatie of ChatGPT-sessieauthenticatie voor vertrouwde first-party servers. Codex leest daarnaast het MCP-veld instructions dat bij initialisatie wordt teruggegeven en gebruikt dat als serverbrede sturing naast de tools van die server. Dat laatste verklaart waarom twee servers met vergelijkbare tools zich toch anders kunnen gedragen.

Waar de configuratie staat

In config.toml, standaard ~/.codex/config.toml, en per project te scopen met .codex/config.toml (alleen in vertrouwde projecten). Elke server krijgt een tabel [mcp_servers.<server-name>]. STDIO-opties zijn command (verplicht), args, env, env_vars, cwd en experimental_environment. Streamable HTTP-opties zijn url (verplicht), auth, bearer_token_env_var, http_headers en env_http_headers.

De opties die je in de praktijk zet

Timeouts: startup_timeout_sec staat standaard op 10 seconden en tool_timeout_sec op 60 seconden. Beschikbaarheid: enabled zet een server uit zonder hem te verwijderen, required laat het opstarten falen als de server niet initialiseert. Toolselectie: enabled_tools werkt als toegestane-lijst en disabled_tools als weigerlijst die daarna wordt toegepast. Goedkeuring: default_tools_approval_mode kent de waarden auto, prompt, writes en approve, waarbij writes vraagt bij tools die niet als read-only zijn gemarkeerd, en met tools.<tool>.approval_mode zet je dat per tool anders. Die writes-stand is voor de meeste teams de verstandige middenweg.

Toevoegen vanaf de terminal of in de interface

In de CLI: codex mcp add <server-name> --env VAR=VALUE -- <stdio server-command>, bijvoorbeeld "codex mcp add context7 -- npx -y @upstash/context7-mcp". Verder bestaan codex mcp list voor je geconfigureerde servers, codex mcp --help voor alle commando's en codex mcp login <server-name> voor OAuth. In de chat toont /mcp de actieve servers en voegt "/mcp verbose" gedetailleerde diagnostiek toe. In de desktop-app loopt het via Settings > MCP servers > Add server (naam, STDIO of Streamable HTTP, commando of URL, opslaan, Restart) en in de IDE-extensie via het tandwielmenu > MCP servers > Add server met Restart extension. De serverlijst toont welke servers aanstaan en welke OAuth vereisen, met een knop Authenticate.

Twee dingen die vaak over het hoofd worden gezien

Plugins kunnen MCP-servers bundelen in hun manifest. Die servers worden vanuit de plugin gestart, dus jouw configuratie bepaalt hun transportcommando niet; wel regel je aan/uit-status en toolbeleid onder plugins.<plugin>.mcp_servers.<server>. En andersom: Codex kan zelf als MCP-server draaien met codex mcp-server over stdio, wat je gebruikt wanneer een andere agent Codex moet aanroepen.

Computer Use

Computer Use: als er geen API, plugin of MCP-server bestaat

Met Computer Use kan ChatGPT grafische gebruikersinterfaces op macOS of Windows zien en bedienen. De documentatie positioneert het scherp: het is bedoeld voor taken waar commandoregeltools of gestructureerde integraties tekortschieten. Een desktop-app controleren, een browser gebruiken, app-instellingen wijzigen, werken met een gegevensbron die niet als plugin beschikbaar is, of een bug reproduceren die alleen in een grafische interface optreedt.

Het gebruiksmoment, met de voorbeeldprompts uit de docs

"Open the app with Computer Use, reproduce the onboarding bug, and fix the smallest code path that causes it. After each change, run the same UI flow again." En korter: "Open @Chrome and verify the checkout page still works after the latest changes." Je start een taak door @Computer of @AppName in je prompt te noemen, of door ChatGPT gewoon te vragen Computer Use te gebruiken.

Installeren en de twee lagen toestemming

Je installeert de Computer Use-plugin via Plugins > Computer Use en zet de Computer Use-server- en skill-schakelaars aan. Op macOS verleen je daarna twee systeemrechten: Screen Recording zodat ChatGPT de doel-app kan zien en Accessibility zodat het kan klikken, typen en navigeren. Die systeemrechten staan los van de tweede laag: app-goedkeuringen binnen ChatGPT. Tijdens een taak vraagt ChatGPT toestemming voordat het een app mag gebruiken, en met Always allow hoeft het dat later niet meer te vragen. Apps verwijder je uit die lijst via Settings > Computer Use. Bestandslezingen, bestandsbewerkingen en shellcommando's blijven het sandbox- en goedkeuringsbeleid van de taak volgen.

Op Windows neemt het je bureaublad over

Reken erop dat ChatGPT de muisaanwijzer verplaatst, typt en de voorgrond overneemt: Computer Use draait op het actieve bureaublad en kan niet op de achtergrond werken terwijl jij dezelfde Windows-sessie gebruikt. Moet Windows-werk doorlopen terwijl je wegloopt, dan noemt de documentatie drie routes: het apparaat zonder vergrendeling en online houden, remote control gebruiken vanaf je telefoon, of de desktop-app in een virtuele machine draaien zodat Computer Use de VM overneemt in plaats van je hoofdbureaublad. Blijvende app-beslissingen slaat Windows op in $CODEX_HOME/config.toml onder [computer_use.windows] met always_allowed_app_ids, bijvoorbeeld ['mspaint.exe'].

Locked use: alleen op macOS, en met waarborgen

Locked use laat ChatGPT Computer Use gebruiken nadat je Mac is vergrendeld, maar pas nadat je het inschakelt via Settings > Computer Use. ChatGPT installeert daarvoor een Apple authorization plug-in die meedoet op het moment dat macOS de vergrendeling opheft. De waarborgen die de documentatie noemt: het autorisatievenster is kortstondig en beperkt tot de lopende poging, het automatisch opheffen van de vergrendeling is alleen beschikbaar voor ChatGPT tijdens actieve Computer Use-beurten, ChatGPT dekt elk beeldscherm af terwijl het bureaublad tijdelijk open staat, en bij gedetecteerde lokale toetsenbord- of muisinvoer vergrendelt ChatGPT de Mac opnieuw.

Wat het niet doet, en waarom dat verstandig is

Computer Use kan geen terminalapplicaties en ChatGPT zelf niet automatiseren, omdat dat het beveiligingsbeleid zou kunnen omzeilen. Het kan zich niet als beheerder authenticeren en geen beveiligings- of privacy-toestemmingsprompts op je computer goedkeuren. En de belangrijkste voor zakelijk gebruik: gebruikt ChatGPT je browser, dan kan het interacteren met pagina's waar je al bent ingelogd, en sites kunnen goedgekeurde klikken, formulierverzendingen en ingelogde acties behandelen alsof ze van jouw account komen. Beheerders kunnen de functie uitzetten via requirements.toml met [features].computer_use = false.

Eerst de goedkopere route proberen

Voor webapps die je lokaal bouwt raadt de documentatie aan eerst de ingebouwde browser te gebruiken. Heeft de doel-app een eigen plugin of MCP-server, dan verdient die gestructureerde integratie de voorkeur voor datatoegang en herhaalbare handelingen. Kies Computer Use pas wanneer ChatGPT de app echt visueel moet inspecteren of bedienen.

Beschikbaarheid in Nederland, met een open punt

In de week van 15 tot 19 juni 2026 begonnen Computer Use, de Chrome-extensie, Memories en Chronicle uit te rollen naar de EER, het Verenigd Koninkrijk en Zwitserland. Memories blijft in die regio's standaard uitgeschakeld en Chronicle is er een opt-in research preview voor ChatGPT Pro op macOS. Op de functiematrix dragen Computer Use en Record & Replay wel de voetnoot "region", met de toelichting dat de functie tot bepaalde regio's beperkt is. Het open punt: de featurepagina van Record & Replay meldt nog steeds dat de initiele beschikbaarheid de EER, het VK en Zwitserland uitsluit, en wij vonden geen bron die een latere uitrol bevestigt of ontkent. Reken er dus niet op voordat je het zelf ziet.

Review

Review: een tweede agent leest je diff voordat jij commit

Codex-codereview inspecteert codewijzigingen voordat je commit of pusht. Je start hem met /review, waarna Codex een aparte reviewer start die de geselecteerde diff leest en geprioriteerde, actiegerichte bevindingen rapporteert zonder je working tree te wijzigen. Kleine maar praktische detail: het commando verschijnt alleen wanneer het geopende project in een Git-repository zit.

Het reviewpaneel toont je repo, niet alleen wat Codex deed

Dat is de aanname die het vaakst misgaat. Het paneel in de desktop-app weerspiegelt de staat van je Git-repository: wijzigingen van Codex, je eigen wijzigingen en andere niet-gecommitte wijzigingen staan er door elkaar. Standaard toont het Unstaged; verder kies je Staged voor de Git-index, Commit voor een geselecteerde commit, Branch voor de diff tegen je base branch en Last turn voor alleen de laatste assistentbeurt. Die laatste is wat de meeste mensen eigenlijk bedoelen als ze "laat zien wat je hebt gedaan" vragen.

Inline comments zijn de snelste stuurknop

Feedback aan specifieke regels in de diff hangen is vaak de kortste weg naar de juiste fix. Je opent het reviewpaneel, zweeft over de regel, klikt de plus-knop, schrijft je feedback en verstuurt die. Daarna stuur je een bericht terug naar de chat met expliciete intentie, bijvoorbeeld "Address the inline comments and keep the scope minimal." Zonder die laatste zin gaat een agent al snel meer aanpassen dan je bedoelde.

Accepteren of terugdraaien per hunk

Het reviewpaneel bevat Git-acties op drie niveaus: de hele diff (knoppen als Stage all of Revert all), per bestand (stagen, unstagen of terugdraaien) en per hunk (een enkele hunk stagen, unstagen of terugdraaien). Staging gebruik je wanneer je een deel van het werk accepteert, revert wanneer je het wilt weggooien. Zo hoef je een beurt die voor tachtig procent goed is niet in zijn geheel af te wijzen.

Het gebruiksmoment in GitHub: @codex review

Voor pull request-reviews zet je Codex cloud op voor de repository en schakel je Code review aan via chatgpt.com/codex/settings/code-review. Daarna vraag je een review aan door in een pull request-comment @codex review te noemen. Codex reageert met een oogjes-emoji en plaatst een standaard GitHub-codereview. Belangrijke nuance: in GitHub markeert Codex alleen P0- en P1-problemen, zodat het commentaar gericht blijft op risico's met hoge prioriteit. Wil je een breder oordeel, draai dan lokaal /review met eigen criteria.

Losse reviewchat, ander model en PR-context

Reviews draaien standaard in de huidige chat. In de desktop-app kies je onder Settings > General > Code review voor Detached om een aparte reviewchat te starten; in de IDE-extensie zet je daarvoor chatgpt.reviewDelivery op detached. In de CLI stel je review_model in config.toml in wanneer reviews een ander model dan je sessie moeten gebruiken, bijvoorbeeld een zwaarder model voor het beoordelen dan voor het schrijven. Wil je pull request-context en reviewerfeedback in de zijbalk zien, installeer dan de GitHub CLI en log in met "gh auth login"; ontbreekt gh of is die niet geauthenticeerd, dan verschijnen PR-details mogelijk niet.

Subagents

Subagents: ruizig werk uit je hoofdgesprek houden

ChatGPT Work en Codex kunnen gespecialiseerde agents parallel starten en hun resultaten in een antwoord verzamelen. De documentatie motiveert dat met twee begrippen: context pollution (nuttige informatie raakt bedolven onder ruizige tussenoutput) en context rot (prestaties verslechteren naarmate de chat volloopt met minder relevante details). Subagents verplaatsen dat ruizige werk: de hoofdagent blijft bij eisen, beslissingen en einduitvoer, de subagents doen verkenning, tests of loganalyse en geven samenvattingen terug in plaats van ruwe output.

Het gebruiksmoment, letterlijk uit de docs

"Review this branch with parallel subagents. Spawn one subagent for security risks, one for test gaps, and one for maintainability. Wait for all three, then summarize the findings by category with file references." Een goede subagent-prompt legt drie dingen vast: hoe het werk verdeeld moet worden, of Codex op alle agents moet wachten, en welke samenvatting of output er terug moet komen.

Lees-intensief eerst, schrijven met beleid

Als startpunt raadt de documentatie parallelle agents aan voor lees-intensieve taken: verkenning, tests, triage en samenvatting. Wees voorzichtiger met parallelle schrijf-intensieve workflows, omdat agents die tegelijk code bewerken conflicten veroorzaken en de coordinatielast verhogen. En reken op de rekening: omdat elke subagent eigen model- en toolwerk doet, verbruiken subagent-workflows meer tokens dan vergelijkbare single-agent runs.

Drie ingebouwde agents, en je eigen in TOML

Codex levert default als algemene fallback, worker als uitvoeringsgerichte agent voor implementatie en fixes, en explorer als lees-intensieve codebase-verkenner. Eigen agents definieer je als losstaande TOML-bestanden onder ~/.codex/agents/ (persoonlijk) of .codex/agents/ (projectgebonden). Elk bestand definieert een agent en bevat minimaal name, description en developer_instructions. Geef je je eigen agent de naam van een ingebouwde, zoals explorer, dan heeft die van jou voorrang. Naast die drie velden mag een agentbestand config.toml-sleutels bevatten zoals model, model_reasoning_effort, sandbox_mode, mcp_servers en skills.config.

Een uitgewerkt patroon voor review

De documentatie splitst review over drie eigen agents: pr_explorer die de codebase in kaart brengt en bewijs verzamelt (read-only), reviewer die let op correctheid, beveiliging en testrisico's (read-only, hoge reasoning effort), en docs_researcher die framework- of API-documentatie controleert via een eigen MCP-server. Dat is een goed sjabloon om te kopieren: twee lezers en een specialist, geen van drieen met schrijfrechten.

Instellingen onder [agents]

agents.enabled (standaard true) zet de multi-agent-tools aan of uit. agents.max_concurrent_threads_per_session begrenst het aantal gelijktijdig open gespawnde agent-threads, exclusief de primaire (agents.max_threads is de verouderde alias). Verder bestaan agents.default_subagent_model, agents.default_subagent_reasoning_effort en agents.interrupt_message (standaard true), dat een model-zichtbaar bericht vastlegt wanneer een agent-beurt wordt onderbroken. Wat de standaardwaarde van max_concurrent_threads_per_session is, staat niet in de documentatie: de voorbeelden gebruiken 6 en 8, maar dat zijn expliciet gezette waarden.

Rechten erven ze van jou

Subagents erven je huidige sandbox-beleid. In de desktop-app en de IDE-extensie erven ze de permissiemodus die onder de composer geselecteerd staat, dus die kies je bewust voor de ouderbeurt. In de CLI kunnen goedkeuringsverzoeken opduiken vanuit inactieve agent-threads terwijl jij naar de hoofdthread kijkt; de overlay toont het bronthread-label en met "o" open je die thread voordat je goedkeurt, afwijst of antwoordt. Codex herhaalt bovendien de live runtime-overrides van de ouderbeurt bij het spawnen van een kind, inclusief /permissions-wijzigingen, zelfs als het gekozen agentbestand andere standaarden zet.

Beheer verschilt per oppervlak

In de CLI wissel je met /agent tussen actieve agent-threads en inspecteer je de lopende thread. In de desktop-app open je een subagent-thread vanuit de activiteit in de hoofdthread. In de IDE-extensie klap je het background-agent-paneel uit om status te bekijken, actieve subagents te stoppen of een thread te openen. In ChatGPT op het web open je Subagents voor alleen-lezen lijsten Active en Done, zonder besturing om een individuele subagent te stoppen of te sturen.

Welk model onder welke agent, met een kanttekening

Voor subagents adviseert de documentatie gpt-5.6 als startpunt, gpt-5.6-terra voor agents die snelheid en efficientie boven diepgang stellen zoals verkenning en lees-intensieve scans, en gpt-5.6-luna voor snelle, nauw afgebakende agents met herhaalbaar of hoogvolume werk. Reasoning effort loopt van low (rechttoe rechtaan taken) via medium (gebalanceerde standaard) en high (agents die complexe logica moeten volgen, zoals reviewers) naar max, xhigh en ultra. De kanttekening: twee codevoorbeelden op diezelfde pagina gebruiken model = "gpt-5.3-codex-spark", terwijl de prijzenpagina dat model als research preview bij Pro noemt. De voorbeelden lijken achter te lopen op het advies in de tekst, maar er is geen bron die dat expliciet oplost. Meer over de modelkeuze staat op modellen en abonnementen.

Hooks

Hooks: je eigen scripts in de lus van de agent

Hooks zijn het uitbreidingsframework waarmee je eigen scripts in de agentische lus injecteert. De documentatie noemt vijf toepassingen: de chat naar je eigen logging- of analytics-engine sturen, teamprompts scannen om per ongeluk geplakte API-sleutels te blokkeren, chats samenvatten om automatisch blijvende memories te maken, een eigen validatiecontrole draaien wanneer een chatbeurt stopt om standaarden af te dwingen, en prompting aanpassen in een bepaalde map.

Het gebruiksmoment: afdwingen wat een model vergeet

De sterkste toepassing voor Nederlandse teams is de tweede uit die lijst: prompts scannen op geplakte sleutels of persoonsgegevens voordat ze weggaan. Een model dat je vraagt "plak nooit klantdata" doet dat meestal goed, een hook doet het altijd. Dezelfde logica geldt voor een validatiecontrole op Stop: geen beurt is klaar voordat jouw script zegt dat hij klaar is.

Waar Codex hooks zoekt

Naast de actieve configuratielagen, in twee vormen: een hooks.json-bestand of inline [hooks]-tabellen in config.toml. De vier bruikbare locaties zijn ~/.codex/hooks.json, ~/.codex/config.toml, <repo>/.codex/hooks.json en <repo>/.codex/config.toml. Bestaan er meerdere bronnen, dan laadt Codex alle matchende hooks: hogere configuratielagen vervangen lagere niet. Staat in een laag zowel hooks.json als inline [hooks], dan voegt Codex ze samen en waarschuwt bij het opstarten.

Niets draait voordat jij het vertrouwt

Voordat een niet-beheerde command-hook mag draaien, vereist Codex dat je de exacte hookdefinitie beoordeelt en vertrouwt. Dat vertrouwen registreert Codex tegen de huidige hash van de hook, dus nieuwe of gewijzigde hooks worden gemarkeerd voor review en overgeslagen tot ze opnieuw vertrouwd zijn. In de CLI gebruik je /hooks om bronnen te inspecteren, wijzigingen te beoordelen, hooks te vertrouwen of individuele niet-beheerde hooks uit te schakelen. Beheerde hooks uit system-, MDM-, cloud- of requirements.toml-bronnen zijn per beleid vertrouwd en kun je niet vanuit de gebruikersbrowser uitschakelen. Voor eenmalige automatisering waarbij de bronnen buiten Codex al gecontroleerd zijn, bestaat de vlag --dangerously-bypass-hook-trust; die naam is een waarschuwing, geen suggestie.

Drie niveaus: event, matcher-groep, handler

Een hook-event zoals PreToolUse of Stop bevat een of meer matcher-groepen die bepalen wanneer het event matcht, en elke matcher-groep bevat een of meer handlers die dan draaien. Een handler van type command kent velden als command, statusMessage, additionalContextLimit en timeout. Matchers werken per event op verschillende waarden: PreToolUse, PostToolUse en PermissionRequest matchen op toolnaam, PreCompact en PostCompact op de compaction-trigger (manual of auto), SessionStart op de start source (startup of resume), SubagentStart en SubagentStop op subagent-type, en UserPromptSubmit en Stop ondersteunen geen matcher.

Wat er tijdens het draaien gebeurt

Matchende hooks uit meerdere bestanden draaien allemaal, en meerdere matchende command-hooks voor hetzelfde event worden gelijktijdig gestart zodat de ene hook de andere niet kan blokkeren. Projectlokale hooks laden alleen wanneer de .codex/-laag van dat project vertrouwd is; in niet-vertrouwde projecten laadt Codex nog wel je gebruikers- en systeemhooks. Geinstalleerde plugins kunnen ook lifecycle-configuratie bundelen, via hun manifest of een hooks/hooks.json-bestand; die hooks laden naast de andere bronnen en doorlopen dezelfde trust-review.

AGENTS.md

AGENTS.md: de huisregels die Codex bij elke run inleest

Codex leest AGENTS.md-bestanden voordat het aan werk begint en bouwt bij het starten een instructieketen op, eenmaal per run en in de terminal meestal eenmaal per gestarte sessie. Er is geen cache: Codex herbouwt die keten elke keer. De documentatie omschrijft het bestand als een open-format README voor agents die automatisch in context laadt. Hieronder eerst wat erin hoort en wanneer je hem bijwerkt, daarna de precieze leesvolgorde in vijf stappen.

Wat erin hoort

De best practices noemen zes onderwerpen: de repo-indeling en belangrijke mappen, hoe je het project draait, de build-, test- en lintcommando's, engineeringconventies en PR-verwachtingen, en beperkingen of do-not-regels. Houd hem klein en gebruik hem voor de regels die Codex elke keer in deze repo moet volgen, niet voor uitleg die ook in je README past.

Het gebruiksmoment: wanneer je hem bijwerkt

Bij een herhaalde fout voeg je een regel toe. Vindt de agent de juiste bestanden maar leest hij te veel documenten, dan voeg je routing-sturing toe over welke mappen of bestanden voorrang krijgen. Terugkerende PR-feedback codificeer je. In GitHub kun je in een pull request-comment @codex add this to AGENTS.md taggen om de update aan een cloudchat te delegeren. En met geplande taken laat je terugkerende controles draaien die gaten in de sturing opsporen.

Reviewregels horen in de dichtstbijzijnde AGENTS.md

Voor Codex-codereview in GitHub voeg je een sectie ## Code Review Rules toe aan de AGENTS.md die het dichtst bij de betreffende code staat: repository-brede controles in de root, servicespecifieke controles in een geneste file. Houd die regels beknopt, leg uit welk gedrag gemarkeerd moet worden plus een veilig pad of uitzondering, en laat opmaak- en lintcontroles over aan je CI.

Controleren wat er daadwerkelijk geladen is

Een scaffold genereer je met /init. Wil je zien welke instructiebestanden actief zijn, draai dan bijvoorbeeld codex --ask-for-approval never "Summarize the current instructions." of codex --cd subdir --ask-for-approval never "Show which instruction files are active." Dat is de snelste manier om te ontdekken dat een geneste AGENTS.md je root-regels overschrijft.

Worktrees

Worktrees: meerdere klussen tegelijk in dezelfde repo

Worktrees laten Codex meerdere onafhankelijke chats in hetzelfde project draaien zonder dat ze elkaar storen. Ze werken alleen in projecten die deel uitmaken van een Git-repository, omdat ze onderliggend Git worktrees gebruiken. De documentatie hanteert drie termen: Local checkout (de repository die je zelf maakte, in de app kortweg Local), Worktree (een Git worktree die vanuit die local checkout in de app is aangemaakt) en Handoff (de flow die een chat tussen Local en Worktree verplaatst). Hoe je er een start, staat onderaan deze sectie in vier stappen.

Het gebruiksmoment: de agent bouwt terwijl jij doorwerkt

Je kunt Local zien als de voorgrond en Worktree als de achtergrond. Wil je een refactor laten draaien terwijl jij zelf in dezelfde repo een bugfix maakt, dan voorkomt een worktree dat jullie elkaars bestanden overschrijven. Het advies voor parallelle chats is simpel: elke chat houdt eigen context, berichten, resultaten en doel; draai ze gerust gelijktijdig, maar voorkom dat twee chats dezelfde bestanden wijzigen.

Waar ze staan, en wat Git ervan vindt

Codex maakt worktrees aan in $CODEX_HOME/worktrees; via Settings > Worktrees > Worktree root kies je een andere locatie. De worktree wordt niet als branch uitgechecked maar staat in detached HEAD-staat, zodat Codex er meerdere kan maken zonder je branches te vervuilen. Maak je met "Create branch here" toch een branch op een worktree en probeer je die ook lokaal uit te checken, dan volgt de foutmelding "fatal: 'feature/a' is already used by worktree at '<WORKTREE_PATH>'". Git staat nu eenmaal maar een checkout per branch toe. Gebruik in dat geval Handoff om de chat naar Local te verplaatsen in plaats van dezelfde branch op twee plekken te houden.

Genegeerde bestanden verhuizen niet vanzelf mee

Omdat Handoff Git-bewerkingen gebruikt, gaan bestanden die in .gitignore staan niet mee, tenzij Codex ze via .worktreeinclude kopieert naar een lokale beheerde worktree. In dat bestand in de repository-root zet je genegeerde paden of .gitignore-achtige patronen, bijvoorbeeld .env, .env.local en config/secrets.json. Codex kopieert alleen genegeerde bestanden die matchen, slaat bronsymlinks over en overschrijft geen bestaande bestanden. Een genegeerde AGENTS.override.md kopieert Codex automatisch, dus die hoef je niet te vermelden. Dit is de eerste plek om te kijken als een agent in een worktree opeens je omgevingsvariabelen mist.

Wegwerp of langlevend

Standaard gebruiken chats een door Codex beheerde worktree: lichtgewicht, wegwerpbaar en meestal aan een chat gewijd. Wil je een langlevende omgeving, maak dan via het driepuntsmenu op een project in de zijbalk een permanente worktree aan; die wordt een eigen project, wordt niet automatisch verwijderd en kan meerdere chats bedienen. Codex bewaart standaard je 15 meest recente beheerde worktrees; die limiet is aanpasbaar en automatisch verwijderen kun je uitzetten. Beheerde worktrees blijven staan zolang er een vastgezette chat aan hangt, de chat nog loopt, of het een permanente worktree is. Ze verdwijnen wanneer je de bijbehorende chat archiveert of wanneer Codex moet opruimen om binnen je limiet te blijven, en voor verwijdering slaat Codex een snapshot op zodat je bij het heropenen van de chat de optie krijgt hem te herstellen.

Cloud

Cloud-taken: parallel draaien zonder je laptop bezet te houden

Codex cloud draait codeertaken in geisoleerde cloudomgevingen, parallel, en je start werk vanaf het web, GitHub, Linear of Slack. De documentatie noemt drie voordelen: werk parallel draaien (langere taken krijgen een eigen omgeving en lopen door terwijl jij iets anders doet), de omgeving reproduceren (afhankelijkheden, tools, variabelen en setupstappen per repository configureren) en beoordelen voor je merget (samenvatting en diff inspecteren, een vervolgvraag stellen of een pull request openen). De opzet zelf staat onderaan deze sectie in vijf stappen.

Het gebruiksmoment: vier situaties uit de docs

Wanneer werk op de achtergrond moet draaien. Wanneer je meerdere pogingen wilt vergelijken zonder je lokale machine bezet te houden. Wanneer werk begint in GitHub, Linear of Slack. En wanneer je weg bent van je ontwikkelmachine en werk vanaf het web of de CLI wilt starten en beoordelen. Voor snelle iteratie op bestanden die je zelf open hebt, blijft lokaal sneller.

Local, Worktree of Cloud kiezen

In de desktop-app kies je bij het starten van een Codex-chat waar die draait: Local (rechtstreeks in je huidige projectmap), Worktree (wijzigingen isoleren in een Git-worktree) of Cloud (extern in een geconfigureerde cloudomgeving). Local en Worktree draaien beide op je eigen computer. In de IDE-extensie schakel je met /cloud en /local tussen cloud- en lokale uitvoering en kies je met /cloud-environment welke cloudomgeving je gebruikt. Alle commando's per oppervlak staan in het commando-overzicht.

Achtergrond

Werk dat doorloopt: geplande taken, achtergrondterminals en meldingen

Naast cloud-taken kent Codex drie manieren om werk door te laten lopen terwijl jij iets anders doet: geplande taken, achtergrondterminals in de CLI en de geintegreerde terminal in de desktop-app. Ze lossen verschillende problemen op.

Geplande taken: eenmalig, op schema, bij een gebeurtenis of monitorend

Onder Scheduled bekijk je actieve, gepauzeerde en voltooide taken plus recente runs. De documentatie noemt als voorbeelden een taak die telemetriefouten evalueert en fixes indient, en een taak die rapporten maakt over recente wijzigingen in de codebase. Moet doorlopend werk dezelfde context houden, plan de taak dan binnen een bestaande chat. In de desktop-app kunnen geplande taken met lokale projecten werken en draaien ze in de projectmap of in een geisoleerde worktree; in Git-repositories kies je zelf welke van die twee. Houd je computer aan en de app open wanneer een geplande taak lokale bestanden nodig heeft. De Codex CLI en de IDE-extensie hebben geen Scheduled-beheerinterface.

Achtergrondterminals in de CLI: /ps en /stop

/ps toont je achtergrondterminals met hun commando plus maximaal drie recente, niet-lege outputregels, zodat je in een oogopslag ziet of die dev-server nog draait of allang is gecrasht. /stop stopt alle achtergrondterminals van de huidige sessie, met /clean als alias. Achtergrondterminals verschijnen wanneer unified_exec in gebruik is; anders kan de lijst leeg blijven.

De geintegreerde terminal in de app

Elke chat in de desktop-app heeft een terminal die gescoped is op het huidige project of de huidige worktree. Je opent hem met het terminalicoon rechtsboven of met Ctrl+`. ChatGPT kan de huidige terminaloutput lezen, dus het kan een draaiende ontwikkelserver controleren of naar een mislukte build verwijzen terwijl het met je meewerkt. Cmd+K opent het app-commandopalet, Ctrl+L wist de terminal.

Wakker blijven en op tijd gemeld worden

Voor lokaal langlopend werk zet je in de desktop-app de instelling Prevent sleep while running aan, zodat je Mac wakker blijft. Om te zien wanneer een chat invoer nodig heeft of klaar is voor review gebruik je Pets of systeemmeldingen. In de notificatie-instellingen bepaal je of beurt-voltooiingsmeldingen nooit verschijnen, alleen wanneer ChatGPT op de achtergrond draait, of altijd; aparte schakelaars regelen meldingen voor toestemming en voor vragen. Zet die laatste twee aan, anders staat een agent stil te wachten zonder dat je het merkt.

Sites

Sites: publiceren vanuit de chat, met een kanttekening voor Nederland

Sites laat ChatGPT websites, webapps en games maken, hosten, verfijnen en delen, zonder aparte deployment-workflow. Het staat in public beta en de beschikbaarheid hangt af van je abonnement, regio en werkruimte-instellingen. Je start de workflow door het woord "website" in je prompt op te nemen of door @Sites te noemen.

Opslaan en deployen zijn twee verschillende stappen

Save a version: ChatGPT bouwt een deploybare versie en koppelt die bij een lokaal bronproject aan de gebruikte Git-commit. Dat levert een beoordeelbare deployment-kandidaat op. Deploy a version: ChatGPT publiceert een opgeslagen versie en meldt de productie-URL. Let op de consequentie: elke Sites-deployment-URL is een productie-deployment. Wil je een build eerst beoordelen, vraag ChatGPT dan expliciet een versie op te slaan zonder te deployen.

Opslag: D1 voor records, R2 voor bestanden

D1 is de relationele database voor duurzame gestructureerde data zoals opgeslagen records, gebruikersvoortgang en gamescores. R2 is objectopslag voor bestanden: afbeeldingen, documenten, audio, video en uploads. Heb je geuploade bestanden met doorzoekbare metadata, dan combineer je beide: D1 voor de metadata, R2 voor de bestandsinhoud. De koppeling tussen je lokale bronproject en de hosting legt Sites vast in .openai/hosting.json, met velden zoals project_id, d1 en r2.

Delen, inloggen en meten

Toegang tot een nieuwe Site is beperkt tot de eigenaar en werkruimtebeheerders totdat jij dat verandert. Deelopties kunnen zijn: eigenaar en werkruimtebeheerders, geselecteerde gebruikers of groepen, iedereen in de werkruimte, en iedereen op internet wanneer publiek publiceren is ingeschakeld. In Enterprise-werkruimtes staat publiek publiceren standaard uit en moet een beheerder het aanzetten. Delen geeft bezoekrecht, geen bewerkrecht. Publieke Sites kunnen daarnaast Sign in with ChatGPT aanbieden voor identiteitsbewuste functies, via de platformpaden /signin-with-chatgpt en /signout-with-chatgpt; na aanmelding komt de identiteit binnen in de request headers oai-authenticated-user-email en oai-authenticated-user-full-name. Die tweede is optioneel, dus val terug op het e-mailadres, en houd autorisatiebeslissingen in je servercode. Verkeer wordt automatisch geregistreerd, zodat je zonder analytics-SDK unieke bezoekers en paginaweergaven ziet, ook over tijd, met instelbaar datumbereik en granulariteit. Analytics is op dit moment beschikbaar voor Sites die niet in eigendom zijn van een Enterprise-werkruimte.

Eigen domein en gebruikslimieten

Waar aangepaste domeinen beschikbaar zijn, koppel je een apex-domein of subdomein dat je al bezit. Sites registreert zelf geen domeinen, dus je moet DNS-records kunnen wijzigen: je voegt het domein toe via de site-instellingen, zet de DNS-records van Sites bij je domeinprovider en vernieuwt daarna de domeinstatus. Bij lancering zijn aangepaste domeinen niet beschikbaar in Enterprise-werkruimtes. Tijdens de beta gelden abonnementsspecifieke gebruikslimieten over al je Sites; ChatGPT toont de huidige limieten en waarschuwt als je er een nadert. Een limiet raken kan verhinderen dat je een Site aanmaakt, opslag toevoegt of een Site met hoog gebruik publiek houdt, maar bewerken en beheren blijft mogelijk. Verwijderen doe je via Delete site en het intypen van de site-slug, en dat is niet terug te draaien.

Waar het schuurt met Nederlandse eisen

Twee dingen om vooraf te weten. Ten eerste het gebruiksverbod: geen Protected Health Information of betaalkaartgegevens verwerken, niet richten op kinderen onder 13 of de geldende leeftijd van digitale toestemming, geen financiele transacties mogelijk maken, geen malware verspreiden, geen phishing mogelijk maken en geen personen of organisaties nabootsen. Sommige frameworks, private netwerken, databases, achtergronddiensten en hostingpatronen worden niet ondersteund. Ten tweede, en zwaarder voor AVG-gevoelige toepassingen: Sites ondersteunt bij lancering geen data residency en geen inference residency. Dat geldt voor gedeployde Sites, Site-code, D1- en R2-data, bestandsopslag, gegenereerde artefacten en logs. Voor een intern prototype is dat prima, voor een klantomgeving met persoonsgegevens is het een blokkade. Meer over de zakelijke kant staat op privacy en zakelijk gebruik.

Volgorde

In welke volgorde zet je dit aan?

De documentatie beschrijft de aanpasbaarheid van Codex als vijf lagen die elkaar aanvullen: project guidance via AGENTS.md voor blijvende instructies, Memories voor nuttige context uit eerder werk, skills voor herbruikbare workflows en domeinexpertise, MCP voor toegang tot externe tools en gedeelde systemen, en subagents voor het delegeren van werk. De aanbevolen bouwvolgorde staat onderaan deze sectie in vijf stappen, en is even nuchter als effectief.

Naast Claude Code

Werk je met beide agents, dan herken je de bouwstenen: ook Claude Code kent skills op de open agent skills-standaard, MCP, subagents, hooks en worktrees. Het verschil zit vooral in waar ze wonen. Bij Codex hangen worktrees, Computer Use en Sites aan de ChatGPT desktop-app, terwijl de CLI de volledige commandoset heeft. De tegenhangers aan Anthropic-kant staan in de Claude Code-gids, zodat je per klus kunt kiezen in plaats van per merk.

De open punten die we bijhouden

Vier dingen staan niet in de documentatie en houden we in de gaten. Of plan mode een equivalent krijgt in ChatGPT op het web. Of hooks ook in Codex cloud of ChatGPT Work op het web draaien. Wat de standaardwaarde van agents.max_concurrent_threads_per_session is. En of Record & Replay inmiddels in de EER beschikbaar is. Zodra daar een officiele bron voor is, past deze pagina zich aan.