Codex CLI v0.164 adds /presets and inline /permissions arguments for permission profiles
v0.164.0 stores reusable prompts in ten /presets slots and lets /permissions pick a permission profile as an argument. Plus credential masking and hardened sandbox checks.
Contents
Codex CLI v0.164.0 is the first release in a while with several genuine features. The two that matter are /presets and inline /permissions arguments.
The second is more than a typing shortcut. Behind it sits permission profiles, a beta mechanism that does not combine with the older sandbox_mode settings. Configure both without knowing that, and one of them is silently ignored.
KEY POINT
What this article covers
- What the ten
/presetsslots hold - How the permission profiles that
/permissionsselects are built - Why permission profiles and
sandbox_modecannot be used together
Ten preset slots for prompts
The release notes read: "Save reusable prompts and slash commands in ten numbered /presets slots, with a keyboard menu for quick access."
Reusable prompts and slash commands go into ten numbered slots, recalled from a keyboard menu. It gives the standing instructions you retype every session somewhere to live.
The other input-side addition is arguments for /model and /permissions: "Set model, reasoning effort, speed, and permission profiles directly with inline /model and /permissions arguments." Instead of opening a menu and choosing, you pass the value on the command.
/presets and /permissions are not in the official list
As of 2026-10-26, the official slash command list (28 entries) has no row for /presets or /permissions. That page does say "Available commands vary based on your environment and access", so availability may vary, but neither could be confirmed in the documentation. Nor is there any statement of where the preset slots are stored.
The permission profiles behind /permissions
The permission profiles that /permissions selects are a beta feature with their own documentation page: "A profile is a named policy that combines filesystem rules, which define what commands can read or write, with network rules, which define which destinations commands can reach."
Three profiles are built in.
| Profile | What it does |
|---|---|
:read-only | Keeps local command execution read-only |
:workspace | Allows writes inside the active workspace roots and system temp directories |
:danger-full-access | Removes local sandbox restrictions; only when that breadth is intended |
Define your own under [permissions.<name>] and select it with the top-level default_permissions key.
default_permissions = "project-edit"
[features]
network_proxy = true
[permissions.project-edit.workspace_roots]
"~/code/app" = true
"~/code/shared-lib" = true
[permissions.project-edit.filesystem]
":minimal" = "read"
[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
".devcontainer" = "read"
"**/*.env" = "deny"
[permissions.project-edit.network]
enabled = true
[permissions.project-edit.network.domains]
"api.openai.com" = "allow"
"*.github.com" = "allow"
"tracking.example.com" = "deny"The **/*.env deny line is the practically useful part: writes stay allowed inside the workspace while environment files are carved out.
network.enabled = true alone does not enforce domain rules
The documentation states: "A profile's network.enabled = true permits command network access, but it does not start the network proxy." To have the domain rules enforced, also set features.network_proxy = true in config.toml. Without an active proxy, those domain rules do not restrict direct network access.
Permission profiles and sandbox_mode do not mix
This is the part that catches people migrating. The documentation is explicit: "Permission profiles do not compose with the older sandbox settings. Configure either default_permissions and [permissions], or sandbox_mode / sandbox_workspace_write, but not both."
The resolution falls entirely to one side. If sandbox_mode appears anywhere in a loaded config file, if you pass --sandbox, or if the selected config profile sets sandbox_mode, Codex uses the older sandbox settings rather than default_permissions.
So a sandbox_mode line left over in ~/.codex/config.toml silently voids a permission profile you just wrote. Remove the old settings first. For the older model, see Combining approval_policy and sandbox_mode in Codex.
Credential masking and the other fixes
Two security changes landed. One is "Mask credentials during supported remote Bash commands and Zsh snapshot sessions", which covers custom provider credentials too. The other is "Hardened sandbox checks for case-variant metadata paths on macOS and replaceable symlinks used to locate executables."
Three fixes stand out:
- A failed compaction no longer leaves partial summaries in conversation history
- Resuming a session now finds compressed histories and restores saved thread settings
- Windows HTTPS and WebSocket connections handle proxy authentication challenges with the signed-in user's credentials
Beyond those, enterprise MCP connections can authenticate through Codex account grants or a dedicated sign-in, and the Amazon Bedrock setup wizard is now on by default. For the previous release, see Codex CLI v0.163 turns Daybreak back on by default.
Summary
/presetsstores reusable prompts and slash commands in ten numbered slots/modeland/permissionsnow accept their settings as inline arguments- The permission profiles
/permissionsselects are beta; the built-ins are:read-only,:workspaceand:danger-full-access - Permission profiles do not combine with
sandbox_mode; a leftoversandbox_modewins /presetsand/permissionscould not be confirmed in the official slash command list
FAQ
- What can /presets store?
- The release notes say: Save reusable prompts and slash commands in ten numbered /presets slots, with a keyboard menu for quick access.
- Can permission profiles and sandbox_mode be used together?
- No. The documentation says to configure one or the other. If sandbox_mode appears anywhere in your loaded config, Codex uses the older sandbox settings instead of default_permissions.
- Are /presets and /permissions in the official docs?
- As of 2026-10-26 neither appears in the official slash command list. The permission profile mechanism itself is documented on the Permissions page.
Primary sources
This article was drafted by AI from official documentation and reviewed by the site operator before publishing. Found a mistake? Let us know via the contact page.