Codex CLI 0.164: Preset Slots and Inline Model Parameter Parsing

OpenAI's Codex CLI introduces a batch of workflow-efficiency improvements in version 0.164.0: ten /presets preset slots, inline parameter support for /model and /permissions, and credential masking for remote commands. These changes may look scattered, but they all point to one goal—making the AI coding assistant on the command line feel more like a "configurable development environment" than a one-off chat tool.

Preset Slots: Locking In Frequently Used Configurations

/presets provides ten configurable, nameable slots. Previously, whenever users switched models or adjusted permission policies, they often had to retype the full command or rely on external scripts; now a set of parameters can be saved as a preset and quickly invoked by slot.

The value of this design lies in reducing context-switching costs. For example, a team might maintain three usage modes at once—"quick completion," "deep refactoring," and "read-only review"—each corresponding to a different model and permission combination. Preset slots turn these modes into reusable commands instead of long strings of parameters scattered across shell history. The limit of ten slots also indicates that the official positioning is lightweight configuration, not a complete configuration-file system.

Inline Parameters: /model and /permissions Take Arguments Directly

Version 0.164 allows parameters to be attached directly when invoking /model and /permissions, eliminating a second round of interaction. For users who prefer scripted operations, this means model selection and permission settings can be written into a single command, making them easier to reuse in CI or automation flows.

Inline permissions deserve particular attention. Codex CLI involves file reads and writes and command execution, so permission boundaries are a sensitive point in practical use. Writing permission parameters explicitly in the command is easier to audit than relying on defaults or interactive confirmation—the command history itself becomes a record of permission changes.

Slash Command is a conventional instruction form in interactive CLIs, beginning with / and parsed by the CLI itself rather than handed off to the underlying shell. Unlike ordinary shell commands, slash commands usually take effect within an interactive session and can read and modify session state (such as the current model or permission policy). Before 0.164, /model and /permissions were mostly invoked without arguments, entering a submenu or follow-up selection after execution; inline parameters merge parameter parsing into the same instruction, essentially compressing "command + interactive response" into a single idempotent call. This also explains its significance for scripting: argument-free commands depend on TTY interaction and are hard to reuse in pipelines or CI, whereas the inline form can deterministically complete configuration switches non-interactively, with exit codes and output that are easier for upstream tools to parse.

Credential Masking: A Security Patch for Remote Commands

In remote command scenarios, version 0.164 adds credential masking. When command output or logs may contain sensitive information, this mechanism masks it.

This change targets a risk surface common to AI coding tools: when the CLI performs remote operations, tokens, keys, and other credentials may leak into logs or terminal echo through output streams. Masking cannot replace the principle of least privilege, but as a default line of defense it reduces the probability of accidental exposure. The official guidance asks users to check workflows that depend on remote commands after upgrading to confirm that masking behavior matches expectations.

Credential Masking follows the same idea as common log redaction: before data leaves the process boundary, sensitive substrings are identified through pattern matching or known key fingerprints and replaced with placeholders such as ***. It differs from "credential encryption" (encryption in transit or at rest) and "credential isolation" (not putting keys into environment variables or command lines) in that it is a fallback measure on the output side. A typical implementation maintains a set of regex or entropy-detection rules covering API keys, Bearer tokens, private key blocks, and similar forms, and filters them uniformly across stdout/stderr, debug logs, and error traces. Its limitation is that masking happens after the fact: if a key has already been written to a remote logging system or leaked through side effects, the damage cannot be undone; at the same time, overly aggressive rules may inadvertently affect normal output. For this reason, the industry generally treats it as one layer of defense in depth, to be combined with least privilege, short-lived tokens, key rotation, and other measures.

Upgrade Recommendations and Checklist

This update is a feature-enhancement release with no mention of breaking changes, but several points are worth verifying after upgrading: where preset slots are persisted and how they are shared across a team, compatibility of inline parameters with existing scripts, and the coverage of masking in remote command output. For teams using Codex CLI in automated pipelines, it is advisable to first verify the actual behavior of inline permission parameters in a non-critical environment before rolling them out to the main workflow.

Overall, the direction of 0.164's improvements runs along two parallel tracks: "configurability" and "security." Presets and inline parameters address efficiency, while credential masking fills a security gap. For users who treat Codex CLI as a daily development tool, these changes are worth taking the time to rethink their own command habits.

Additional Background

The difference between a preset and a configuration file is worth clarifying. A preset slot usually refers to a small set of named parameters persisted inside the application, at a coarser granularity and aimed at quick session-level switching; a configuration file (such as TOML/YAML) supports layered overrides, environment variable interpolation, and merging of project-level and user-level settings, making it suitable for carrying complex configurations that need version management. The limit of ten slots suggests that presets take a "hotkey-style" lightweight path, and their persistence location is most likely the user configuration directory rather than the project repository—which means team sharing requires additional measures (export, sync, or documentation). Understanding this boundary helps determine which configurations should be locked into presets and which should still be left to configuration files or environment variables, avoiding the loss of traceability that comes from stuffing team collaboration conventions into personal slots.

One-line Summary

Codex CLI 0.164 adds preset slots, inline model and permission parameters, and credential masking, improving configurability and security.

Paragraph Summary

Codex CLI 0.164.0 introduces three improvements centered on workflow efficiency and security: first, /presets provides ten nameable configuration slots that lock common model and permission combinations into reusable commands, reducing context-switching costs; second, /model and /permissions support inline parameters, eliminating a second round of interaction and making them easier to script and reuse in CI, while explicit permissions written into command history are easier to audit; third, remote commands gain credential masking that obscures tokens and keys in output and logs, reducing leak risk. The article argues that these changes collectively point toward a "configurable development environment" and recommends verifying preset persistence, inline parameter compatibility, and masking coverage after upgrading.