The Forge · 7 min mission

Codex TUI: Personality, Themes & Speed Dials

Turn Codex’s catalogued-but-unexplained UI commands into real habits — personality, themes, Vim, keymaps, and the fast lane.

interfacecustomizationcodexFact-checked 2026-06-14
On this page

The Codex CLI reference lists these commands in a table and moves on. That is the right call for a reference — but it leaves the how and when unanswered, and these are exactly the commands you tune once and benefit from every session afterward. This guide is that missing layer: when to switch Codex's tone, which themes earn their keep, the real tradeoff of Vim mode, how to rebind a shortcut for good, and the two different levers that change how fast Codex feels.

/personality: set the tone, not the instructions

/personality picks a communication style for Codex's responses — styles framed as more concise, more explanatory, or more collaborative — without you editing a prompt or AGENTS.md. Reach for it situationally: terser output when you are iterating fast and just want the diff, more explanation when you are learning an unfamiliar codebase and want Codex to narrate its reasoning. The choice applies to the active session and you can change it again any time.

The trap is treating it as an instruction layer. It is not. /personality changes manner, not substance — it does not replace your standing project instructions in AGENTS.md, and it won't make Codex follow a convention you never wrote down. (There is also a persistent personality setting in config for when you want a default rather than a per-session choice.) For what Codex should do, use AGENTS.md; for how it talks, use /personality.

/theme, /vim, /keymap: the editing surface

/theme previews and persists a syntax-highlighting theme for the TUI — set it once when code blocks are hard to read against your terminal background, and it sticks. /vim toggles Vim mode in the composer, giving you modal normal/insert editing while you write prompts. The thing to understand is its scope: it changes how you edit text in the composer, not how Codex edits your files. If you live in Vim, it removes the friction of typing prompts in a plain line editor; if you don't, leave it off.

/keymap is the one that pays off long-term. It lets you inspect and remap TUI shortcuts and persists the binding to tui.keymap in config.toml, so a shortcut you fix stays fixed across sessions. Bindings are scoped by context — global, chat, composer, editor, vim_normal, pager, list, approval — and a context-specific binding beats the tui.keymap.global fallback. Reach for it when a default shortcut collides with your terminal or your muscle memory.

CommandTunesPersists?
/personalityResponse tone (concise / explanatory / collaborative)Session (or set a default in config)
/themeSyntax-highlighting paletteYes — saved and reused
/vimComposer editing mode (modal vs. default)Toggle for the session
/keymapTUI keyboard shortcuts, by contextYes — written to tui.keymap in config.toml
/fastThe model's Fast service tierPer thread, when the model offers one
The personalization dials, by what they tune and whether the change persists. Verified against the official Codex slash-command and config references.

The two speed dials: /fast and reasoning effort

"Make it faster" can mean two different things in Codex, and they are separate levers.

/fast toggles the current model's Fast service tier — turn it on or off, or check whether the thread is already on it. It is catalog-driven: if the active model doesn't advertise a Fast tier, /fast simply isn't shown, which is why it can be present on one model and absent on another. This is an infrastructure-side latency trade, not a change to how hard the model thinks.

Reasoning effort is the other lever — how much the model deliberates before answering. The documented, reliable way to change it is /model, which lets you choose the active model and its reasoning effort, when available. You may see practitioners mention Alt+, / Alt+. for nudging effort mid-session, but that binding is not in Codex's official keyboard-shortcut list [P] — treat it as build-dependent and use /model as the dependable path. Bump effort with /model when a task gets genuinely hard; drop it back for a fast mechanical edit.

/side, /status, /copy: small commands that keep flow

Three more that smooth a working session. /side (alias /btw) opens an ephemeral side conversation with its own transcript, separate from the parent thread — perfect for a quick aside ("what does this regex do?") that you don't want cluttering the main task's history or burning its context. While you're in the aside, the TUI keeps showing parent-thread status so you can tell whether the main task is still running. Two limits: you can't open a side conversation from inside another one, and it's unavailable during /review.

/status prints a one-shot snapshot of the session — the active model, the approval policy, the writable roots the sandbox allows, and how much context budget is left before compaction. It's the fast way to confirm "what am I actually running right now." /copy (or Ctrl+O) copies Codex's latest completed output — a response or a plan — to your clipboard without mouse-selecting across the terminal.

/side vs. /new — an aside or a fresh start

/side (alias /btw)

An ephemeral side thread with its own transcript. The parent task is paused, not lost — its status stays visible — and you return to it when the aside is done.

Use it for a quick tangent mid-task that shouldn’t pollute the main thread or spend its context.

/new

Starts a fresh conversation in the same session — a clean slate, no automatic path back to the previous thread’s context.

Use it when you’re genuinely moving on to unrelated work, not taking a temporary detour you’ll come back from.

Knowledge check

Codex keeps producing slightly-wrong solutions on a hard refactor, so you want it to deliberate more. You also want a quick aside to check an unrelated regex without losing your place. Which moves fit?

Reach the end and this star joins your charted sky.