I’ve been running Claude Code as my main coding tool for most of the past year. Most of the work I do at RightBlogger and on the small product sites I run goes through it at some point. There are 111 commands as I write this, but the actual list I touch in a given week is much smaller.
This is that list, plus an honest section on --dangerously-skip-permissions, which is the flag everyone wants to know about and almost nobody uses correctly.
How commands work in Claude Code
Inside a session, type / to see every command available, or type / followed by a few letters to filter. A command is only recognized at the very start of your message; anything after the command name is passed as arguments.
Two things to know up front. First, slash commands and skills now use the same system. The official commands reference splits them into “built-in commands” (behavior coded into the CLI, like /clear and /model) and “bundled skills” (prompt-driven, like /simplify and /debug), but you invoke both the same way. If you put a file at .claude/commands/deploy.md or a skill at .claude/skills/deploy/SKILL.md, both create /deploy.
Second, not every command shows up for every user. Availability depends on your plan, OS, and environment. /desktop only shows on macOS and Windows when you’re signed in with a Claude subscription. /upgrade doesn’t show on Enterprise plans. If a command in this post isn’t there for you, that’s why.
Everything below is from the official commands reference and the permissions docs, tested against Claude Code 2.1.261. Last checked September 4, 2026.
The ones I run constantly
These are the ten or so commands that earn their muscle memory.
Context management: /clear, /compact, /context
/clear starts a new conversation with an empty context. The previous one stays available in /resume. Pass an optional name (/clear notes) to label the previous conversation in the resume picker so it’s easier to find later. Aliases: /reset, /new.
/compact [instructions] is different. It keeps the same conversation but summarizes it to free up context. Pass focus instructions if you want the summary biased toward something specific. Use this when you’re mid-task and the context bar is getting hot.
/context shows current context usage as a colored grid, with suggestions for what’s eating the most. I use it whenever a session starts feeling sluggish to figure out which tool or memory file is bloating things.
Sessions: /resume, /branch, /rewind
/resume [session] (alias /continue) jumps back into a previous conversation. With no argument, it opens a picker.
/branch [name] creates a branch of the current conversation at this point and switches you into it. You can explore one approach, then /resume back to the original and try a different one without losing either. Note that /fork used to be an alias for this and no longer is: as of v2.1.212 it copies the conversation into a separate background session instead. More on that below.
/rewind is checkpointing. Roll back the conversation, the code, or both, to a previous point, or summarize from a selected message. Aliases: /checkpoint, /undo. This one feels weird the first time and indispensable after.
Models and effort: /model, /effort
/model [model] switches the model for the session. With no argument, it opens a picker.
/effort [level] controls how much reasoning the model uses. Accepts low, medium, high, xhigh, max, or ultracode. max and ultracode are session-only, and the available levels depend on the model you’re on. ultracode is a Claude Code setting that pairs xhigh reasoning with automatic workflow orchestration. Run with no argument to get an interactive slider, or /effort status to just print the current level. One wrinkle: max and ultracode are session-only, but the ultracode setting itself persists. Both of these take effect immediately, without waiting for the current response to finish, which is the kind of small detail you only appreciate after living without it.
Diffs and reviews: /diff, /code-review, /security-review
/diff reviews the changes in your working tree, including the edits Claude has made so far. This is what I use to actually read what just happened before I trust it.
/code-review is the one that matters now, and it took over the job the old /review used to do. It reviews the current diff for correctness bugs and cleanup opportunities, and takes an effort level as the first argument: /code-review low through max, plus ultra for a deep multi-agent review in a cloud sandbox. You can also point it at a target instead of the working tree: a PR number, a branch, or a path. Add --fix to apply what it finds, or --comment to post the findings as inline GitHub PR comments. On an ultra run against a GitHub PR, --post preselects posting the finished findings back to the PR. The ultra tier includes 3 free runs on Pro and Max before it starts drawing usage credits, and it isn’t something Claude can launch on its own.
/review is worth a warning if you read an older version of this post, mine included. It has changed meaning twice. It used to be the local review command, then briefly became a fast single-pass read-only PR review, and as of v2.1.223 it is simply an alias of /code-review with the same effort levels and flags. So /review 1234 and /code-review 1234 now do the same thing. One quirk: with no level given, it reuses the last low through max level you typed.
/security-review analyzes the changes on your current branch for things like injection, auth issues, and data exposure. Specifically it diffs your branch against origin’s default branch, which means it needs an origin remote: if it fails with an ambiguous argument error, that’s why. Worth running before any PR that touches request handling.
File access: /permissions, /add-dir
/permissions (alias /allowed-tools) opens an interactive dialog for managing allow, ask, and deny rules. You can view rules by scope, add or remove them, and review recent auto-mode denials. This is the single command most worth learning if you want to stop being prompted for the same Bash variations forty times a day.
/add-dir <path> adds a working directory for file access during the current session. Worth knowing: most .claude/ configuration in the added directory is not loaded as configuration, just as files. The exceptions are skills in .claude/skills/, which do get picked up with live reload.
The ones worth knowing exist
These don’t earn daily slots, but they’re the ones I reach for when the situation calls for them.
/initinitializes a project with aCLAUDE.mdguide. SetCLAUDE_CODE_NEW_INIT=1for an interactive flow that also walks through skills, hooks, and personal memory files./memoryeditsCLAUDE.mdfiles, enables or disables auto-memory, and views auto-memory entries./agentsused to open an interactive manager for subagents. As of v2.1.198 it just prints a reminder to ask Claude to create or manage them for you, or to edit.claude/agents/and~/.claude/agents/yourself. Mildly annoying if you had muscle memory for the old UI./plan [description]enters plan mode directly from the prompt. Pass a description to start with that task immediately, like/plan fix the auth bug./goal [condition]is a newer one I’ve been enjoying. Set a condition (“all tests pass,” “every endpoint returns 401 for unauthenticated requests,” “no TypeScript errors”) and Claude keeps working across turns until it’s met. With no argument, it shows the current or most recently achieved goal. Passclear,stop,off,reset,none, orcancelto drop an active goal early. What I like about it is the simplicity: it just keeps working until the thing you asked for is done./simplify [target]is a bundled skill that reviews recently changed files for reuse, simplification, efficiency, and whether the change sits at the right level of abstraction, then applies the fixes. Four review agents run in parallel and their findings get aggregated./debug [description]enables debug logging for the current session and troubleshoots issues by reading the session debug log. Worth knowing that debug logging is off by default unless you started withclaude --debug, so running/debugmid-session captures logs from that point forward, not earlier./loop [interval] [prompt]runs a prompt repeatedly while the session stays open. Omit the interval and Claude self-paces. Example:/loop 5m check if the deploy finished./schedule [description](alias/routines) creates, updates, lists, or runs routines, which execute in the cloud. You can also ask it about a routine’s recent runs. Useful for the “remind me to clean up that feature flag in two weeks” pattern./usage(aliases/cost,/stats) shows session cost, plan usage limits, and activity stats. On Pro, Max, Team, or Enterprise plans, it also breaks down usage by skill, subagent, plugin, and MCP server./export [filename]exports the current conversation as plain text. With a filename, writes directly; without, opens a copy/save dialog./copy [N]copies the last assistant response to the clipboard. PassNto copy the Nth latest. With code blocks present, you get an interactive picker. Presswin the picker to write the selection to a file instead, which is genuinely useful over SSH./mcpmanages MCP server connections and OAuth./pluginmanages plugins./reload-pluginsreloads all active plugins to apply pending changes without restarting./doctorgot a real promotion. It’s now a bundled skill that runs a full setup checkup and offers to fix what it finds: duplicate installs,PATHproblems, unparseable settings, slow hooks, and skills or MCP servers or plugins you’re paying context for and never using. It’ll also dedupe and trim yourCLAUDE.mdfiles, cutting the parts Claude could work out from the codebase anyway and moving what’s left into skills that load on demand. It reports first and asks before changing anything. Worth running once on any project you’ve had for a while./insightsgenerates an HTML report on your recent sessions on this machine: which projects you work in, how you use Claude Code, where things go wrong. Not available in cloud sessions./cd <path>moves the session to a different working directory without losing the conversation. It appends the new directory’sCLAUDE.mdas a message rather than rebuilding the system prompt, so the prompt cache survives the move. Useful in a monorepo when you finish in one package and want to keep going in another./advisor [model]turns on a second model that gets consulted at key moments during a task. Acceptsfable,opus,sonnet, or a full model ID. Fable was explicitly rejected as an advisor when this landed and is now allowed if you have access to it. It’s a second opinion on the hard calls rather than a second worker./verifyand/runare a pair worth knowing if you’ve ever had a change pass every test and still not work./runlaunches and drives your project’s app;/verifyconfirms a change does what it should by actually building and running it instead of trusting tests and type checks./reload-skillsre-scans your skill and command directories so anything you added or edited mid-session becomes available without a restart./config key=valuesets a setting without opening the settings UI, like/config theme=darkor/config thinking=false. Run/config --helpto list every key./autocompact [auto|<tokens>]sets how full the context window gets before Claude Code compacts on its own. Pass a size like500k, orautoto go back to the default for your model. It saves to user settings and applies to the current session, so it’s the one to reach for if auto-compact keeps firing earlier than you want./import [codex|gemini]brings configuration over from OpenAI Codex or Gemini CLI: instruction files, MCP servers, commands, subagents, and skills.--dry-runpreviews without writing./initnow offers this automatically if it spots config from either one./rate-limit-optionsshows your options when a usage limit blocks a request: wait for the reset and continue automatically, add usage credits, or upgrade. Claude Code will open this on its own when you hit a limit./artifactslists artifacts you own or that are shared with you, then lets you attach one to the session, open it in a browser, or copy its link.
Running things in parallel
This is the cluster that changed most since I first wrote this post, and the naming is genuinely confusing, so it’s worth laying out side by side. Four commands, four different shapes of “do this somewhere else.”
/branch [name]copies the conversation and switches you into the copy. You’re now working in the branch; the original waits in/resume./fork [prompt]copies the conversation and leaves you where you are. The copy runs as its own background session with everything up to this point, and the two are independent from then on. Pass a prompt and it starts on it immediately./subtask <task>hands a side task to a subagent that inherits the full conversation, works in the background, and reports its result back into this conversation when it’s done. This is the one you want for “go check that while I keep going.”/background [prompt](alias/bg) detaches this session to keep running without you and frees the terminal. Monitor it withclaude agents.
The short version: /branch to change your own direction, /fork to spin off an independent copy, /subtask to delegate and get an answer back, /background to walk away from a long job.
If you’re running any of these, /workflows opens the progress view where you can watch, pause, resume, or save what’s running, and /tasks lists background work in the current session, including subagents that have already finished.
One caveat on /fork and /subtask: they only behave this way on v2.1.212 and later. Between v2.1.161 and v2.1.211, /fork was the forked-subagent command and /subtask didn’t exist. Before that, /fork was just an alias for /branch. Check your version before assuming.
The dangerous one
Now the section everyone scrolls to: --dangerously-skip-permissions.
This is a CLI flag, not a slash command. You start a session with it:
claude --dangerously-skip-permissionsIt puts the session in bypassPermissions permission mode, which skips almost all the per-tool approval prompts. No more “Allow Bash to run npm install?” No more accept-edit dialog. Claude just goes.
There’s also a related flag, --allow-dangerously-skip-permissions, that doesn’t enable bypass mode but allows it as an option (so you can flip into it with --permission-mode bypassPermissions later). Anthropic recommends the latter only for sandboxes with no internet access.
What it actually skips
According to the permissions documentation, bypassPermissions mode skips permission prompts including writes to what the docs call protected paths. Those are the directories .git, .config/git, .claude (except .claude/worktrees), .vscode, .idea, .husky, .cargo, .devcontainer, .yarn, and .mvn.
There is now a protected files list too, and it’s the one that should make you pause: .gitconfig, .gitmodules, and your shell startup files, meaning .bashrc, .bash_profile, .zshrc, .zprofile, .zshenv, .profile, .envrc, and friends. In every normal mode a write to any of those prompts. In bypass mode it doesn’t. A model edit to your .zshrc is a model edit to every shell you open afterward.
Worth knowing separately: permissions.allow rules do not pre-approve protected-path writes even outside bypass mode. The safety check runs before allow rules are evaluated, so an Edit(.claude/**) entry in your settings changes nothing.
That means if you’re running this in a real project, Claude can rewrite your local git history, edit your editor settings, modify your husky hooks, and overwrite your own .claude/ config without asking. None of those will trigger a prompt.
What it doesn’t skip
More than I originally gave it credit for. “Skips all prompts” was never quite right, and the docs are clearer about it now. Explicit ask rules you’ve written still prompt. So do connector tools your organization set to ask, the built-in AskUserQuestion tool, and MCP tools marked requiresUserInteraction. The cross-session messaging safeguards hold too, so a message to your sessions on another machine still asks. Bypass mode overrides the defaults, not your deliberate guardrails.
Then there’s the circuit breaker, and it has been hardened since I first wrote this. rm and rmdir removals targeting a critical path, like rm -rf / or rm -rf ~, still prompt in bypass mode. Outside it they are denied outright, and no permissions.allow rule and no PreToolUse hook returning "allow" can approve one. The docs frame this as a guard against model error, not user error. So you’re not going to wipe your machine in a single tool call without seeing a dialog first.
It also got smarter about hiding places. It catches the removal inside command substitution with $(...) or backticks, or process substitution with <(...), whether the removal sits inside the substitution or elsewhere in the same command. It also treats a glob directly under a shell variable, like rm -rf "$DIR"/*, as a critical-path removal, on the reasoning that an empty variable turns that into a removal from the filesystem root. That is a genuinely good catch and not one I would have thought of.
Hooks are also still respected in the blocking direction. A PreToolUse hook that exits with code 2 still blocks the call. It just can’t be used to wave through a critical-path removal.
Two more guardrails worth knowing before you reach for this. You can’t switch into bypass mode from a session you started without it, so it has to be enabled at launch, either with the flag or with permissions.defaultMode. And on macOS and Linux, Claude Code refuses to start in this mode as root or under sudo.
The first interactive session you start with it shows a one-time dialog asking you to accept responsibility for what happens without permission checks. Accept it and it’s saved to user settings and never shown again. Decline and Claude Code exits. Non-interactive sessions show no dialog at all, and a background session started with --bg is refused until you’ve accepted it somewhere interactive.
When I actually use it
My honest take: with a strong model like Claude Opus 5, this flag is more usable than its name implies. Opus is unlikely to wander off and do something catastrophic on its own. I do run sessions with bypass mode on for routine work where I’m watching what’s happening, and the friction reduction is real.
The risk isn’t the model freelancing. The risk is one bad prompt from you. Ask Claude to “clean up that directory” ambiguously, drop bypass on, and you can lose work. Tell it to “reset the database” without specifying which one, and it’ll happily run the destructive command against whatever connection your local env is pointed at. Worst case, a single typo or unclear instruction in a bypass session can delete files you care about, drop a database, or do something genuinely worse if the session has access to production credentials. The flag removes the safety net that would have caught any of that.
So a better framing than “never use it” is: use it with a strong model, in a project where you’ve thought about the blast radius, and only after you trust yourself to write prompts that are unambiguous about destructive operations. The rules I run with:
- Don’t run bypass mode in a directory holding uncommitted work I’d hate to lose.
- Don’t run bypass mode in any session that has access to a production database, S3 bucket, or live API key.
- Never paste a prompt I haven’t read carefully into a bypass session.
- Anthropic’s own recommendation, “isolated environments like containers or VMs where Claude Code cannot cause damage,” is still the safest bar to hit when the project allows it.
If those constraints don’t fit a particular project, the lower-risk paths below get you most of the friction reduction without the full liability:
/permissionsto allow specific commands you trust. Spend ten minutes setting upBash(npm run *),Bash(git status *),Bash(jest *), and the prompts go away.- The
/fewer-permission-promptsskill, which scans your transcripts for common read-only Bash and MCP calls and adds a prioritized allowlist to your project’s.claude/settings.json. /sandboxto toggle sandbox mode (on supported platforms). When sandboxing is enabled withautoAllowBashIfSandboxed: true(the default), sandboxed Bash commands run without prompting. The sandbox boundary substitutes for the per-command prompt, which is a much safer trade than blanket bypass.acceptEditsmode, which auto-accepts file edits and common filesystem commands likemkdir,touch,mv, andcpfor paths in your working directory. Most of the friction without most of the risk.
How orgs lock it down
If you run a team and don’t want anyone using bypass mode, set permissions.disableBypassPermissionsMode to "disable" in managed settings. That blocks the mode regardless of what individual users put in their own settings. The --dangerously-skip-permissions flag will still parse, but the mode won’t activate. Worth setting if Claude Code is going on company laptops with access to anything sensitive.
Custom commands are just skills now
If you find yourself pasting the same instructions into chat, or your CLAUDE.md file has grown a section that’s really a procedure, that procedure should be a skill.
The minimum is a directory with a SKILL.md file. Drop it at ~/.claude/skills/<name>/SKILL.md for personal use across every project, or .claude/skills/<name>/SKILL.md for a single project. The directory name becomes the command. Add YAML frontmatter with a description, and Claude can also load the skill automatically when the description matches what you’re asking.
A useful pattern is the ! prefix to inject live shell output into a skill before Claude reads it:
---
description: Summarize uncommitted changes and flag risky ones.
---
## Current changes
!`git diff HEAD`
## Instructions
Summarize the diff in two or three bullets. Flag missing error handling, hardcoded values, or tests that need updating.When you run /summarize-changes, Claude Code runs git diff HEAD first, replaces the placeholder with the output, and only then sends the prompt. The instructions arrive with the actual diff already inlined.
The full reference is in the skills documentation. I built a few of these for the WordPress sites I run, and the time savings vs pasting the same checklist into chat are real.
Skills worth installing
The good thing about skills being a shared format is you don’t have to write your own to benefit. There’s now a directory at skills.sh where developers publish reusable skills for Claude Code, Cursor, Cline, and other agents. A few I keep installed:
color-expertby meodai. Color naming, theory, palettes, ramps, gradients, conversions, accessibility. The kind of knowledge I don’t want to keep re-explaining to an agent every time I’m picking colors.emil-design-engby Emil Kowalski. Encodes Emil’s philosophy on UI polish, component design, animation decisions, and the small details that make software feel good. If you’ve ever stared at one of Emil’s components on Twitter and wondered how he gets motion to feel that way, this is the closest thing to a transferable answer.make-interfaces-feel-betterby Jakub Krehel. Design engineering principles for hover states, micro-interactions, and the kind of polish that takes a UI from working to nice.
If you want to find more, skills.sh itself has a find-skills skill you can install that helps you discover others when you describe what you’re trying to do. Mildly recursive but useful.
Quick reference
If you just want the categorical list:
- Context tools:
/clear,/compact,/autocompact,/context - Sessions:
/resume,/branch,/rewind - Model and effort:
/model,/effort,/fast - Reviewing changes:
/diff,/code-review(/reviewis an alias),/security-review - Permissions and access:
/permissions,/add-dir,/sandbox - Project setup:
/init,/import,/memory,/skills,/hooks,/cd - Parallel work:
/branch,/fork,/subtask,/background,/workflows,/tasks - Workflow:
/plan,/goal,/loop,/schedule,/simplify,/debug,/verify,/run,/fewer-permission-prompts - Visibility:
/usage,/insights,/status,/doctor - Output:
/copy,/export,/recap - Integrations:
/mcp,/plugin,/reload-plugins,/install-github-app,/install-slack-app - Session UI:
/theme,/color,/focus,/tui,/statusline - The dangerous flag, CLI only:
--dangerously-skip-permissions
That’s not all of them. The complete list is in the official commands reference, and it changes often enough that I’d check it before relying on anything not covered here.