default_permissions

Values

Value	What you get
:read-only	Codex reads files, writes nothing
:workspace	Writes inside workspace roots, reads elsewhere
:danger-full-access	No sandbox restrictions
"my-profile"	Custom, must match a [permissions.my-profile] table

There is no published default. The official guidance is to set it explicitly for predictable behavior.

Custom profiles take five fields: extends, description, filesystem, network, and workspace_roots. Filesystem rules map paths or globs to "read", "write", or "deny", with special tokens like :minimal and :workspace_roots. Network rules cover an enabled flag, per-domain allow/deny, unix sockets, and proxy settings.

This example is verbatim from the permissions docs:

default_permissions = "project-edit"

[permissions.project-edit]
description = "Project editing with OpenAI API access."
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

When to change it

1. You want the repo writable but .env files unreadable. Extend :workspace and add a "**/*.env" = "deny" filesystem rule, exactly like the snippet above.
2. A project needs network access to one or two APIs and nothing else. A custom profile with network.domains handles that; sandbox_mode never could at that granularity.
3. You’re still carrying sandbox_mode config from the older setup. Profiles replaced it, and the two don’t compose, so migrate rather than mixing.

Gotchas

The config reference is blunt about the big one: don’t combine default_permissions with sandbox_mode or [sandbox_workspace_write]. Configure one system or the other.

On Windows, #13574 reports apply_patch failing to add or update files under the sandboxed default permission on 0.108.0-alpha.8: exit code 1, empty output, no approval prompt (file deletes kept working, which made it harder to spot). Closed as completed on 2026-03-10, so update if you’re still on 0.108.0-alpha.8.

Codex Desktop has its own problem: #22553 shows it ignoring project-local default_permissions from .codex/config.toml while displaying “Custom (config.toml)” as selected. The same profile works when passed on the CLI with codex -c 'default_permissions="my-profile"'.

On extends: Codex rejects :danger-full-access parents, unknown parents, and inheritance cycles, and a child never inherits its parent’s description.

Related settings

• sandbox_mode: the older sandbox key this replaces; mutually exclusive with this one
• approval_policy: when Codex asks before acting; runs alongside whichever permission system you pick