Inside the Harness: Turn-Scoped Permissions werden zu einer Agent-Runtime-Primitive

Es gibt ein Issue im OpenAI-Codex-Repository, Mitte Juli filed, das Ihnen mehr darüber sagt, wohin Agent Runtimes gehen, als die meisten Launch Posts. Der Reporter bemerkte: Wenn Sie Codex' Permission Mode ändern, während ein Turn läuft, ignoriert der laufende Turn die Änderung. Er behält die Permissions, mit denen er gestartet ist, und Ihre neue Einstellung gilt erst für den nächsten Turn. Erhöhen Sie Access mid-turn, bleibt der Agent blocked. Senken Sie ihn mid-turn und, schlimmer, die UI sagt restricted, während der Agent für weitere Minuten seine ursprünglichen Powers behält.

Dieses Behaviour ist nicht im offensichtlichen Sinn ein Bug. Es ist der sichtbare Rand einer Design Decision, die still zum Standard in Agent Runtimes wird: Permissions sind auf den Turn scoped, werden beim Start des Turns snapshotted und als Property dieser Unit of Work behandelt, nicht des Users, der Machine oder der Session. Dieses Piece erklärt, was diese Primitive ist, welches Threat Model sie beantwortet und wie Codex, derzeit die Reference Implementation, sie tatsächlich verdrahtet.

Wichtigste Erkenntnisse - Turn-scoped Permissions bedeuten, dass die Runtime beim Start eines Turns eine Approval Policy, Sandbox Policy und ein Permission Profile snapshotten und jeder Tool Call in diesem Turn gegen diesen Snapshot ausgeführt wird. - Das Threat Model ist kein malicious User. Es ist ein leistungsfähiger Agent, der hostile Instructions, Prompt Injection, folgt oder off-task driftet und dabei mit Ihren Credentials auf Ihrer Machine läuft. - Codex implementiert die Boundary als drei unabhängige Dials: Approval Policy, fragt es nach; Sandbox Mode, was dürfen Commands berühren; Permission Profiles, fine-grained Filesystem- und Network Rules, enforced vom OS, nicht vom Model. - Enforcement lebt unter dem Model: Seatbelt auf macOS, bubblewrap plus seccomp auf Linux, eine dedizierte Sandbox unter Windows. Wo eine Policy nicht enforcebar ist, verweigert Codex den Command. - Die unresolved Frontier ist mid-turn Mutation: Heute ist der Snapshot für die Lebensdauer des Turns immutable, was safe und gelegentlich maddening ist.

Was passiert ist

Durch Ende Juli und Anfang August wurde die Codex Permission Surface von zwei coarse Settings zu etwas, das eher wie eine Policy Engine aussieht, und die Docs holten auf. Das ältere Model bestand aus zwei Dials in config.toml: sandbox_mode (read-only, workspace-write, danger-full-access) und approval_policy (untrusted, on-request, never). Das neuere Model fügt Permission Profiles hinzu, derzeit beta: benannte, composable Policies, die Filesystem Rules (read, write, deny per Path, wobei deny gewinnt) und Network Rules, Domain Allowlists enforced durch einen Local Proxy, kombinieren. Drei Built-ins shippen mit der Runtime: :read-only, :workspace und :danger-full-access, und Sie erweitern sie, statt bei Null anzufangen.

Neben der Config Surface wurde auch das Interaction Model turn-native. /permissions wechselt Modes innerhalb einer laufenden Session. Eine granular Approval Policy lässt bestimmte Prompt Categories interactive, Sandbox Escalations, MCP Elicitations, während andere automatisch rejected werden können, darunter eine distinct request_permissions Category, also der Agent selbst, der mid-task nach mehr Access fragt. Und Approvals können an einen automatic Reviewer Agent geroutet werden, der Requests auf Exfiltration, Credential Probing und destructive Actions screened, bevor ein Human sie je sieht, laut OpenAIs Approvals und Security Documentation.

Nichts davon ist ein einzelnes Announcement. Es ist eine Runtime, die eine Permission Layer aufbaut, so wie Operating Systems User Accounts aufgebaut haben: widerwillig und als Reaktion auf Kontakt mit der Realität.

OpenAI Codex hat sich von zwei coarse Settings, Sandbox Mode und Approval Policy, zu named Permission Profiles entwickelt, die per-path Filesystem Rules und proxied Network Domain Rules kombinieren, mit mid-session Switching, granular Approval Categories und einem optionalen Auto-reviewing Agent, laut der offiziellen Permissions Documentation und Approvals Documentation.

Was "turn-scoped" tatsächlich bedeutet

Die sauberste Definition, die ich habe: Die Menge der Dinge, die der Agent tun darf, ist an die Lebensdauer eines einzelnen Turns gebunden, wird beim Start des Turns captured und kann im Prinzip am Ende wieder released werden. Nicht an den User gebunden, der vielleicht eine Stunde weggeht, während der Agent arbeitet; nicht an die Machine, die viele Turns mit völlig unterschiedlichem Risk hostet; nicht einmal an die Session, die morgens Code reviewed und nachmittags Dependencies installiert.

Das Codex Issue am Anfang dieses Pieces ist der Beweis, dass der Snapshot real ist. Der laufende Turn "retains a permission or sandbox snapshot created when the turn starts", wie der Reporter formuliert, und der vorgeschlagene Fix ist Machinery, um eine neue Approval Policy, Sandbox Policy und Permission Profile in den aktiven Turn zu propagieren oder, wenn das nicht geht, intern pause-and-resume, damit der Turn unter frischen Permissions neu startet, ohne dass der User neu prompten muss. Liest man die Acceptance Criteria, sind sie eine Spec für turn-scoped Permissions als First-class Runtime Concept: Permissions mid-turn zu reduzieren muss neue violating Operations blockieren, sie zu erhöhen muss den Agent unblocked machen, und resumed, delegated und compacted Turns müssen den updated Context behalten.

Warum überhaupt Snapshot? Weil die Alternative schlechter ist. Wenn Permissions mutable Global State sind, dann hat alles, was diesen State beeinflussen kann, einschließlich Content, den der Agent liest, einen Lever darauf, was der Agent als Nächstes tun darf. Ein immutable-per-turn Snapshot bedeutet, dass die Permission Decision einmal von einem Human oder einer Policy in einem Moment klarer Intent getroffen wird und der Agent sich mid-flight nicht daran vorbeireden kann. Der Turn wird zur kleinsten Unit of Trust, was der tatsächlichen Agent Work entspricht: "review this diff" und "push to main" sollten niemals denselben Permission Context teilen, selbst wenn sie dieselbe Session teilen.

Codex bindet Permissions an einen Turn-start Snapshot: ein Issue vom Juli 2026 dokumentiert, dass Access Mode Changes mid-turn den laufenden Turn nicht beeinflussen, und schlägt vor, updated Approval Policy, Sandbox Policy und Permission Profiles in den aktiven Turn zu propagieren, wobei resumed und delegated Turns den neuen Context behalten.

Das Threat Model, das es beantwortet

Es lohnt sich, hier präzise zu sein, weil "Agent Security" viele vague Worries umfasst. Das Threat Model hinter turn-scoped Permissions hat drei benannte Actors, und keiner davon ist ein Hacker im Hoodie.

Prompt Injection ist die Headline Threat. Der Agent liest den ganzen Tag untrusted Content: Repositories, Web Pages, Issue Tickets, Tool Output. Alles davon kann Instructions tragen, die auf den Agent zielen. OpenAIs eigene Docs sind klar über die Consequences: Der Default Web Search Mode ist cached statt live, speziell um Injection Exposure zu reduzieren, und die Guidance warnt, dass Network Access einem injected Agent erlaubt, untrusted Instructions zu fetch und follow. Eine turn-scoped, network-off-by-default Sandbox capped, was eine erfolgreiche Injection in diesem Turn erreichen kann.

Drift und Over-reach ist die stille Threat. Ein capable Agent, der legitime Arbeit macht, wird trotzdem wandern: etwas installieren, Dependency fetchen, "helpfully" ein Directory aufräumen. Die Sandbox beantwortet das, ohne dass der Agent malicious sein muss, weshalb die Boundary vom OS enforced wird, Seatbelt auf macOS, bubblewrap plus seccomp auf Linux, native Sandbox auf Windows, und nicht vom guten Judgement des Models. Wo die Platform eine requested Policy nicht enforce kann, verweigert Codex den Command, statt ihn unsandboxed auszuführen. Fail closed, nicht fail hopeful.

Credential Exposure ist der Multiplier. Die Devcontainer Guidance der Docs spricht es aus: Führen Sie Codex mit Full Access in einem Container aus, kann ein malicious Project alles im Container exfiltrieren, einschließlich Codex Credentials. Darum sind die neueren Primitives so spezifisch bei Secrets: "**/*.env" = "deny" Globs, die Credential Files aus writable Workspaces herausschneiden, .git, .codex und .agents als read-only innerhalb writable Roots schützen, und ein Network Proxy, der local und private Destinations standardmäßig blockiert als DNS-rebinding Defence. Das ist dieselbe Shape wie die breitere Architecture Question in agentic AI architecture: Das Model proposes, das Harness disposes, und das Harness sollte die Secrets halten.

Codex' dokumentiertes Threat Model zentriert Prompt Injection, Network off by default und cached Web Search zur Reduktion hostile Live Content, Agent Drift, OS-enforced Sandboxes, die Commands verweigern, wenn sie die Policy nicht enforce können, und Credential Exposure, Deny Globs für .env, read-only .git und .codex, Blocking lokaler Networks, laut OpenAIs Security Documentation.

Wie die Implementation tatsächlich zusammenhängt

Drei Implementation Details sind es wert, für das eigene Runtime Thinking übernommen zu werden.

Deny schlägt Write schlägt Read, bei gleicher Specificity. Permission Profiles erlauben Broad Access zuerst und carve out Exceptions danach: Workspace writable, **/*.env denied, .devcontainer read-only. Specific Paths überschreiben breitere, und ein denied Subpath bleibt denied in einem writable Parent. Sie können sogar einen narrow Subtree in einem broad Deny wieder öffnen, ~/Documents denied, ~/Documents/codex writable. Das ist das richtige Precedence Model, weil Least Privilege dadurch additive zu Write wird statt subtractive from Memory.

Network Access und Network Filtering sind separate Switches. network.enabled = true lässt Commands das Network erreichen; features.network_proxy = true ist das, was Ihre Domain Rules tatsächlich durch einen Local Proxy enforced. Das eine ohne das andere gibt unrestricted Outbound Access mit falschem Governance Gefühl. Domain Rules sind allowlist-first, deny gewinnt, und localhost und Friends sind blocked, solange Sie sie nicht explicitly erlauben, denn ein sandboxed Agent mit Access auf lokale Daemons ist nicht sinnvoll sandboxed.

Das alte und neue System composieren nicht. Profiles und Legacy sandbox_mode Settings sind mutually exclusive; wenn irgendeine loaded Config sandbox_mode setzt, werden Profiles ignored. Enterprise Admins können das neue Model über eine managed allowed_permission_profiles Allowlist erzwingen, die auch omitted Built-ins denied. Wenn Sie eine Operational Lesson mitnehmen: Zwei Permission Systems, die "beide apply", sind der Weg dazu, zu glauben, man habe etwas denied, obwohl man es nicht hat. Wählen Sie eines, verify mit /permissions und /status, dann expand.

Für Teams, die Agents jenseits der CLI betreiben, generalisiert das Pattern. Snapshotten Sie einen Permission Context per Task, halten Sie Credentials in der Tool-execution Layer statt im Model Context, enforce unter dem Model und expire alles am Task End. Ob Sie das aus einer Vendor Runtime oder dem eigenen Harness bekommen, ist die Build-versus-buy Frage, und wenn Sie selbst betreiben, gelten die Self-hosted Agent Trade-offs mit mehr Knobs.

Codex Permission Profiles verwenden Deny-over-write-over-read Precedence mit Specificity Overrides, trennen Network Enablement von proxied Domain Enforcement und verweigern Composition mit Legacy Sandbox Settings, um Ambiguity zu vermeiden; Admins können Profiles über Managed Allowlists erzwingen, laut Permissions Documentation.

Was Sie jetzt tun sollten

1. Heute: Führen Sie /permissions und /status in Ihrer nächsten Codex Session aus und sehen Sie nach, was tatsächlich in Effect ist, nicht was Sie glauben. Wenn irgendeine Config Layer noch sandbox_mode setzt, haben Sie Permission Profiles still deaktiviert. Entscheiden Sie, welches System Sie nutzen.

2. Diese Woche: Schreiben Sie ein Custom Profile, das :workspace erweitert, **/*.env denied und nur die API Domains erlaubt, die Sie tatsächlich callen, mit network_proxy on. Testen Sie es mit codex debug, dem Sandbox Command, bevor Sie ihm vertrauen. Wenn Sie Third-party Code reviewen, pinnen Sie diese Projects auf ein von :read-only abgeleitetes Profile in ihrer Project Config.

3. Diesen Monat: Wenn Sie eine Agent Runtime bauen oder wrappen, übernehmen Sie den Turn als Permission Unit: Snapshot bei Turn Start, expire bei Turn End, Secrets außerhalb des Model Context halten und Enforcement fail closed machen. Schreiben Sie dann Ihre Antwort auf die offene Frage auf, die Codex selbst noch nicht fertig beantwortet hat: Was soll passieren, wenn Permissions mid-turn geändert werden? "Nothing until the next turn" ist safe, aber Users erwarten, dass die UI meint, was sie sagt.

FAQ

Was sind Turn-scoped Permissions?

Ein Permission Model, bei dem die Runtime eine Approval Policy, Sandbox Boundary und Filesystem/Network Rules beim Start eines Agent Turns captured und diesen Snapshot auf jeden Tool Call im Turn anwendet. Permissions sind Property der Unit of Work, nicht des Users, der Machine oder Session. Im Prinzip werden sie released, wenn der Turn endet, sodass Elevated Access nicht by default persistiert.

Wie unterscheidet sich das davon, den Agent einfach als Restricted OS User auszuführen?

OS Users sind machine-scoped und static: Jede Task, die der Agent ausführt, erbt dasselbe Blanket. Turn Scoping lässt "review this repo" read-only laufen, während "install dependencies and test" mit Workspace Writes und Domain Allowlist in derselben Session läuft, ohne Accounts zu wechseln. Es gibt Ihnen auch einen natürlichen Ort, Access zu expire, den OS Users nicht haben.

Kann Prompt Injection Codex' Permissions ändern?

Nicht innerhalb eines Turns, by design: Der laufende Turn führt gegen den beim Turn Start erzeugten Snapshot aus, und mid-turn Changes an Settings propagieren nicht hinein, das Behaviour aus Issue #32612. Residual Risks sind der nächste Turn und jede Surface, die das Profile bereits erlaubt, weshalb Network Access default off ist und sensitive Paths denied oder read-only sind.

Sind Permission Profiles stabil genug, um darauf zu bauen?

Sie sind explizit beta und composieren nicht mit den älteren sandbox_mode Settings, also behandeln Sie sie als Direction of Travel statt finished API. Die älteren Modes sind heute Stable Baseline. Für Team Rollout wählen Sie ein Model per Client Version, verify Behaviour mit /status und erwarten Sie, dass Profile Fields noch eine Weile weiterwandern.

Fazit

Agent Permissions wachsen auf wie Unix Permissions: von "root or nothing" hin zu fine-grained, least-privilege, auditable Boundaries, nur dass die Unit kein Process oder User ist, sondern ein Turn. Codex ist gerade die klarste Implementation zum Studieren, und sein roughest Edge, der immutable mid-turn Snapshot, ist zugleich der lehrreichste: Selbst die Reference Runtime verhandelt noch, wie dynamic eine Permission sein kann, bevor sie nichts mehr bedeutet. Wenn Sie Agents bauen oder betreiben, lernen Sie die Shape dieser Primitive jetzt. Jede ernsthafte Runtime wird innerhalb eines Jahres eine haben, und diejenigen, die Snapshot Semantics falsch machen, werden es öffentlich lernen.

Wenn Sie die Permission Layer für Ihre eigenen Agents designen und ein zweites Paar Augen möchten, ist das Arbeit, die ich mit Client Teams mache. Kontakt aufnehmen.

Quellen

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

• OpenAI Developers, "Agent approvals and security": https://developers.openai.com/codex/agent-approvals-security (abgerufen 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, abgerufen 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, abgerufen 2026-08-29)

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