Claude Code: 64 Tips, Tricks & Hacks
Sixty-four of them, grouped by what you are actually trying to do. Some are single flags or keystrokes; the ones that carry the most leverage are habits rather than features, and they sit in the section they belong to alongside the quick reference for that topic.
Beginner → Advanced
1. /init reads the codebase and writes a starting CLAUDE.md for it. Run it once in any project you'll come back to — the generated file is a draft to edit, not a finished one.
2. /statusline gives you a live readout along the bottom of the terminal, refreshed every turn: which model you are actually talking to, how full the context window is, and the tokens going in and coming back out. It is the difference between seeing a compact coming and being surprised by one, between catching an architecture decision you handed to Haiku and never noticing, and between watching a long session's token use climb and hearing about it from your usage limit.
To enable it, run /statusline and describe the line you want in plain language — "show the model, how full the context window is, and the tokens in and out". It writes the script, drops it in ~/.claude/ and wires it into your settings for you, so there is nothing to configure by hand.
Which gives you this at the bottom of every turn:
Opus 5 | Ctx: 37% | In: 45.2k Out: 3.8k
3. claude doctor is run in your terminal, not inside a session, and prints installation and settings diagnostics. It is the first thing to run when something behaves strangely, before you start changing configuration at random.
4. When Claude starts behaving oddly, the first thing to establish is whether the problem is Claude or the pile of configuration you have layered on top of it — and these two flags settle that without deleting anything. --safe-mode starts a normal, usable session with every customization disabled (CLAUDE.md, skills, plugins, hooks, MCP servers, custom commands) while auth, model selection, built-in tools and permissions keep working: reproduce the problem in it, and still broken means the cause is not your setup, fixed means you re-enable one thing at a time until it comes back. --bare is the scripting counterpart, skipping hooks, plugin sync, auto-memory and CLAUDE.md discovery so a CI job behaves identically on every machine — with one catch worth knowing before you put it in a pipeline: it never reads OAuth or the keychain, so it needs ANTHROPIC_API_KEY in the environment.
5. /voice turns on dictation — /voice hold to push-to-talk with the space bar, /voice tap to tap once to start and again to send, /voice off to stop. Transcription costs no tokens and does not count against your usage limits. It needs a Claude.ai account, so it is unavailable on API-key, Bedrock or Vertex auth, and it needs a local microphone, so it does not work over SSH.
6. ? on an empty prompt toggles the shortcut help panel, which is faster than looking up any of the keystrokes below.
14. Keep the context clean, not just short: one conversation per logical task. Debugging a flaky test and then immediately asking for a new feature in the same session means Claude is still carrying the failed hypotheses and dead ends from the first problem into the second. /clear between unrelated tasks costs nothing and removes an entire class of "why did it suggest that?" moments — see Avoiding Usage Limits for what actually fills a context window in the first place.
15. /context shows exactly what is occupying the window, broken down by system prompt, tools, MCP servers, skills and messages. Run it before you assume the conversation is what filled it up; often it is not.
16. /compact takes focus instructions, so you control what survives — "compact, keep the migration plan and drop the debugging" beats letting it choose. Around 60% is a reasonable trigger.
17. # at the start of a message saves a durable note to memory instead of burying the instruction in a conversation that will be compacted away.
18. CLAUDE.md is instructions, not a scratchpad. Update it at the end of a session while you still remember what was missing, and keep it short — around 200 lines is a sane ceiling. Every line is re-read every session, so a bloated file is a permanent tax.
19. Use CLAUDE.md as a router. Point it at where the information lives — "API conventions are in docs/api.md, deploy runbook is in ops/deploy.md" — so Claude knows where to look without you paying for that content in every single session.
20. MCP servers cost context whether you use them or not, because their tool definitions load into every turn. A handful can quietly consume more of the window than your entire conversation. /context will show you the number.
21. For anything large or risky, agreeing on the approach in plan mode before Claude writes a single line costs a fraction of what re-doing a wrong implementation costs. It's also the cheapest place to catch a misunderstanding of the task — a wrong plan is a two-line correction; a wrong implementation is a re-review.
22. Be exact about the problem and loose about the solution. Exactness first: paste the actual error text and stack trace instead of paraphrasing it — a paraphrase drops the one detail (an exact exception type, a line number, a variable name) that would have pointed straight at the cause. Reference src/auth.py:142 instead of "the login function." A concrete, minimal repro ("run pytest tests/test_auth.py -k expired, it fails with X") beats a paragraph describing the symptom, because Claude can run it instead of inferring it.
Then stop. Being exact about the symptom is not the same as dictating the fix, and the second one costs you the thing you came for. If you hand over the exact command to run, you get a typist. Describe the problem and the constraints — "this endpoint times out under load, don't add a caching layer" — and let it work out the approach, then argue with the approach it picks. The two halves feel contradictory and are not: maximum precision about the facts, maximum latitude about the plan.
23. Make it ask you questions. "Before you start, ask me anything that is ambiguous" surfaces the assumptions it would otherwise have made silently, and it is the cheapest bug-prevention available.
24. If Claude keeps drifting toward an approach you've already ruled out, naming it explicitly ("don't add a new dependency for this, use the stdlib") stops the loop faster than repeating the correction after every attempt. If the same correction would apply to every session in this project, it belongs in CLAUDE.md instead of being retyped — a rule stated once in a file Claude reads every session beats being restated once per conversation.
25. Esc interrupts mid-turn and keeps the work done so far, so correcting course early costs you nothing. The instinct to let it finish a response you already know is wrong is the expensive one.
26. Esc Esc on an empty prompt opens the rewind menu, which restores code and conversation to an earlier point. This is the undo button for a session that went sideways three turns ago.
27. ultrathink when a problem genuinely deserves it, or set --effort high, xhigh or max for a whole session. Reasoning depth is a dial, and leaving it at the default for architectural decisions is leaving capability unused.
28. Match the model to the task instead of picking one and forgetting about it. Haiku is right for mechanical passes — renames, moving files, running greps. Opus earns its cost on design, debugging and anything where being wrong is expensive. See Choosing a Model.
29. Option+P (macOS) or Alt+P switches model without clearing what you have already typed, so you can escalate a prompt you are halfway through writing.
30. --fallback-model keeps a long run alive when the primary model is unavailable, retrying the primary at the start of each turn.
31. In an interactive session you notice when Claude gets stuck retrying the same failing test; in a scripted or scheduled run nobody does, and the loop keeps costing money until something stops it. --max-budget-usd is that something: a spending ceiling for the run, though it only applies in -p mode. --max-turns caps how many turns it takes instead — one model response plus its tool calls each — and is accepted even though it is not listed in --help. So claude -p "fix the failing tests" --max-budget-usd 2.00 --max-turns 20 cannot cost more than two dollars or run longer than twenty round trips. Set them before you walk away, not after the first surprise.
32. Shift+Tab cycles permission modes mid-session — manual, accept-edits, plan and, where enabled, auto. Changing posture per task beats picking one setting forever.
33. /permissions is worth twenty minutes once. Explicitly allow the commands that are safe and cannot lose work — tests, linters, builds, read-only git — and explicitly deny the destructive ones. You get autonomy where it is free and a prompt where it matters, instead of approving everything out of habit until you approve the wrong thing.
34. /fewer-permission-prompts reads your own history and generates that allowlist for you, which is a faster starting point than writing it by hand.
35. --add-dir at launch, or /add-dir mid-session, grants access to additional directories. This is how one session works across a service and the library it depends on without you copying files between them.
parallelism and long-running work
36. claude -c continues the most recent conversation in the current directory, which is almost always what you want after closing a terminal by accident.
37. claude -n "refactor-auth" names a session and claude -r "refactor-auth" resumes it by that name. Naming sessions is the difference between resuming work and hunting for it.
38. The single highest-leverage habit here: a git worktree is a separate directory with its own branch checked out, sharing one repo's history — which means a separate Claude Code session running in it can't collide with one running in your main checkout. Instead of waiting on a long task before starting the next one, or context-switching a single session between two unrelated pieces of work, each gets its own directory, its own branch, and its own conversation. See Worktrees & Submodules for the git mechanics in full.
git worktree add ../myapp-feature-x feature-x || creates a sibling directory with "feature-x" checked out, sharing this repo's history — run from your main checkout | 'wt_tip1'
Then, in a second terminal:
cd ../myapp-feature-x && claude || starts an independent Claude Code session scoped to that worktree, while your original session keeps working in the main directory | 'wt_tip2'
A worktree shares git history but not working-directory state — dependencies, build artifacts, and .env files usually need their own install step the first time. Worth it for anything that would otherwise mean idling one session to babysit another: a long-running migration in one worktree while you keep reviewing PRs in the main one, or two genuinely independent features that don't touch the same files.
39. A task that's going to take ten minutes doesn't need you watching the whole time — running it in the background and coming back to check, covered in Avoiding Usage Limits, keeps you unblocked for everything else instead of turning a coffee break into a stare at the terminal.
Two ways to actually do it: ask Claude directly to run the command in the background, or press Ctrl+B while a Bash command it already started is running to move that one command to the background mid-flight (tmux users press it twice, since tmux intercepts the first one as its own prefix key). Either way you get a background task ID back immediately instead of a blocked turn.
/tasks || lists every running background shell and subagent, so you can check progress or pull output on demand instead of it landing in your context unasked | 'bg_tip1'
40. claude --bg goes one step further and starts a whole session in the background, returning immediately with an id.
claude --bg "run the full integration suite and summarize failures" || starts a detached session and prints its id; claude attach, logs, stop and rm all take that id, and claude agents lists everything currently running | 'bg_ref1'
41. Hand independent work to subagents rather than doing it in sequence. Searching three directories for the same pattern is three subagents and one wait, not three waits.
42. context: fork in a skill's frontmatter runs it in an isolated subagent, so its intermediate output never lands in your main context — add agent: alongside it to pick which agent type the fork uses. Reach for it when a skill's work is much larger than its answer. Say you have a skill that answers "which modules still import this deprecated helper?" — it greps the repo, opens forty files and reports three names. Forked, those three names are all that comes back. Unforked, the contents of all forty files sit in your window for the rest of the session, and you pay for them on every later turn. The trade is that a forked skill starts cold and cannot see your conversation, so everything it needs must come from the skill itself — which makes it wrong for anything that depends on where the discussion had got to.
43. Agent teams go further: a coordinated group of separate sessions that Claude spawns and supervises, each teammate with its own context window and tool access, able to message each other. Subagents run inside one session and hand back a summary; teammates are genuinely parallel sessions working the same problem. See Subagents & Agents.
44. Run multi-hour jobs on a VPS with always-on sessions and SSH in to check progress, instead of tying the job to a laptop that sleeps. One caveat before you move: voice dictation needs a local microphone, so it stops working once you are on a remote box.
custom commands and skills
45. A custom command is a file. Create .claude/skills/<name>/SKILL.md with a name and description in the frontmatter and the instructions below it, and it becomes /<name>. See Custom Slash Commands.
46. Turn repeated reviews into skills. A code review skill, a PR review skill, a release checklist. Anything you have typed out twice with the same wording should be a file instead.
47. Inject live state into a skill so it arrives already knowing the current situation instead of asking.
!`git status --short` || put that on its own line inside SKILL.md and it runs before Claude sees the prompt, with the command's real output replacing the line | 'skill_ref1'
48. $ARGUMENTS gives you everything passed to the command, $1 and $2 give you positional arguments, and declaring arguments: in the frontmatter gives you named ones. That is the difference between a saved prompt and a function you can call.
49. allowed-tools: in the frontmatter pre-approves tools for that command only — allowed-tools: Bash(git *) lets a release skill run git without prompting, without granting that permission everywhere else.
hooks, MCP and the browser
50. Anything you ask for every single time is a hook, not a request. Formatting after edits, running tests before a commit, or firing a desktop notification when a long turn finishes — the harness runs these, so they happen whether or not Claude remembers. See Hooks.
51. --strict-mcp-config pins a session to exactly the MCP servers you name and ignores everything else configured on the machine. Useful when you want a clean, cheap context.
52. context7 is the MCP server worth having for library documentation, because a model's training data is always older than the framework you are using.
53. MCP or a plain API call? Use MCP when you want the capability available every session and discoverable by Claude without being asked. Use a plain API call or a small script when it is a one-off, because tool definitions cost context on every turn whether or not you use them. A server you consult twice a month is not worth a permanent tax on every conversation.
54. The Chrome integration lets it see the page. Claude can open the site, read the rendered DOM and the console, click through a flow and tell you what actually broke. For front-end work this replaces describing the bug with showing it. See MCP Servers.
55. /loop repeats a prompt or slash command on an interval within a session — /loop 5m /check-ci — or self-paces if you omit the interval. /schedule is the other tool: it creates cloud agents that run on a cron schedule, including one-off future runs, and they survive your terminal closing.
56. -p makes Claude non-interactive, and with --output-format json it becomes a normal Unix citizen you can pipe into something else.
claude -p "summarize what changed on this branch" --output-format json || runs one turn, prints structured output and exits, so the result can be parsed by whatever comes next in the pipeline | 'script_ref1'
57. --json-schema goes further and validates the output against a schema you supply, which is what you want when a downstream step will break on a malformed field.
58. cat error.log | claude -p "what broke?" pipes a file straight in without you pasting it.
59. claude setup-token sets up a long-lived authentication token for environments where nobody can log in interactively, such as CI jobs and cron. It requires a Claude subscription. Treat the output like any other credential: store it in your CI secret manager, and never paste it back into a Claude session or a terminal you are recording.
60. --append-system-prompt bolts one constraint onto a single run without editing any file — useful for a one-off "respond only with the patch, no commentary" in a script.
61. Read the diff before accepting it, the same way you'd review a colleague's PR — Claude is confident whether or not it's right, and confidence isn't the signal to watch for. If a change is opaque, "explain what this does and why" is a cheap way to catch a misunderstanding before it ships, not after. And a suggested destructive command (a force-push, a DROP TABLE, an rm -rf) is worth reading in full before approving it, not reflexively confirming because the last five suggestions were fine.
62. Build the check into the task. "Add the endpoint, then write a test that fails without it and prove the test fails on the old code" produces its own evidence, and a to-do list with verification steps in it gets verified.
63. Challenge the first version. "What would a stricter reviewer say about this?" or "solve it again without the extra dependency" costs one turn and regularly produces something better. A first answer is a draft.
64. Ctrl+O opens the transcript viewer, showing the real tool calls with timestamps and the model used, rather than the summary of what happened. When a result surprises you, this is where you find out why.