Inside the Harness : Turn-Scoped Permissions deviennent une primitive d'Agent Runtime

Il y a un issue dans le repository OpenAI Codex, filed mi-juillet, qui en dit plus sur la direction des agent runtimes que la plupart des launch posts. Le reporter a remarqué que si vous changez le permission mode de Codex pendant qu'un turn tourne, le running turn vous ignore. Il garde les permissions avec lesquelles il a commencé, et votre nouveau setting ne s'applique qu'au next turn. Augmentez access mid-turn, l'agent reste blocked. Réduisez-le mid-turn et, pire, la UI dit restricted pendant que l'agent garde ses powers originaux plusieurs minutes encore.

Ce behaviour n'est pas un bug au sens évident. C'est le bord visible d'une design decision qui devient silencieusement standard dans les agent runtimes : permissions sont scoped au turn, snapshotted quand il commence, et traitées comme property de cette unit of work plutôt que du user, de la machine ou de la session. Ce piece explique cette primitive, le threat model auquel elle répond et comment Codex, reference implementation actuelle, la câble réellement.

Points clés - Turn-scoped permissions signifie que runtime snapshot une approval policy, sandbox policy et permission profile au début d'un turn, et chaque tool call dans le turn s'exécute contre ce snapshot. - Threat model n'est pas malicious user. C'est un capable agent suivant hostile instructions, prompt injection, ou dérivant off-task avec vos credentials sur votre machine. - Codex implémente boundary avec trois dials indépendants : approval policy, est-ce qu'il demande ; sandbox mode, que peuvent toucher commands ; permission profiles, fine-grained filesystem/network rules, enforced par OS, pas model. - Enforcement vit sous le model : Seatbelt macOS, bubblewrap plus seccomp Linux, sandbox dédiée Windows. Quand policy ne peut être enforced, Codex refuse command. - Frontier non résolue : mid-turn mutation. Aujourd'hui snapshot immutable pour la durée du turn, safe et parfois maddening.

Ce qui s'est passé

Fin juillet et début août, permission surface Codex s'est épaissie de deux coarse settings vers quelque chose qui ressemble davantage à policy engine, et docs ont suivi. Ancien model : deux dials dans config.toml, sandbox_mode (read-only, workspace-write, danger-full-access) et approval_policy (untrusted, on-request, never). Nouveau model ajoute permission profiles, beta : policies nommées, composable, combinant filesystem rules (read, write, deny par path, deny wins) et network rules, domain allowlists enforced via local proxy. Trois built-ins ship avec runtime : :read-only, :workspace, :danger-full-access, et vous les étendez au lieu de repartir de zéro.

Interaction model devient aussi plus turn-native. /permissions change modes dans running session. Granular approval policy laisse certaines prompt categories interactive, sandbox escalations, MCP elicitations, tout en auto-rejectant d'autres, dont distinct request_permissions category, l'agent lui-même demandant davantage access mid-task. Et approvals peuvent être routed vers automatic reviewer agent qui screen requests pour exfiltration, credential probing, destructive actions avant qu'un human ne les voie, selon OpenAI approvals/security docs.

Ce n'est pas un seul announcement. C'est runtime qui développe une permission layer comme operating systems ont développé user accounts : à contrecœur et au contact de la réalité.

OpenAI Codex est passé de deux coarse settings, sandbox mode et approval policy, à named permission profiles combinant per-path filesystem rules et proxied network domain rules, avec mid-session switching, granular approval categories et optional auto-reviewing agent, selon official permissions docs et approvals docs.

Ce que "turn-scoped" signifie vraiment

Définition la plus propre : ensemble de ce que l'agent peut faire est lié à lifetime d'un single turn, capturé quand turn commence et en principe released quand il finit. Pas au user, qui pourrait s'absenter une heure ; pas à machine, qui héberge many turns de risk très différent ; même pas à session, qui peut review code le matin et installer dependencies après déjeuner.

Issue Codex qui ouvre ce piece prouve que snapshot est réel. Running turn "retains a permission or sandbox snapshot created when the turn starts", selon reporter, et fix proposé est machinery pour propager nouvelle approval policy, sandbox policy et permission profile dans active turn, ou sinon internal pause-and-resume pour redémarrer turn sous fresh permissions sans re-prompt user. Acceptance criteria ressemblent à spec turn-scoped permissions first-class : réduire permissions mid-turn doit block violating operations nouvelles, les augmenter doit unblock agent, resumed/delegated/compacted turns doivent préserver updated context.

Pourquoi snapshot ? Alternative pire. Si permissions sont mutable global state, tout ce qui influence state, content que agent lit inclus, obtient lever sur ce que agent peut faire ensuite. Immutable-per-turn snapshot signifie permission decision faite une fois par human/policy à moment de clear intent, et agent ne peut parler son chemin autour mid-flight. Turn devient smallest unit of trust, correspondant à agent work : "review this diff" et "push to main" ne devraient jamais partager permission context, même si same session.

Codex lie permissions à turn-start snapshot : issue juillet 2026 documente que changer access modes mid-turn n'affecte pas running turn et propose de propager updated approval policy, sandbox policy et permission profiles dans active turn, avec resumed/delegated turns préservant new context.

Le threat model auquel cela répond

Soyons précis, car "agent security" couvre beaucoup de vague worry. Threat model derrière turn-scoped permissions a trois actors nommés, aucun hacker en hoodie.

Prompt injection est headline threat. Agent lit untrusted content toute la journée : repositories, web pages, issue tickets, tool output. Tout peut contenir instructions visant agent. Docs OpenAI sont directes : default web search mode cached plutôt que live pour réduire injection exposure, guidance avertit que network access permet injected agent de fetch/follow untrusted instructions. Turn-scoped sandbox network-off-by-default cap ce qu'une successful injection atteint dans ce turn.

Drift et over-reach est la menace silencieuse. Capable agent faisant legitimate work va quand même wander : installer quelque chose, fetch dependency, "helpfully" nettoyer directory. Sandbox répond sans agent malicious, d'où boundary enforced par OS, Seatbelt macOS, bubblewrap plus seccomp Linux, native sandbox Windows, pas model judgement. Si platform ne peut enforce requested policy, Codex refuse command plutôt que running unsandboxed. Fail closed, pas fail hopeful.

Credential exposure est multiplier. Devcontainer guidance le dit : Codex full access dans container et malicious project peut exfiltrate tout dedans, y compris Codex credentials. D'où nouvelles primitives spécifiques aux secrets : "**/*.env" = "deny" globs retirent credential files des writable workspaces, .git, .codex, .agents protégés read-only dans writable roots, network proxy bloque local/private destinations par default comme DNS-rebinding defence. Même shape que broader architecture question dans agentic AI architecture : model proposes, harness disposes, harness should hold secrets.

Threat model documenté Codex centre prompt injection, network off by default et cached web search pour réduire hostile live content, agent drift, OS-enforced sandboxes refusant commands si policy non enforceable, credential exposure, deny globs .env, read-only .git/.codex, local-network blocking, selon OpenAI security docs.

Comment l'implémentation tient ensemble

Trois implementation details à voler.

Deny bat write, write bat read, à specificity égale. Permission profiles permettent broad access puis carve out exceptions : workspace writable, **/*.env denied, .devcontainer read-only. More specific paths override broad rules, denied subpath reste denied dans writable parent. Vous pouvez reopen narrow subtree dans broad deny, ~/Documents denied, ~/Documents/codex writable. C'est right precedence model car least-privilege devient additive to write plutôt que subtractive from memory.

Network access et network filtering sont switches séparés. network.enabled = true autorise commands à atteindre network ; features.network_proxy = true est ce qui enforce réellement domain rules via local proxy. L'un sans l'autre donne unrestricted outbound access avec false sense governance. Domain rules allowlist-first, deny wins, localhost et friends blocked sauf explicit allow, car sandboxed agent avec access aux local daemons n'est pas meaningfully sandboxed.

Old/new systems ne composent pas. Profiles et legacy sandbox_mode mutually exclusive ; si any loaded config sets sandbox_mode, profiles ignored. Enterprise admins peuvent forcer new model via managed allowed_permission_profiles allowlist, qui deny aussi omitted built-ins. Operational lesson : deux permission systems qui "both apply" vous font croire que vous avez denied quelque chose alors que non. Pick one, verify /permissions et /status, puis expand.

Pour teams opérant agents beyond CLI, pattern generalise. Snapshot permission context per task, credentials dans tool-execution layer pas model context, enforce below model, expire task end. Vendor runtime versus own harness est question build versus buy, et si self-host, self-hosted agent trade-offs s'appliquent avec plus de knobs.

Codex permission profiles utilisent deny-over-write-over-read precedence avec specificity overrides, séparent network enablement de proxied domain enforcement et refusent composition avec legacy sandbox settings pour éviter ambiguity ; admins peuvent mandate profiles via managed allowlists, selon permissions docs.

Que faire maintenant

1. Aujourd'hui : lancez /permissions et /status dans prochaine Codex session, regardez ce qui est vraiment in effect. Si any config layer sets encore sandbox_mode, vous avez silently opted out de permission profiles. Choisissez system.

2. Cette semaine : écrivez custom profile étendant :workspace, deny **/*.env, allow seulement API domains réellement appelés, network_proxy on. Testez avec codex debug, sandbox command, avant de trust. Si vous review third-party code, pin ces projects à profile dérivé de :read-only.

3. Ce mois-ci : si vous build/wrap agent runtime, adoptez turn comme permission unit : snapshot turn start, expire turn end, secrets hors model context, enforcement fail closed. Puis écrivez réponse à open question Codex : que faire si permissions changent mid-turn ? "Nothing until the next turn" est safe, mais users attendent que UI signifie ce qu'elle dit.

FAQ

Que sont turn-scoped permissions ?

Permission model où runtime capture approval policy, sandbox boundary et filesystem/network rules au début d'un agent turn, et applique snapshot à every tool call. Permissions sont property de unit of work, pas user, machine ou session. En principe released à fin du turn, elevated access ne persists pas by default.

En quoi est-ce différent de lancer agent comme restricted OS user ?

OS users machine-scoped et static : every task hérite same blanket. Turn scoping laisse "review this repo" read-only tandis que "install dependencies and test" tourne avec workspace writes et domain allowlist dans same session, sans changer accounts. Donne aussi endroit naturel pour expire access.

Prompt injection peut-il changer permissions Codex ?

Pas within turn, by design : running turn exécute snapshot du turn start, mid-turn settings changes ne propagent pas, behaviour issue #32612. Residual risks next turn et surfaces déjà allowed, d'où network default off et sensitive paths denied/read-only.

Permission profiles sont-ils assez stables ?

Explicitement beta et ne composent pas avec older sandbox_mode, donc direction of travel, pas finished API. Older modes stable baseline aujourd'hui. Team rollout : pick one model per client version, verify /status, attendez profile fields moving.

En bref

Agent permissions grandissent comme Unix permissions : de "root or nothing" vers fine-grained, least-privilege, auditable boundaries, sauf que unit n'est pas process/user, mais turn. Codex est implementation la plus claire à étudier, et roughest edge, immutable mid-turn snapshot, est aussi la plus instructive : même reference runtime négocie combien dynamic permission peut être avant de ne plus signifier quoi que ce soit. Si vous build/operate agents, apprenez la shape de primitive maintenant. Toute serious runtime en aura une dans un an, celles qui ratent snapshot semantics l'apprendront en public.

Si vous concevez permission layer pour vos agents et voulez second pair of eyes, c'est du travail que je fais avec client teams. Contactez-moi.

Sources

• OpenAI Developers, "Codex permissions": https://developers.openai.com/codex/permissions (consulté 2026-08-29)

• OpenAI Developers, "Agent approvals and security": https://developers.openai.com/codex/agent-approvals-security (consulté 2026-08-29)

• GitHub, openai/codex issue #32612, "Apply access-control changes to the currently running turn": https://github.com/openai/codex/issues/32612 (filed 2026-07-12, consulté 2026-08-29)

• GitHub, openai/codex issue #23626, "Codex CLI /permissions omits Read-only in WSL2 but shows it in Windows PowerShell": https://github.com/openai/codex/issues/23626 (filed 2026-05-20, consulté 2026-08-29)

• OpenAI Codex repository: https://github.com/openai/codex (consulté 2026-08-29)