Vraagt Codex steeds om goedkeuring? Goedkeuringsbeleid, sandbox en “niet meer vragen” uitgelegd
Codex vraagt om goedkeuring als een commando buiten zijn sandbox moet. De meeste klachten over “hij blijft maar vragen” komen door een te krappe sandbox, een instelling die niet meer bestaat of een “niet meer vragen” die alleen voor de sessie gold.
KORT ANTWOORD
In de huidige Codex is approval_policy ofwel on-request (de standaard: het model vraagt wanneer het nodig is), never of een granular-tabel; untrusted is verwijderd en on-failure is nu gewoon een andere naam voor on-request. Hoe vaak je iets gevraagd wordt, hangt vooral af van de sandbox: met sandbox_mode = "workspace-write" bewerkt Codex bestanden en voert het commando’s uit binnen je project zonder te vragen. Voeg voor commando’s die je altijd vertrouwt een prefix_rule met decision = "allow" toe in ~/.codex/rules/default.rules. Daar slaat “niet meer vragen voor commando’s die beginnen met …” zichzelf ook op.
Eerst: wat er in Codex is veranderd
Veel handleidingen en forumantwoorden beschrijven instellingen die niet meer werken. Controleer je ~/.codex/config.toml aan de hand van deze lijst voordat je iets afstelt:
| Oude instelling | Nu |
|---|---|
approval_policy = "untrusted" | Verwijderd. Codex meldt “approval_policy = "untrusted" is no longer supported; remove this setting”. De documentatie raadt in plaats daarvan sandbox_mode = "read-only" met on-request aan. |
approval_policy = "on-failure" | Wordt nog geaccepteerd, maar alleen als alias voor on-request. |
--full-auto | Staat niet meer in de CLI-referentie. De vlag die er het dichtst bij komt is --approve-for-me (alias --not-so-yolo): automatische beoordeling van goedkeuringen met on-request en de sandbox workspace-write. |
[profiles.name] in config.toml | Sinds Codex 0.134.0 leest --profile name in plaats daarvan $CODEX_HOME/name.config.toml. Een achtergebleven sleutel profile = "x" geeft nu een fout. |
/approvals | Gebruik /permissions (“Set what Codex can do without asking first.”) |
Ook de documentatie van Codex is verhuisd: de oude pagina’s op developers.openai.com/codex verwijzen nu door naar learn.chatgpt.com.
Hoe Codex beslist of het vraagt
Twee instellingen werken samen. De sandbox beperkt wat een commando kan aanraken: bestanden buiten het project, het netwerk. Het goedkeuringsbeleid bepaalt wat er gebeurt als een commando meer nodig heeft dan de sandbox toestaat.
| sandbox_mode | Wat Codex zonder vragen kan doen |
|---|---|
read-only (standaard) | Bestanden lezen en commando’s uitvoeren in een alleen-lezen sandbox |
workspace-write | Automatisch lezen, bewerken en commando’s uitvoeren in de werkmap |
danger-full-access | Alles, zonder sandbox. Niet aanbevolen |
| approval_policy | Gedrag |
|---|---|
on-request (standaard) | Het model beslist wanneer het vraagt. Commando’s die de sandbox toestaat, draaien zonder goedkeuring |
never | Vraagt nooit. Alles wat mislukt, gaat terug naar het model en wordt niet aan jou voorgelegd |
{ granular = { … } } | Houd sommige promptcategorieën interactief en weiger de rest automatisch (sandbox_approval, rules, skill_approval, request_permissions, mcp_elicitations) |
Zit je dus in read-only, dan heeft elke bewerking een ja nodig. Dat is dé meest voorkomende oorzaak van “Codex vraagt over alles”. Zelfs in workspace-write blijven .git, .codex, .agents en .aws alleen-lezen, en netwerktoegang staat uit tenzij je die aanzet.
Dit is de voorbeeldconfiguratie uit de documentatie van OpenAI, met uitleg bij de workspace-opties:
Nieuwere versies bieden ook machtigingsprofielen (default_permissions met de ingebouwde profielen :read-only, :workspace en :danger-full-access). Gebruik profielen of sandbox_mode, niet allebei.
Presets in de CLI, de IDE-extensie en de app
Je hoeft geen TOML te bewerken. In de CLI opent /permissions de presets; in de app en de IDE-extensie staat een machtigingsinstelling onder het invoerveld. De presets in de CLI zijn:
- Read Only: leest de workspace; goedkeuring is nodig om bestanden te bewerken of internet te gebruiken.
- Default: bewerkt binnen de workspace; goedkeuring is nodig om internet te gebruiken of andere bestanden te bewerken.
- Full Access: bewerkt buiten de workspace en gebruikt internet zonder te vragen.
De app en de IDE-extensie beschrijven dezelfde keuze als Ask for approval, Approve for me en Full access. Oudere IDE-screenshots noemen ze Chat, Agent en Agent (Full Access).
Specifieke commando’s toestaan met regels
Wil je dat Codex één commando buiten de sandbox uitvoert zonder te vragen (bijvoorbeeld gh pr view), schrijf dan een regel. Regels zijn experimenteel en staan in een .rules-bestand in een map rules/ naast een configuratielaag, bijvoorbeeld ~/.codex/rules/default.rules:
allow: buiten de sandbox uitvoeren zonder te vragen.prompt: vragen vóór elk overeenkomend commando.forbidden: blokkeren zonder te vragen.
Als meerdere regels matchen, wint de strengste: forbidden gaat boven prompt, en dat gaat boven allow. Test een commando met codex execpolicy check voordat je op een regel vertrouwt.
Wat “niet meer vragen” echt opslaat
De goedkeuringsprompt in de Codex CLI biedt verschillende soorten “ja”, en die gelden heel verschillend lang:
| Optie | Hoe lang het geldt |
|---|---|
| Yes, proceed | Dit ene commando |
Yes, and don’t ask again for commands that start with <prefix> | Permanent (als regel opgeslagen in ~/.codex/rules/default.rules) |
| Yes, and don’t ask again for this command in this session | Tot de sessie eindigt |
| Yes, and don’t ask again for these files | Bestandsbewerkingen, voor deze sessie |
Blijf je de sessieoptie kiezen, dan krijg je morgen dezelfde vraag weer. Kies de prefixoptie, of schrijf de regel zelf.
Codex op Windows
Op Windows was “hij vraagt over alles” het ergst. In issue #10187 legde een teamlid van OpenAI uit waarom: “Without a sandboxing mechanism, all tool calls need to be manually approved on Windows.” Codex heeft nu een native Windows-sandbox en gebruikt die standaard:
mxc: de aanbevolen sandbox op compatibele Windows-apparaten.elevated: de voorkeursoptie om op terug te vallen als MXC niet beschikbaar is.unelevated: een verouderde terugvaloptie.
Voer /setup-default-sandbox uit in de CLI om de elevated sandbox in te stellen (of codex sandbox setup --elevated voor IT). Windows 11 wordt aanbevolen; Windows 10 1809 of nieuwer wordt zo goed mogelijk ondersteund. Werk je in WSL, dan gebruikt Codex daar zijn Linux-sandbox, en WSL1 wordt niet meer ondersteund.
Projectconfiguratie laadt alleen in vertrouwde projecten
Een .codex/config.toml in een repo wordt alleen gelezen als je het project vertrouwt. Lijken je projectinstellingen genegeerd te worden, dan is dat de reden. Een vertrouwensvermelding in je gebruikersconfiguratie ziet er zo uit:
Instellingen zijn gelaagd, hoogste eerst: opdrachtregelvlaggen en -c-overrides, de .codex/config.toml van het vertrouwde project, het --profile-bestand, je ~/.codex/config.toml, en daarna de systeemstandaarden.
Over --yolo
--dangerously-bypass-approvals-and-sandbox (alias --yolo) voert elk commando uit zonder goedkeuringen of sandbox. De broncode beschrijft het als “EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed.” approval_policy = "never" met danger-full-access doet hetzelfde vanuit het configuratiebestand. Wil je gewoon minder prompts, dan kom je daar met workspace-write plus een paar allow-regels, terwijl de sandbox aan blijft.
Voor de prompts die overblijven
Zodra Codex alleen nog vraagt over dingen die ertoe doen (het netwerk, bestanden buiten het project, een push), is het resterende probleem dat je de vraag moet opmerken. Pet Island zet de commando- en bestandsgoedkeuringen van Codex op een klein eiland bovenaan je scherm, met het commando of de diff, zodat je ze kunt toestaan of weigeren zonder de juiste terminal te zoeken. Het laat zien wanneer Codex bezig is en klaar is, en vragen van Codex brengen je met één klik naar het juiste venster. Het werkt met de Codex CLI en de Codex-app, en als het eiland gesloten is, vraagt Codex zoals gewoonlijk in zijn eigen venster.
VEELGESTELDE VRAGEN
Hoe zorg ik dat Codex niet steeds om goedkeuring vraagt?
Gebruik sandbox_mode = "workspace-write" zodat Codex binnen je project kan bewerken en commando’s kan uitvoeren, houd approval_policy = "on-request" aan, en voeg prefix_rule-vermeldingen met decision = "allow" toe in ~/.codex/rules/default.rules voor commando’s die je altijd vertrouwt.
Wordt approval_policy = "untrusted" nog ondersteund?
Nee. De huidige Codex weigert het met “approval_policy = "untrusted" is no longer supported; remove this setting”. Gebruik in plaats daarvan sandbox_mode = "read-only" met approval_policy = "on-request".
Wat is er met --full-auto gebeurd?
Het staat niet meer in de Codex CLI-referentie. De optie die er het dichtst bij komt is --approve-for-me (alias --not-so-yolo), die automatische beoordeling van goedkeuringen gebruikt met on-request en de sandbox workspace-write.
Waarom wordt “niet meer vragen” niet onthouden?
“Don’t ask again for this command in this session” geldt alleen voor de sessie. Kies “don’t ask again for commands that start with …”, dat een regel opslaat in ~/.codex/rules/default.rules.
Waarom vraagt Codex meer op Windows?
Zonder sandbox heeft elke toolaanroep goedkeuring nodig. Codex gebruikt nu standaard een native Windows-sandbox; voer /setup-default-sandbox uit als die nog niet is ingesteld.
Waarom wordt de .codex/config.toml van mijn project genegeerd?
Codex laadt projectconfiguratie alleen voor vertrouwde projecten.
Bronnen
Elke instelling en elk gedrag op deze pagina is op 26 oktober 2026 gecontroleerd aan de hand van deze pagina’s. Agents veranderen snel; klopt er iets niet meer, dan geldt de officiële pagina.
- OpenAI: Codex agent approvals and security
- OpenAI: Codex permission modes
- OpenAI: Codex config basics
- OpenAI: Codex sample config
- OpenAI: Codex rules
- OpenAI: Codex Windows sandbox
- OpenAI: Codex CLI reference
- OpenAI: Codex slash commands
- Broncode van openai/codex (goedkeuringsprompt, configuratiefouten)
- Issue #10187: Codex vraagt herhaaldelijk om goedkeuring voor commando’s
- Issue #5131: Bestandsbewerkingen moeten altijd worden goedgekeurd
- Issue #29406: Goedkeuringsprompt blijft verschijnen ondanks don’t ask again