⌥+⌃AltPlusCtrl

Claude Code Keyboard Shortcuts

Claude Code runs as a REPL inside whatever terminal you already use, so its interaction model borrows heavily from decades of shell conventions rather than inventing a new one from scratch — Ctrl+C to interrupt a running turn, arrow-key history, and Tab completion all behave close to what you'd expect from a normal shell session, layered underneath a set of interactions specific to steering an autonomous coding agent. The two mechanics that most distinguish Claude Code's keyboard model from a typical chat interface are the permission system governing when the agent is allowed to act without asking first, and slash commands, which let you invoke a fixed set of built-in operations (clearing context, checking cost, reviewing config) by typing a forward slash rather than describing the action in prose. Because Claude Code is explicitly designed to take actions in your real filesystem and shell — editing files, running tests, executing arbitrary commands — the keyboard interactions around approving, denying, and interrupting those actions carry more weight than the equivalent keystrokes in a plain chatbot, where the worst outcome of a bad response is wasted time rather than an unwanted file change or command execution. Shift+Tab is worth calling out early since it's the single most workflow-defining shortcut in the tool: it cycles the current permission mode between asking before each file edit or command, auto-accepting edits without individual prompts, and a read-only planning mode that restricts the agent to research and analysis before any code gets touched, and switching deliberately between these modes based on how much you trust the current task is close to the core skill of using Claude Code well.

Session Control

ActionWindowsMacDescription
Interrupt the current turnCtrl+CCtrl+CCuts off Claude mid-sentence or mid-tool-call the instant you see it heading somewhere wrong — in auto-accept mode this is your main brake, since edits and commands are applying without a confirmation prompt to catch them first, so noticing early and interrupting fast matters more here than in ask mode, where you'd normally get a chance to decline before anything runs.
Exit Claude CodeCtrl+C (twice) or Ctrl+DCtrl+C (twice) or Ctrl+DA second quick Ctrl+C, or Ctrl+D on an empty line, tears down the whole session rather than just the current turn — worth knowing that this discards the in-memory conversation unless you've been running with a session you can pick back up (see resuming below), so it's not the move if you're mid-task and just want to stop one runaway response.
Jump back to a previous point in the conversationEsc (twice)Esc (twice)Pressing Escape twice opens a view for rewinding to an earlier message in the current conversation and editing it, letting you correct an instruction from several turns back without needing to clear the whole session and restate everything that was still correct.
Resume a previous session from your shellclaude --continue (typed in shell before launch)claude --continueRelaunches Claude Code with the most recent session's conversation history restored, a shell-level flag rather than an in-session keystroke, useful for picking a task back up after closing your terminal without losing the context that had already been built up about the codebase and the task.

Permission Modes

ActionWindowsMacDescription
Cycle permission mode (ask / auto-accept / plan)Shift+TabShift+TabCycles the active session between requiring approval before each file edit or shell command, an auto-accept mode that applies edits without individually prompting, and a read-only plan mode where Claude can research and reason about a change but is restricted from actually writing files or running mutating commands until you switch out of it.

Slash Commands

ActionWindowsMacDescription
Open the slash command menu//Typing a forward slash at the start of the input line brings up the list of built-in commands (clearing context, reviewing cost, checking configuration, and others) as a discoverable menu rather than requiring you to already know a command's exact name.
Clear conversation context/clear/clearResets the conversation history for the current session, useful when pivoting to an unrelated task, since Claude Code's context otherwise keeps accumulating everything discussed so far, which can dilute or bias its reasoning on a genuinely separate piece of work.
Check session token usage and cost/cost/costReports the current session's accumulated token usage, a direct consequence of Claude Code billing by API token consumption rather than a flat per-session fee, and useful for noticing early if a particular task is consuming unusually large amounts of context.

Input Editing

ActionWindowsMacDescription
Recall previous inputUp ArrowUp ArrowWalks back through what you've already typed this session, which in practice gets used most for re-issuing a correction after Claude misread an instruction — rather than typing the whole thing again, pull up the original and edit just the part that was ambiguous.
Insert a newline without submittingShift+Enter or Backslash+EnterShift+Enter or Option+EnterAdds a line break inside the current prompt instead of submitting it, needed for multi-paragraph instructions or when pasting a multi-line error message you want Claude to read as one block rather than several separate submitted messages.
Tab-complete a file path referenceTabTabType @ followed by a few letters of a filename and this fills in the rest from the actual project tree, which matters most in a repo with several similarly-named files (three different `utils.ts` in different folders, say) where describing the file in words would leave Claude guessing which one you mean.

Frequently Asked Questions

What's the actual difference between plan mode and just asking Claude Code a question without letting it edit anything?

Plan mode is a session-wide state, not a one-off qualifier on a single message — while it's active, every request in that session is restricted to read-only research and analysis regardless of how it's phrased, so Claude can explore the codebase, form a plan, and explain it, but any tool call that would write a file or run a mutating shell command is blocked until you cycle out of plan mode with Shift+Tab. That's a stronger guarantee than just asking nicely in a single message, since it's enforced by the tool rather than relying on the model correctly interpreting an ambiguous request as read-only.

If I use auto-accept mode, can I still catch a bad edit before it causes real damage?

Auto-accept removes the per-edit confirmation prompt, but it doesn't remove your ability to review afterward — the files Claude touches are still ordinary files under your normal version control, so a git diff or git status immediately after a task gives you a fast way to see everything that changed in one pass. The practical safety net most experienced users rely on is committing (or at least staging) a clean baseline before starting an auto-accept session, so any unwanted change is trivially reversible rather than needing to be manually undone.

Does Ctrl+C during a long-running shell command Claude launched actually stop that command, or just Claude's turn?

It's intended to interrupt the current turn, which includes stopping a shell command Claude is actively waiting on — but because Claude Code executes real commands in your actual shell, a command that's already spawned background processes or written to a lock file may need the same cleanup a manually interrupted command would need outside of Claude Code entirely. Treat the interrupt as reliably stopping Claude's turn, and separately verify anything with side effects the way you'd verify after killing any long-running terminal command.

Why does typing @ before a filename matter instead of just naming the file in plain text?

Using @ followed by Tab-completion inserts a resolved, exact file reference into your prompt rather than leaving Claude to interpret a plain-text filename that might be ambiguous in a project with similarly named files across different directories. It's a small habit that removes an entire class of misunderstanding where Claude edits the wrong file of the same name, particularly relevant in monorepos or projects with repeated file names across separate modules.

Is there a way to undo the context clear from /clear if I did it by mistake?

Not directly — /clear wipes the active conversation's context for that session, and there isn't a built-in redo for the specific conversation history it discarded. If you anticipate needing to reference an earlier exchange again, it's worth copying anything genuinely important (a specific plan Claude proposed, a decision you both settled on) out into a comment, commit message, or scratch file before clearing, rather than assuming the conversation itself will remain retrievable.

Does Claude Code remember my permission mode choice the next time I start a session in the same project?

Permission mode is generally a per-session setting rather than something that permanently sticks to a project — each new session starts back in the default ask-before-acting mode, and you re-select plan or auto-accept mode again with Shift+Tab if you want it for that session specifically. This is a deliberate safety choice: it means a stale, forgotten auto-accept setting from a previous session never silently carries over into a new one.

Can I paste a multi-line error message directly into Claude Code without it submitting halfway through?

Yes — pasted multi-line text is generally handled as a block rather than triggering submission line-by-line the way manually typing and pressing Enter would, so pasting a full stack trace typically lands as one coherent multi-line prompt. If you're composing a multi-line message by typing rather than pasting, remember that plain Enter submits immediately, so use the newline modifier (Shift+Enter, or Option+Enter on Mac) between lines you're typing manually rather than pasting.

What happens to in-progress file edits if I force-quit my terminal instead of exiting Claude Code normally?

Any edit Claude had already written to disk before the terminal closed remains on disk exactly as written, since file writes happen as they occur rather than being buffered until a clean session exit — there's no in-memory-only state that gets lost by force-quitting mid-task the way an unsaved document in a GUI editor would be lost. What you do lose is the conversational context and any plan Claude hadn't yet acted on, so a force-quit mid-task is more of a lost-context problem than a lost-work problem, provided the actual file writes had already completed.

Is resuming a session with --continue the same as the earlier session never having ended?

Functionally close, but not identical — the restored conversation history gives Claude back the discussion and decisions that had already happened, which is usually enough to keep working without re-explaining the task from scratch. What it can't restore is any state that lived only in a now-closed shell process, such as an environment variable set earlier in that terminal session or a background process that was still running when the terminal closed, so a resumed session is best treated as picking up the conversation, not necessarily every piece of surrounding shell state that existed a moment before.