Inside the Harness: Turn-Scoped Permissions estão virando uma primitive de Agent Runtime

Há um issue no repository OpenAI Codex, filed em meados de julho, que diz mais sobre para onde agent runtimes caminham que muitos launch posts. Reporter percebeu que se você muda permission mode do Codex enquanto turn roda, running turn ignora. Mantém permissions com que começou, e nova setting só vale next turn. Aumente access mid-turn e agent segue blocked. Reduza mid-turn e, pior, UI diz restricted enquanto agent conserva powers originais por mais alguns minutos.

Behaviour não é bug no sentido óbvio. É borda visível de design decision virando padrão em agent runtimes: permissions são scoped ao turn, snapshotted quando começa, tratadas como property daquela unit of work, não user, machine ou session. Este piece explica primitive, threat model e como Codex, reference implementation atual, realmente a conecta.

Principais conclusões - Turn-scoped permissions significa runtime snapshot approval policy, sandbox policy e permission profile no início do turn, e every tool call executa contra snapshot. - Threat model não é malicious user. É capable agent seguindo hostile instructions, prompt injection, ou drift off-task com seus credentials na sua machine. - Codex implementa boundary em três dials independentes: approval policy, pergunta ou não; sandbox mode, o que commands tocam; permission profiles, fine-grained filesystem/network rules, enforced por OS, não model. - Enforcement vive abaixo model: Seatbelt macOS, bubblewrap plus seccomp Linux, sandbox dedicada Windows. Onde policy não pode enforce, Codex recusa command. - Frontier unresolved é mid-turn mutation: snapshot hoje immutable por vida do turn, safe e às vezes maddening.

O que aconteceu

No fim julho/início agosto, permission surface Codex cresceu de dois coarse settings para algo como policy engine, e docs alcançaram. Old model: dois dials em config.toml, sandbox_mode (read-only, workspace-write, danger-full-access) e approval_policy (untrusted, on-request, never). New model adiciona permission profiles, beta: named composable policies combinando filesystem rules (read, write, deny per path, deny wins) e network rules, domain allowlists enforced por local proxy. Três built-ins ship: :read-only, :workspace, :danger-full-access, que você estende.

Interaction model também ficou turn-native. /permissions troca modes dentro running session. Granular approval policy mantém certas prompt categories interactive, sandbox escalations, MCP elicitations, enquanto auto-reject outras, incluindo distinct request_permissions, agent pedindo mais access mid-task. Approvals podem route para automatic reviewer agent que screens exfiltration, credential probing, destructive actions antes de human ver, segundo OpenAI approvals/security docs.

Não é single announcement. É runtime construindo permission layer como operating systems construíram user accounts: reluctant, contato com realidade.

OpenAI Codex evoluiu de dois coarse settings, sandbox mode e approval policy, para named permission profiles com per-path filesystem rules e proxied network domain rules, mid-session switching, granular approval categories e optional auto-reviewing agent, segundo permissions docs e approvals docs.

O que "turn-scoped" realmente significa

Definição mais limpa: conjunto do que agent pode fazer fica vinculado ao lifetime de single turn, captured no início e releasable ao fim. Não user, que pode se afastar uma hora; não machine, que hospeda turns de riscos diferentes; nem session, que review code de manhã e instala dependencies depois.

Issue inicial prova snapshot real. Running turn "retains a permission or sandbox snapshot created when the turn starts", e fix proposto é machinery para propagar nova approval policy, sandbox policy, permission profile ao active turn ou internal pause-and-resume, reiniciando sob fresh permissions sem re-prompt. Acceptance criteria parecem spec: reducing permissions mid-turn bloqueia violating operations novas, raising unblock agent, resumed/delegated/compacted turns preservam updated context.

Por que snapshot? Alternativa pior. Mutable global permissions dão a qualquer content capaz de influenciar state um lever sobre next action. Immutable-per-turn snapshot faz permission decision uma vez, human/policy, clear intent, e agent não negocia mid-flight. Turn vira smallest unit of trust: "review this diff" e "push to main" não devem compartilhar permission context mesmo na mesma session.

Codex vincula permissions a turn-start snapshot: issue julho 2026 documenta que access mode changes mid-turn não afetam running turn e propõe propagar updated approval policy, sandbox policy e permission profiles ao active turn, mantendo context em resumed/delegated turns.

Threat model que responde

"Agent security" é amplo; aqui há três actors.

Prompt injection é headline threat. Agent lê untrusted content o dia todo: repos, web, issue tickets, tool output. Tudo pode carregar instructions. Docs OpenAI dizem default web search cached, não live, para reduzir injection exposure, e network access deixa injected agent fetch/follow untrusted instructions. Turn-scoped, network-off-by-default sandbox limita blast radius da injection naquele turn.

Drift e over-reach é silencioso. Capable agent legítimo ainda vagueia: instala coisa, fetch dependency, "helpfully" limpa directory. Sandbox responde sem malicious intent, por isso OS enforcement: Seatbelt macOS, bubblewrap+seccomp Linux, native Windows sandbox. Se platform não consegue enforce requested policy, Codex recusa command. Fail closed.

Credential exposure multiplica. Devcontainer guidance: Codex full access no container e malicious project pode exfiltrate tudo, inclusive credentials. Por isso "**/*.env" = "deny", .git, .codex, .agents read-only em writable roots, network proxy bloqueando local/private destinations contra DNS rebinding. Same architecture shape em agentic AI architecture: model proposes, harness disposes, harness segura secrets.

Threat model Codex centra prompt injection, network off/cache search, agent drift com OS-enforced sandbox, credential exposure com .env deny globs, read-only .git/.codex, local-network blocking, segundo security docs.

Como implementação se encaixa

Três details para copiar.

Deny ganha de write, write ganha de read, mesma specificity. Broad grant + exceptions: workspace writable, **/*.env denied, .devcontainer read-only. More specific paths override, denied child continua denied em writable parent. Pode reopen narrow subtree dentro broad deny. Right precedence para least privilege.

Network access/filtering separados. network.enabled = true permite network; features.network_proxy = true enforce domain rules. Um sem outro pode virar unrestricted outbound com false governance. Allowlists, deny wins, localhost blocked unless explicit.

Old/new não compõem. Profiles e legacy sandbox_mode mutually exclusive; any loaded sandbox_mode ignora profiles. Enterprise admins usam allowed_permission_profiles. Lesson: two permission systems "both apply" cria falso deny. Pick one, verify /permissions, /status.

Beyond CLI, generalize: permission context per task, credentials no tool layer, enforce below model, expire at task end. Vendor vs own harness é build versus buy; self-host implica self-hosted agent.

Codex profiles usam deny-over-write-over-read precedence, separam network enablement de proxied enforcement e não compõem legacy sandbox settings; admins podem enforce managed allowlists, segundo permissions docs.

O que fazer agora

1. Hoje: /permissions e /status, veja actual effective config. Se algum sandbox_mode, profiles silently off. Escolha system.

2. Esta semana: custom profile extends :workspace, deny **/*.env, allow only APIs usadas, network_proxy on. Test codex debug. Third-party code, pin :read-only derived profile.

3. Este mês: se build/wrap runtime, turn como permission unit: snapshot start, expire end, secrets outside model context, fail closed. Defina mid-turn mutation semantics. "Nothing until next turn" safe, mas UI precisa ser honesta.

FAQ

O que são turn-scoped permissions?

Runtime captura approval policy, sandbox boundary, filesystem/network rules no início do turn e aplica a every tool call. Permission property da unit of work, não user/machine/session. Elevated access expira por default ao fim.

Diferença de restricted OS user?

OS user machine-scoped/static, same blanket. Turn scoping permite review read-only e install/test com workspace write/domain allowlist na mesma session, e natural expiry.

Prompt injection pode mudar permissions?

Não within turn by design; snapshot fixed. Residual next turn e already-allowed surfaces. Network off e sensitive deny/read-only limitam.

Profiles são estáveis?

Beta, não compõem old sandbox_mode. Direction of travel, não finished API. Team rollout deve verify /status por client version.

Resumo

Agent permissions estão crescendo como Unix permissions, de "root or nothing" para least-privilege auditable boundaries, mas unit é turn. Codex é implementation mais clara agora, e immutable mid-turn snapshot mostra dificuldade real: dynamic demais e permission perde significado. Aprenda primitive agora; serious runtimes terão uma, e snapshot semantics erradas vão falhar publicamente.

Se está desenhando permission layer dos seus agents, trabalho assim com client teams. Entre em contato.

Fontes

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

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

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