OpenAI Codex CLI Keyboard Shortcuts
Codex CLI shares the broad category of terminal-native coding agent with Claude Code, but its specific approach to controlling how much unsupervised action the agent is allowed to take is built around approval modes selected largely through startup flags and in-session configuration rather than a single always-available mode-cycling keystroke — the practical result is that Codex CLI users tend to decide their risk tolerance for a session more deliberately up front, choosing between suggestion-only behavior, auto-editing with command approval, or fuller autonomy, rather than toggling freely mid-session the way Claude Code's Shift+Tab is designed for. Session mechanics that Codex CLI does share with the wider terminal-agent category — Ctrl+C to interrupt a response or running command, arrow-key recall of prior input, and Tab completion for file references — behave close to standard shell conventions, which is unsurprising given both tools are explicitly designed to feel at home inside a terminal a developer already knows rather than requiring a separate learned interface. Codex CLI's image-input handling is a genuine point of difference worth knowing about: it accepts pasted or referenced screenshots as part of a prompt, useful for describing a UI bug or showing a rendered error rather than only describing it in text, a capability not universal across every terminal coding agent. As with any agent capable of executing real shell commands against your actual filesystem, understanding exactly what a given approval mode does and doesn't require confirmation for matters more than memorizing any single keystroke — the interrupt key is your emergency stop, but the approval-mode decision made at the start of a session is what determines how often you'll need to reach for it.
Session Control
| Action | Windows | Mac | Description |
|---|---|---|---|
| Interrupt the current response or command | Ctrl+C | Ctrl+C | Sends the standard interrupt signal to stop Codex CLI's current output or a command it's actively running, the same universal shell interrupt used across terminal tools, without necessarily ending the whole session on a single press. |
| Exit the session | Ctrl+C (repeated) or Ctrl+D | Ctrl+C (repeated) or Ctrl+D | Repeating the interrupt signal, or pressing Ctrl+D on an empty prompt line, closes the Codex CLI session and returns you to your regular shell, distinct from a single interrupt which only halts the current in-progress action. |
Approval Modes
| Action | Windows | Mac | Description |
|---|---|---|---|
| Set approval mode for the session | --approval-mode flag at launch | --approval-mode flag at launch | Codex CLI's autonomy level — ranging from suggestion-only output you manually apply, to auto-editing files while still confirming shell commands, to a fuller autonomous mode — is primarily selected via a startup flag or persistent config setting rather than a single in-session toggle keystroke, meaning the risk-tolerance decision for a session is typically made deliberately before you start working rather than adjusted freely mid-task. |
| Approve a pending shell command | Y then Enter | Y then Enter | In approval modes that still require confirmation before executing a shell command, responding to the prompt with a yes-style confirmation lets that specific command run; declining leaves it unexecuted and returns control to you to give further instructions. |
| Decline a pending shell command | N then Enter | N then Enter | Refuses a shell command Codex is asking to run in an approval mode that still requires confirmation, returning control to you within the same session so you can redirect the request, ask for a different command, or explain what specifically was wrong with the one it proposed. |
| Persist approval mode preference across sessions | edit config.toml (no in-session keystroke) | edit config.toml | Rather than re-passing the same launch flag every time, a preferred default approval mode can be set once in Codex CLI's own configuration file, so future sessions start with your chosen risk tolerance without needing to remember and retype the flag on every invocation. |
Input Editing
| Action | Windows | Mac | Description |
|---|---|---|---|
| Recall previous prompt | Up Arrow | Up Arrow | Steps backward through prompts already sent in the current session, the same convention used by shell history recall, useful for reissuing a similar instruction with a small correction rather than retyping it in full. |
| Insert a newline without submitting | Shift+Enter | Shift+Enter | Adds a line break within the current prompt rather than sending it immediately, necessary for composing a multi-line instruction or pasting multi-line content you want treated as one submitted block instead of firing on the first line break. |
| Tab-complete a referenced file path | Tab | Tab | Completes a partially typed file path when pointing Codex CLI at a specific file in your prompt, reducing ambiguity in projects that have similarly named files nested in different directories. |
| Attach a screenshot or image to a prompt | Ctrl+V (in supporting terminals) | Cmd+V (in supporting terminals) | Codex CLI can accept an image as part of a prompt — a screenshot of a rendering bug or an error dialog, for example — letting you show rather than only describe a visual problem, though actual paste behavior depends on your specific terminal emulator's own clipboard-image support rather than being a Codex-specific universal binding. |
Frequently Asked Questions
How does Codex CLI's approval mode actually differ from Claude Code's permission mode toggle?
Both tools solve the same underlying problem — deciding how much unsupervised action an agent can take against a real filesystem and shell — but they expose that choice differently. Claude Code makes it a single always-available keystroke (Shift+Tab) meant to be cycled through freely as trust in a given task changes mid-session, while Codex CLI's approval mode is more commonly set once via a launch flag or persistent configuration, reflecting a workflow where you decide your risk tolerance for a session up front rather than adjusting it moment to moment as you go.
If I decline a pending shell command, does Codex CLI just stop entirely?
No — declining a specific command confirmation typically returns control to you within the same ongoing session rather than ending it, giving you the chance to explain why, redirect the approach, or ask for a different command instead. The session and its context remain intact; only that one proposed action is blocked from executing.
Can I really paste a screenshot into Codex CLI, or does that depend on my terminal?
Image input is a genuine Codex CLI capability, but whether pasting actually works depends on your terminal emulator's own support for transmitting clipboard images to a running CLI program — some modern terminal emulators handle this natively, while others don't support image paste into a terminal session at all regardless of what the program running inside expects. If a direct paste doesn't work in your setup, referencing an image file by path is typically the fallback.
Why would I choose suggestion-only mode instead of letting Codex CLI just make the edit directly?
Suggestion-only mode is useful specifically when you want to review every proposed change before it touches a file at all, rather than reviewing it after the fact via a git diff — valuable on unfamiliar codebases, when working against production-adjacent branches, or simply while you're still building trust in how a particular agent behaves on your specific codebase's conventions before granting it more direct editing autonomy.
Does Ctrl+C during a running shell command Codex launched actually kill that underlying process?
It's intended to interrupt Codex CLI's current turn, including a command it's actively waiting on, but because that command executes as a real process in your actual shell environment, anything with side effects already underway (a partially written file, a spawned background process) may need the same manual cleanup you'd apply after interrupting any long-running terminal command outside of Codex CLI entirely.
Is Codex CLI's history recall (Up Arrow) shared with my shell's own command history, or separate?
It's a separate history specific to prompts sent within the current Codex CLI session, not your underlying shell's own command history — exiting Codex CLI and returning to a plain shell prompt won't have your Codex prompts mixed into that shell's own Up Arrow recall, and vice versa.
What happens to files Codex CLI already edited if I interrupt it mid-task?
Any file write that had already completed before the interrupt remains on disk exactly as written — interrupting stops further action but doesn't retroactively undo completed writes. The safest habit is the same one that applies to any agent capable of direct file edits: start from a clean git status so an interrupted, partially completed task is trivially diffable and revertible rather than needing to be manually reconstructed.
Can I run Codex CLI against a repository without giving it any shell command execution ability at all?
Yes — the more conservative approval modes are specifically designed for this, restricting Codex to proposing edits (or even just suggestions you apply yourself) without directly executing arbitrary shell commands, which is a meaningfully different risk profile than a fuller-autonomy mode where it can run tests, install dependencies, or execute other commands as part of completing a task on its own.
Is it worth setting a default approval mode in config rather than passing the flag each time?
For a repository you work in regularly and already trust, yes — persisting a default in config.toml removes the friction of remembering and retyping a launch flag every session, and reduces the temptation to reach for a more permissive mode than you actually intended just because it happened to be the last flag you typed. Many users still keep the flag available for one-off exceptions, such as intentionally launching a single session in a more conservative mode when working against an unfamiliar or higher-stakes part of the codebase, without needing to permanently change the stored default.
What's a practical workflow for using Codex CLI safely on a task you're not fully confident about?
A pattern that works well in practice: start the session in a more conservative approval mode so proposed edits and commands require your explicit confirmation, let Codex work through the task with you approving each meaningful step, and only switch to a more autonomous mode for a follow-up session once you've seen enough of its proposed changes on that specific codebase to trust its judgment there. Treating trust as something earned per codebase, rather than a single global setting you configure once and forget, catches more mistakes early without meaningfully slowing down routine, already-trusted work.