Ik heb de nieuwe Codex Plugins van OpenAI getest — dit is de waarheid

De Slack-notificatie van een bevriende ontwikkelaar bereikte me om 23:00 uur op een woensdag: "Codex heeft net plugins uitgebracht. Er zijn er meer dan 20. Je moet die Build iOS Apps eens bekijken."

Ik zat midden in een sessie met een Claude Code-project, drie agents diep in een parallelle workflow, en mijn eerste impuls was om het te negeren. Weer een feature-release. Weer een ecosysteem-zet. Ik zou er in het weekend wel naar kijken.

Toen opende ik de Codex-app, typte /plugins, en zag wat OpenAI werkelijk had gebouwd. Dit was geen marktplaats die aan de zijkant van een codingtool was vastgeschroefd. Het was een architectuur — skills, connectors voor apps van derden, en MCP servers gebundeld in installeerbare pakketten die fundamenteel veranderen wat Codex standaard kan. Ik sloot mijn Claude Code-sessie. Dit verdiende mijn volledige aandacht.

Ik heb de afgelopen twee dagen elke plugin geïnstalleerd die ik kon vinden, de Build iOS Apps plugin stresstests onderworpen tegen een echt project, en de manifest-bestanden ontleed om te begrijpen hoe het systeem onder de motorkap werkelijk functioneert. Wat ik vond is een pluginsysteem dat tegelijkertijd krachtiger en frustrerender is dan ik had verwacht.

Hier is alles — de architectuur die het interessant maakt, de praktijkervaring die de hiaten blootlegt, en of dit het concurrentielandschap voor AI-codingtools in 2026 verandert.

Waarom deze plugin-lancering nu belangrijk is

OpenAI lanceerde Codex plugins op 26 maart 2026, met meer dan 20 integraties beschikbaar via de Codex-app, CLI en VS Code-extensie. Die timing is geen toeval. De markt voor AI-codingtools is aan het versplinteren — Claude Code heeft zijn agent-teams en skills-systeem, Cursor heeft zijn composer-workflows, en elke grote IDE levert AI-functies. OpenAI had een manier nodig om Codex onmisbaar te maken.

Plugins zijn hun antwoord. En het is een slim antwoord, want het echte probleem met elke AI-codingassistent is niet de AI zelf — het is de integratiekloof. Je kunt het meest capabele model ter wereld hebben, maar als het niet kan communiceren met je projectmanagementtool, je designbestanden niet kan lezen of je buildsysteem niet kan triggeren, zit je nog steeds te kopiëren en plakken tussen vensters alsof het 2023 is.

Ik leef al maanden met precies deze frustratie. Mijn workflow omvat Slack voor teamcommunicatie, GitHub voor versiebeheer, Figma voor designreferenties en Xcode voor iOS-builds. Vóór Codex plugins vereiste het verbinden hiervan ofwel aangepaste MCP server-configuraties of veel handmatig context invoeren. De belofte van plugins is dat iemand anders die bedrading al heeft gedaan — je installeert en gaat aan de slag.

De vraag is of die belofte in de praktijk standhoudt. Spoiler: op sommige plekken wel en op andere absoluut niet. Maar de onderliggende architectuur is solide genoeg dat de ruwe kantjes oplosbaar aanvoelen, niet fundamenteel.

Voordat ik je door de specifieke plugins loop die ik heb getest, moet je begrijpen hoe het drielagensysteem werkelijk functioneert — want die architectuur bepaalt alles over wat plugins wel en niet kunnen.

De drielagenarchitectuur: Skills, Apps en MCP Servers

Elke Codex plugin is een pakket dat maximaal drie typen componenten bevat, en het begrijpen van het verschil ertussen bespaarde me uren van verwarring tijdens het testen. De meeste berichtgeving over deze lancering behandelt "plugins" als een monolithisch concept. Dat zijn ze niet. De drie lagen dienen compleet verschillende doeleinden.

Skills: de hersenlaag

Skills zijn herbruikbare instructies die Codex vertellen hoe specifieke soorten werk aan te pakken. Ze kunnen zo simpel zijn als een tekstprompt — "Gebruik bij het scaffolden van een React-component altijd TypeScript interfaces in plaats van type aliases" — of zo complex als een meerstaps-buildscript dat compilatie, testen en deployment beheert.

Wat skills anders maakt dan simpelweg instructies in je systeemprompt plakken, is persistentie en deelbaarheid. Een skill leeft in het plugin-pakket. Iedereen die die plugin installeert krijgt dezelfde skill. En Codex laadt relevante skills automatisch op basis van wat je aan het doen bent, in plaats van dat je moet onthouden welke instructies bij welke taak horen.

Ik testte dit met de skills van de Build iOS Apps plugin, waaronder een iOS debugger-skill en een project-scaffolding-skill. De debugger-skill zegt niet alleen "help me iOS-apps debuggen" — het bevat specifieke kennis over Xcode Build MCP-integratie, veelvoorkomende SwiftUI-layoutproblemen en hoe je Xcode's berucht cryptische foutmeldingen moet interpreteren. Toen ik Codex vroeg een layout-renderingprobleem in een SwiftUI-preview te debuggen, riep het automatisch de debugger-skill aan en liep het diagnostische proces door in een volgorde die logisch was.

De beperking: skills zijn slechts zo goed als de instructies die ze bevatten. Een slecht geschreven skill is erger dan helemaal geen skill, omdat Codex slechte instructies met vertrouwen opvolgt. Er is geen validatielaag die controleert of het advies van een skill daadwerkelijk correct is.

Apps: de handenlaag

Apps zijn connectors voor diensten van derden — de onderdelen waarmee Codex kan communiceren met tools als Slack, GitHub, Notion, Gmail, Google Drive, Box, Figma, Linear, Canva en andere. Wanneer je een plugin installeert die een app-connector bevat, geef je Codex de mogelijkheid om informatie uit die dienst te lezen en er acties in uit te voeren.

Hier komt authenticatie in beeld. Elke app-connector vereist zijn eigen auth-flow, en tijdens mijn tests varieerde dit van naadloos (GitHub's OAuth duurde ongeveer tien seconden) tot irritant (één connector vereiste dat ik handmatig een API-token genereerde, het inplakte en de plugin herstartte). De auth-ervaring is inconsistent, en ik vermoed dat het aanzienlijk zal variëren afhankelijk van welke dienst van derden je verbindt.

Eenmaal geauthenticeerd werken de app-connectors goed. Ik verbond de Slack plugin en vroeg Codex een kanaal samen te vatten waar mijn team een deploymentprobleem had besproken. Het haalde de laatste 50 berichten op, identificeerde de relevante technische discussie en gaf me een samenvatting die daadwerkelijk de nuance ving — niet alleen "mensen praatten over deployments" maar "het team identificeerde een race condition in de queue worker die optreedt bij meer dan 200 gelijktijdige verbindingen." Dat niveau van contextueel begrip is oprecht nuttig.

De Figma-connector is een andere uitblinker. Direct vanuit een codingsessie naar een designbestand kunnen verwijzen — "pas de spacing aan van dit Figma-frame" — elimineert een van de meest irritante contextwisselingen in front-end development.

MCP Servers: het zenuwstelsel

Model Context Protocol servers zijn de middleware-laag die Codex verbindt met externe buildtools, databases, monitoringsystemen en alles wat een persistente, bidirectionele verbinding nodig heeft. Als skills de hersenen zijn en apps de handen, dan zijn MCP servers het zenuwstelsel dat onder alles doorloopt.

De belangrijkste MCP server in het huidige plugin-ecosysteem is Xcode Build MCP, die meegeleverd wordt met de Build iOS Apps plugin. Deze server beheert build-gerelateerde taken — targets opsommen, compilatie triggeren, build-output vastleggen en de app in een simulator draaien. Het transformeert Codex van een codesuggestietool naar iets dat meer lijkt op een buildsysteemoperator.

Ik volg de MCP-standaard nauwgezet sinds Anthropic de specificatie publiceerde, en zien dat OpenAI het adopteert voor Codex plugins is significant. Het betekent dat plugins dezelfde MCP server-infrastructuur kunnen benutten die Claude Code, Cursor en andere tools eromheen bouwen. Een goed gebouwde MCP server werkt over het hele ecosysteem, niet alleen binnen de tool van één leverancier.

De praktische implicatie: als je al MCP servers hebt opgezet voor een andere codingtool, kan een deel van die configuratie overgezet worden naar Codex plugins. Ik testte dit met een aangepaste MCP server die ik had gebouwd voor een database-monitoringworkflow, en met enkele manifest-aanpassingen werkte het binnen een Codex plugin-structuur. Die portabiliteit is belangrijk.

Plugins installeren en beheren: hoe het proces er werkelijk uitziet

De installatieflow heeft twee paden, en ze bedienen verschillende doelgroepen. Begrijpen welk pad je moet gebruiken, behoedde me voor een frustrerende valse start.

Pad 1: de plugindirectory

Typ /plugins in de Codex-interface en je krijgt een doorzoekbare directory van beschikbare plugins. Elke vermelding toont de pluginnaam, een beschrijving, welke componenten het bevat (skills, apps, MCP servers) en een installatieknop. Klik op installeren, voltooi eventuele authenticatievereisten, en de plugin is direct actief.

De directory bevat momenteel integraties met:

• Communicatie: Slack (kanalen samenvatten, antwoorden opstellen, updates posten)
• Design: Figma (designs raadplegen, componentspecificaties ophalen, spacing controleren)
• Projectmanagement: Linear (issues bijhouden, status bijwerken, tickets refereren in code)
• Documentatie: Notion (referentiedocumenten ophalen, wiki's bijwerken, kennisbanken doorzoeken)
• Opslag: Google Drive (toegang tot documenten, spreadsheets en presentaties), Box (bestandsbeheer)
• E-mail: Gmail (e-mail lezen en beheren binnen codingcontext)
• Code: GitHub (PR-beheer, issue tracking, code doorzoeken), Sentry (foutmonitoring), Hugging Face (modelreferenties)
• Designtools: Canva (beheer van design-assets)
• Ontwikkelworkflows: Build iOS Apps, Build macOS Apps

Eenmaal geïnstalleerd roep je een plugin aan met het @-symbool — @slack summarize #deployments of @figma show me the header component from the main design file. Deze conventie is vertrouwd van andere tools en werkt intuïtief.

Iets wat me direct opviel: er wordt geen versie-informatie weergegeven voor welke plugin dan ook. Je kunt niet zien wanneer een plugin voor het laatst is bijgewerkt, wat er tussen versies is veranderd, of je de nieuwste release draait. Voor een systeem dat productierijp zou moeten zijn, is dit een echt hiaat. Ik ben al vaak genoeg in de problemen gekomen door verouderde toolintegraties om dit als een significant risico te beschouwen.

Pad 2: lokale plugin-builds

Voor aangepaste plugins — of als je een bestaande wilt aanpassen — werk je met een manifest-bestand en een lokale skills-directory. Het manifest is een JSON-bestand dat declareert wat de plugin bevat:

{
  "name": "my-custom-plugin",
  "description": "Custom workflow for my iOS development process",
  "skills": [
    {
      "name": "swift-conventions",
      "type": "prompt",
      "content": "When writing Swift code for this project, always use async/await instead of completion handlers. Prefer struct over class unless reference semantics are required. Use SwiftUI previews for every view component."
    }
  ],
  "mcp_servers": [
    {
      "name": "xcode-build",
      "command": "npx",
      "args": ["xcode-build-mcp"]
    }
  ]
}

De manifest-gebaseerde aanpak is krachtig omdat je meerdere skills kunt combineren in één installeerbaar pakket. Ik heb al een verzameling codingconventies, buildscripts en projectspecifieke instructies verspreid over verschillende configuratiebestanden. Ze verpakken in een plugin betekent dat ik mijn volledige workflow-setup met één commando kan installeren op een nieuwe machine — of delen met een teamlid dat bij een project komt.

De installatie voor lokale plugins houdt in dat je Codex naar je manifest-bestand wijst. Het leest de declaratie, zet eventuele MCP servers op, laadt de skills en maakt alles beschikbaar via hetzelfde @-aanroeppatroon.

Wat ontbreekt bij beide paden is een goed afhankelijkheidssysteem. Als Plugin A een specifieke MCP server-versie vereist die conflicteert met de vereisten van Plugin B, moet je het conflict zelf uitzoeken. Dit heeft me nog niet gebeten met de huidige 20+ plugins, maar naarmate het ecosysteem groeit, zal het een probleem worden.

De Build iOS Apps Plugin testen: waar theorie de praktijk ontmoet

De Build iOS Apps plugin was degene die me alles deed sluiten om op te letten, dus ik gaf hem de grondigste test. Deze plugin bundelt verschillende skills — waaronder een iOS debugger en een project scaffolder — met de Xcode Build MCP server om een workflow te creëren voor het bouwen van native iOS-applicaties vanuit Codex.

De opzet

Ik had een bestaande macOS-app — een Markdown-presentatietool waar ik aan had gewerkt — en ik wilde testen of de plugin het naar iOS kon porten. Dit is een echte taak die ik wekenlang had uitgesteld omdat het beheren van multi-target Xcode-projecten een van die klusjes is die vervelend genoeg zijn om steeds naar "volgende sprint" te schuiven.

Ik maakte een nieuwe Git-branch aan (ik heb op de harde manier geleerd om AI-tooling nooit op mijn main-branch te laten werken), opende het project in Codex, installeerde de Build iOS Apps plugin en vroeg het om een iPhone-target toe te voegen aan mijn bestaande Markdown-presentator-app.

Wat werkte

De scaffolding was oprecht indrukwekkend. De plugin maakte een iOS-app-target aan, zette de buildconfiguratie op, vestigde gedeelde code tussen de macOS- en iOS-targets en genereerde de initiële SwiftUI-views — allemaal via de Xcode Build MCP-integratie. Ik raakte Xcode geen enkele keer aan tijdens de initiële setup.

De build-test-cyclus is waar de plugin zijn waarde bewees. Codex schreef code, triggerde een build via de MCP server, ving de build-output op, identificeerde fouten en loste ze op — alles in een continue cyclus. Apple's xcodebuild-tool kan schemes opsommen en build-, test- en archive-acties uitvoeren vanuit de terminal, en de MCP server benut dit om Codex in een agentische lus te houden in plaats van dat ik naar de Xcode GUI moest schakelen.

Ik keek toe hoe het vier opeenvolgende buildfouten oploste — een ontbrekende import, een type-mismatch, een verouderd API-gebruik en een ontbrekende entitlement — zonder mijn interventie. Elke keer las het de foutoutput, identificeerde de oorzaak, paste een fix toe en bouwde opnieuw. Die cyclus zou me vijftien minuten Xcode-gepruts hebben gekost. Codex deed het in ongeveer negentig seconden.

Wat niet werkte

Hier moet ik eerlijk zijn, want de demo's laten dit er soepeler uitzien dan de realiteit.

De iPhone-app die de plugin produceerde was functioneel in de strengste zin — het compileerde, startte in de simulator en toonde dia's van mijn Markdown-bestanden. Maar de UI was ruw. Lettertypekleuren waren niet geoptimaliseerd voor de weergavekenmerken van de iPhone. Diaweergave was buggy — overgangen haperde, en af en toe renderde een dia met verkeerde afmetingen. De bedieningselementen (volgende/vorige knoppen, een voortgangsindicator) waren gepositioneerd voor een macOS-venster en zagen er onhandig uit op een telefoonscherm.

Sommige van deze problemen komen voort uit de fundamentele uitdaging van het porten van een desktopapp-concept naar mobiel. De scaffolding-skill van de plugin gaat uit van een bepaalde app-architectuur, en wanneer je bestaande app niet aan die aannames voldoet, past de gegenereerde code zich slecht aan. Mijn Markdown-presentator gebruikt aangepaste renderinglogica waar de scaffolder niet volledig rekening mee hield.

De debugger-skill identificeerde enkele van deze UI-problemen toen ik ze aanwees, maar kon ze niet allemaal autonoom oplossen. Het lettertypekleurprobleem vereiste begrip van de relatie tussen de appearance-instellingen van de app en iOS's licht/donker-modusafhandeling — een nuance die de instructies van de skill niet diep genoeg behandelden.

En de renderingbugs in de diaweergave? Die bleken een Core Animation-timingprobleem te zijn dat specifiek was voor de manier waarop ik overgangen had geïmplementeerd. De debugger-skill suggereerde generieke fixes (animatieduur aanpassen, controleren op main thread-schendingen), maar de daadwerkelijke fix vereiste begrip van mijn specifieke implementatie. Begrijpelijk — geen skill kan elke codebase voorzien.

Het verdict over Build iOS Apps

De plugin is een solide startpunt maar geen afgeronde oplossing. Het handelt het vervelende setupwerk af — target-aanmaak, buildconfiguratie, gedeelde codestructuur — beter dan welke tool ik ook heb gebruikt. De buildcyclus via Xcode Build MCP is oprecht krachtig en bespaart echte tijd. Maar de gegenereerde iOS-code heeft significante verfijning nodig voordat het productiekwaliteit heeft.

Ik zou het beoordelen op ongeveer 60-70% van de weg naar een verscheepbare app. Die laatste 30-40% — de afwerking, de platformspecifieke optimalisaties, de edge cases — vereist nog steeds menselijke expertise. Het "nog niet productierijp" noemen is accuraat, maar het nutteloos noemen zou diep oneerlijk zijn. Het comprimeerde wat een tweedaags portingproject zou zijn geweest tot een verfijningssessie van vier uur.

Je eigen plugin bouwen: het deel waar niemand over praat

De meeste berichtgeving over deze lancering richt zich op de voorgebouwde plugins. Dat mist het interessantere verhaal: de mogelijkheid om aangepaste plugins te maken die je bestaande workflows verpakken in deelbare, installeerbare pakketten.

Ik besloot een plugin te bouwen die drie dingen combineert die ik constant gebruik: mijn Swift-codingconventies, een build-and-run-script voor mijn standaard projectstructuur, en een MCP server-verbinding voor database-statusinspectie. Vóór plugins leefden deze in aparte configuratiebestanden en vereisten handmatige setup bij elk nieuw project.

Stap 1: definieer je skills

Begin met de skills — de herbruikbare instructies die je plugin zal bieden. Ik maakte er drie:

Een codingconventies-skill die de Swift-stijlgids van mijn team codeert: naamconventies, architectuurpatronen (MVVM met coordinators), testvereisten (elke publieke functie krijgt een unit test) en SwiftUI-specifieke richtlijnen (preview providers voor elke view, environment objects boven singletons).

Een buildscript-skill die de daadwerkelijke shell-commando's bevat voor het compileren, testen en draaien van de app. Dit is geen prompt — het is een script dat Codex uitvoert via de MCP server. Het handelt de volledige buildlevenscyclus af: clean, build, tests draaien, dekkingsrapporten genereren en de app lanceren in de simulator met specifieke apparaatconfiguraties.

Een debug-workflow-skill die een systematische aanpak definieert voor veelvoorkomende problemen: controleer eerst buildlogs, dan console-output, dan memory graph, dan instruments-traces. Deze volgorde weerspiegelt hoe ik na jaren iOS-ontwikkeling daadwerkelijk problemen debug, en het coderen als skill betekent dat Codex hetzelfde proces volgt.

Stap 2: sluit de MCP Servers aan

Het manifest-bestand declareert welke MCP servers de plugin nodig heeft. Voor mijn plugin zijn dat de Xcode Build MCP (voor buildoperaties) en een aangepaste SQLite MCP server die ik heb gebouwd voor het inspecteren van lokale databasestatus tijdens ontwikkeling.

{
  "name": "ios-dev-workflow",
  "description": "Complete iOS development workflow with Swift conventions, build automation, and database inspection",
  "skills": [
    {"name": "swift-conventions", "file": "skills/swift-conventions.md"},
    {"name": "build-script", "file": "skills/build-script.sh", "type": "script"},
    {"name": "debug-workflow", "file": "skills/debug-workflow.md"}
  ],
  "mcp_servers": [
    {
      "name": "xcode-build",
      "command": "npx",
      "args": ["xcode-build-mcp"]
    },
    {
      "name": "sqlite-inspector",
      "command": "node",
      "args": ["./mcp-servers/sqlite-inspector/index.js"]
    }
  ]
}

Stap 3: test en itereer

Installeer de plugin lokaal, draai hem tegen een echt project en kijk waar het misgaat. Mijn eerste versie had een skill-conflict — de codingconventies-skill zei "gebruik altijd async/await" terwijl het buildscript geschreven was met completion handler-patronen. Codex volgde beide instructies op en genereerde verwarde, hybride code. Dit oplossen betekende ervoor zorgen dat alle skills binnen een plugin intern consistent zijn.

De iteratiecyclus voor aangepaste plugins is snel. Bewerk een skill-bestand, herinstalleer de plugin, test hem. Geen compilatiestap, geen buildproces. Het zijn gewoon configuratiebestanden en scripts.

De kracht van compositie

Wat me oprecht enthousiast maakt over aangepaste plugins is het compositiepotentieel. Ik kan mijn volledige iOS-ontwikkelworkflow in één plugin verpakken. Een collega die aan Android werkt kan de zijne verpakken. We installeren elkaars plugins en erven direct de best practices en automatisering van de ander.

Dit is hetzelfde idee achter skills-systemen in andere tools — ik heb geschreven over hoe skills.sh werkt met Claude Code agents — maar Codex's implementatie voegt de app-connector- en MCP server-lagen toe, waardoor plugins zwaarder maar capabeler worden.

Voor teams die hun ontwikkelproces moeten standaardiseren, is dit de echte waardepropositie. Niet de voorgebouwde Slack-integratie — je team kan die in tien minuten opzetten ongeacht. De waarde zit in het coderen van de opgebouwde kennis van je team in een pakket dat elk nieuw teamlid op dag één kan installeren.

Als je liever hebt dat iemand dit soort aangepaste ontwikkelworkflow vanaf nul bouwt, neem ik AI-tooling- en automatiseringsprojecten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.

Hoe Codex Plugins zich verhouden tot de concurrentie

Ik kan Codex plugins niet geïsoleerd beoordelen omdat ik actief drie andere plugin/skill-ecosystemen gebruik. De vergelijking is belangrijk omdat je keuze van AI-codingtool steeds meer afhangt van welk ecosysteem de integraties heeft die je nodig hebt.

Codex Plugins vs. Claude Code Skills

Het skill-systeem van Claude Code is volwassener voor pure codingworkflows. Skills in Claude Code zijn diep geïntegreerd met het agent-model — ze kunnen sub-agents spawnen, context beheren over lange sessies en Claude's sterke redenering benutten voor complexe architectuurbeslissingen. Ik gebruik Claude Code agent teams voor multi-bestand refactoring-taken, en de skill-gebaseerde coördinatie is iets dat Codex plugins nog niet kunnen evenaren.

Waar Codex plugins winnen is de app-connectorlaag. Claude Code heeft geen native Slack-, Figma- of Linear-integratie in hetzelfde gebundelde formaat. Je kunt MCP servers voor die diensten handmatig opzetten, maar de one-click installatieervaring van Codex plugins is merkbaar soepeler voor teams die integratie willen zonder configuratie.

Codex Plugins vs. Cursor Composer

Cursor's aanpak is anders — het richt zich op IDE-native integratie in plaats van plugin-uitbreidbaarheid. Cursor is uitstekend in het begrijpen van je codebase-context en het genereren van code die past, maar het heeft geen plugin-marktplaats of skill-deelmechanisme. Als je behoeften verder gaan dan codegeneratie — projectmanagementintegratie, designbestandreferenties, buildautomatisering — vereist Cursor externe tooling.

De ecosysteemweddenschap

De eerlijke beoordeling: het plugin-ecosysteem van geen enkele tool is nog compleet. Ik gebruik Codex voor zijn Slack- en Figma-connectors, Claude Code voor zijn agent-architectuur en redeneringdiepte, en Cursor voor zijn IDE-integratie. Consolideren naar één tool zou betekenen dat ik mogelijkheden verlies die ik dagelijks gebruik.

OpenAI's weddenschap is dat het plugin-ecosysteem snel genoeg zal groeien om Codex de enige tool te maken die je niet hoeft te verlaten. Die weddenschap hangt volledig af van of externe ontwikkelaars hoogwaardige plugins bouwen — en op dit moment is zelfbediende pluginpublicatie nog niet beschikbaar. OpenAI heeft de initiële 20+ plugins gecureerd, maar het ecosysteem moet opengaan voordat het kan concurreren met de breedte aan MCP servers die beschikbaar zijn voor Claude Code.

De hiaten die je moet kennen

Ik ben positief geweest over de architectuur, en ik wil dat in balans brengen met de echte beperkingen die ik tegenkwam. Dit zijn geen kleine klachten — het zijn problemen die bepalen of plugins centraal worden in je workflow of een leuk extraatje blijven.

Geen pluginversiebeheer. Dit is het grootste hiaat. Wanneer een plugin wordt bijgewerkt, heb je geen manier om te weten wat er is veranderd, of het je workflow kan breken, of hoe je terug kunt naar een vorige versie. Voor individuele ontwikkelaars die experimenteren is dit vervelend. Voor teams die in productie-workflows op plugins vertrouwen, is het een echt risico.

Inconsistente authenticatie. Sommige plugins authenticeren naadloos via OAuth. Andere vereisen handmatige tokengeneratie en plakken. Minstens één plugin die ik testte vereiste het herstarten van Codex na authenticatie om de nieuwe credentials op te pikken. Dit moet gestandardiseerd worden.

Geen afhankelijkheidsbeheer. Plugins kunnen geen afhankelijkheden declareren van andere plugins of specifieke MCP server-versies. Naarmate het ecosysteem groeit en plugins infrastructuur gaan delen, zal dit conflicten veroorzaken.

Beperkte foutrapportage. Wanneer een plugin faalt, zijn de foutmeldingen vaak generiek — "plugin execution failed" zonder details over welk component (skill, app of MCP server) daadwerkelijk kapotging. Het debuggen van pluginproblemen vereist meer trial-and-error dan nodig zou moeten zijn.

Alleen macOS voor de Codex-app. De volledige pluginervaring vereist de Codex desktop-app, die momenteel alleen draait op macOS met Apple Silicon. De CLI en VS Code-extensie ondersteunen plugins, maar de ervaring is beperkter — je verliest de visuele plugindirectory en sommige authenticatieflows. Windows alpha-testen is gestart, maar Linux-ondersteuning is nog niet in zicht.

Wat dit betekent voor je workflow in 2026

Het Codex pluginsysteem gaat je bestaande toolsetup niet van de ene op de andere dag vervangen. Zo werkt de adoptie van ontwikkelaarstooling niet. Maar het verandert wel de beslismatrix voor teams die AI-codingassistenten evalueren.

Als je Codex al gebruikt en je workflow Slack, GitHub, Figma of een van de andere geïntegreerde diensten omvat, installeer dan onmiddellijk de relevante plugins. De tijdsbesparing op contextwisselingen alleen al rechtvaardigt de tien minuten setup.

Als je Codex vergelijkt met Claude Code of Cursor, wordt het pluginsysteem een betekenisvol onderscheidend kenmerk — maar alleen als de specifieke integraties die je nodig hebt beschikbaar zijn. Controleer de plugindirectory vóór je een beslissing neemt, niet erna.

Als je een teamleider bent die nadenkt over standaardisatie op een AI-codingtool, is de aangepaste pluginmogelijkheid de functie om het zorgvuldigst te evalueren. De mogelijkheid om de conventies, buildprocessen en integratiepatronen van je team te coderen in een installeerbaar pakket is een echte productiviteitsmultiplicator. Het transformeert onboarding van "lees de wiki en zoek onze setup uit" naar "installeer deze plugin en begin met coderen."

En als je een toolbouwer of MCP server-ontwikkelaar bent, is dit een marktsignaal. OpenAI zet in op dezelfde MCP-standaard die Anthropic heeft gepionierd. Bouwen voor MCP betekent dat je integratie over het hele ecosysteem werkt, niet alleen binnen de ommuurde tuin van één leverancier.

Het pluginsysteem is drie dagen geleden gelanceerd. Sommige van mijn klachten zullen in updates worden aangepakt. Andere vertegenwoordigen architectuurbeslissingen die niet snel zullen veranderen. Maar het fundament — skills voor kennis, apps voor integratie, MCP servers voor infrastructuur — is solide. Wat er de komende zes maanden bovenop wordt gebouwd, zal bepalen of Codex plugins essentieel of slechts interessant worden.

Ik ben van plan een aangepaste plugin te bouwen die mijn volledige AI-ontwikkelworkflow omvat — skills van Claude Code, MCP servers die ik heb gebouwd voor database- en monitoringtools, en app-connectors voor de diensten waar mijn team op vertrouwt. Wanneer dat klaar is, deel ik het manifest en loop ik het volledige bouwproces door.

Voor nu zijn de twintig-plus plugins die bij de lancering beschikbaar zijn het installeren en testen waard. Begin met degene die verbinding maken met diensten die je al dagelijks gebruikt. De Slack plugin alleen al heeft me meer tijd bespaard dan het hele testproces kostte.

De oorlog om AI-codingtools gaat niet meer over welk model de beste code genereert. Het gaat over welke tool het meest naadloos past in de manier waarop je al werkt. Plugins zijn OpenAI's sterkste zet richting het winnen van die oorlog — vandaag onvolmaakt, maar architecturaal gepositioneerd om zeer snel veel beter te worden.

Veelgestelde vragen

Wat zijn OpenAI Codex plugins?

Codex plugins zijn installeerbare pakketten die drie typen componenten bundelen — skills (herbruikbare instructies), apps (connectors voor diensten van derden) en MCP servers (middleware voor buildtools en externe systemen) — in deelbare workflows. Ze zijn gelanceerd op 26 maart 2026, met 20+ integraties beschikbaar via de Codex-app, CLI en VS Code-extensie.

Hoe installeer ik Codex plugins?

Typ /plugins in de Codex-app om door de plugindirectory te bladeren. Selecteer een plugin, voltooi de authenticatieflow indien vereist, en het wordt direct beschikbaar via het @-symbool. Voor aangepaste plugins maak je een manifest JSON-bestand dat je skills en MCP servers declareert, en wijs je Codex naar het lokale bestand.

Kan ik mijn eigen Codex plugins bouwen?

Ja. Aangepaste plugins gebruiken een manifest-bestand dat skills (tekstprompts of scripts), app-connectors en MCP server-configuraties declareert. Er is geen compilatie nodig — bewerk het manifest en skill-bestanden, installeer lokaal en test. Zelfbediende publicatie naar de officiële plugindirectory is nog niet beschikbaar per maart 2026.

Produceert de Build iOS Apps plugin productierijpe code?

Nog niet. De plugin handelt project-scaffolding, buildconfiguratie en multi-target-setup goed af, en zijn Xcode Build MCP-integratie maakt krachtige build-testcycli mogelijk. Maar de gegenereerde UI-code heeft significante verfijning nodig — verwacht tijd te besteden aan het oppoetsen van layouts, het oplossen van platformspecifieke renderingproblemen en het optimaliseren voor iOS-weergavekenmerken.

Hoe verhouden Codex plugins zich tot Claude Code skills?

Claude Code skills bieden diepere agent-coördinatie en sterkere redenering voor complexe codingtaken. Codex plugins voegen app-connectors van derden toe (Slack, Figma, Linear) en een one-click installatieervaring die de handmatige MCP-setup van Claude Code niet kan evenaren. De twee systemen bedienen verschillende sterktes — geen van beide vervangt de ander volledig per maart 2026.

Laten we samenwerken

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

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io