Claude Code CLI Commands I Wish I Had Known Sooner

-->

5 Hidden Claude Code CLI Commands You Need to Know

India's Most Futuristic AI Conference Is Back – Bigger, Sharper, Bolder

d

:

h

:

m

:

s

Career

GenAI

Prompt Engg

ChatGPT

LLM

Langchain

RAG

AI Agents

Machine Learning

Deep Learning

GenAI Tools

LLMOps

Python

NLP

SQL

AIML Projects

Reading list

How to Become a Data Analyst in 2025: A Complete RoadMap

A Comprehensive Learning Path to Tableau in 2025

A Comprehensive NLP Learning Path 2025

Learning Path to Become a Data Scientist in 2025

Step-by-Step Roadmap to Become a Data Engineer in 2025

A Comprehensive MLOps Learning Path: 2025 Edition

Roadmap to Become an AI Engineer in 2025

A Comprehensive Learning Path to Master Computer Vision in 2025

Best Roadmap to Learn Generative AI in 2025

GenAI Roadmap for Enterprises

Large Language Models Demystified: A Beginner’s Roadmap

Learning Path to Become a Prompt Engineering Specialist

Claude Code CLI Commands I Wish I Had Known Sooner

Sree Vamsi Last Updated : 31 Jul, 2026

11 min read

I used Claude Code daily for months before realizing that claude --help hides many of its most useful capabilities. I kept restarting fresh sessions, repeatedly explaining the same project structure, simply because I did not know a better workflow existed.

While debugging an unrelated issue, I discovered the full CLI reference: dozens of commands and flags that completely changed how I use the tool. In this article, I walk through the hidden features that mattered most in practice and how they can make Claude Code significantly more productive.

Table of contents

1. The First Thing That Changed: I Stopped Losing My Sessions

1. The One That Changed My Whole Working Day: Background Agents

1. The Flag I Should Have Learned on Day One

1. Where I Was Quietly Burning Money

1. The Setting I Had Wrong for Months

1. MCP From the Terminal

1. System Prompts: Append or Replace, and Why It Matters

1. When Something Breaks

Quick Reference

What I Would Tell Myself Six Months Ago

Frequently Asked Questions

Note: This article skips installation and beginner setup. If you are new to Claude Code, start with Getting Started with Claude Code for installation and first-run setup, and Claude Code: Master it in 20 Minutes for a quick overview of the tool. Everything below focuses on the less obvious CLI features and is verified against Claude Code v2.1.209 and later; version-specific flags are noted where relevant.

1. The First Thing That Changed: I Stopped Losing My Sessions

Claude Code saves every session automatically. It always has. I just never knew how to get back into one. Three flags fix the entire problem:

Continue the most recent session in this directory

claude -c

Name a session when you start it

claude -n "auth-refactor"

Come back to it by name, days later

claude -r "auth-refactor" "finish the PR description"

The naming part is what makes this actually usable. Without a name you get an auto-generated ID like 7c5dcf5d, which works fine but is impossible to remember. With a name, resuming a piece of work three days later takes one command and Claude already knows everything about it.

There is a fourth flag here worth knowing. If you want to pick up an old session but you are about to try something risky, –fork-session branches it so the original transcript stays untouched:

claude -r auth-refactor --fork-session

FlagWhat it actually does for you

claude -cPicks up your last session in this folder. Full context, no re-explaining.

claude -n "name"Names the session so you can find it later without hunting for an ID.

claude -r "name"Resumes a specific session by name or ID.

claude --fork-sessionResumes but branches, so the original session stays as it was.

claude --from-pr 123Opens the session picker filtered to sessions tied to a specific pull request.

Try this now: Open a project you were working on yesterday and run claude -c. If you have ever used Claude Code in that folder, it will pick up exactly where you left off. This one command is the difference between a tool you restart every day and one that remembers your project.

1. The One That Changed My Whole Working Day: Background Agents

If you take one thing from this article, take this one.

Adding --bg to any command starts the task as a background agent and hands your terminal straight back to you. Claude keeps working. You keep working. You check on it when you feel like it.

$ claude --bg "investigate why payments.test.js is flaky" Session started: 7c5dcf5d To attach: claude attach 7c5dcf5d To view logs: claude logs 7c5dcf5d To stop: claude stop 7c5dcf5d

The moment this clicked for me was a Monday morning. I kicked off a background agent to audit an unfamiliar codebase for security issues, then spent the next forty minutes doing my actual planned work in a second terminal. When I came back, it had a full report waiting. I had not been sitting there watching a spinner.

You can run several at once. My usual pattern now looks like this:

Fire off two long jobs

claude --bg "audit the API surface for missing auth checks" claude --bg "find every TODO comment older than six months"

Get on with your own work, then check in

claude agents

Managing them

CommandWhat it does

claude agentsLive view of every session, running and finished.

claude agents --jsonSame thing as JSON, so you can parse it in a script.

claude attach Pull a background session into your current terminal.

claude logs Print recent output without attaching.

claude stop Stop a running session.

claude rm Remove it from the list. The transcript stays on disk.

claude respawn Restart a session with its conversation intact.

claude respawn --allRestart everything. Useful right after a Claude Code update.

One more that took me a while to notice. The –exec flag runs a plain shell command as a background job instead of a Claude session, which is surprisingly handy for long test runs:

claude --bg --exec 'pytest -x tests/'

If parallel agents interest you at a bigger scale, Anthropic pushed this much further with Dynamic Workflows, which can coordinate hundreds of parallel subagents in a single session. We covered that in our Claude Opus 4.8 article.

1. The Flag I Should Have Learned on Day One

-p, short for --print. It runs your query, prints the answer, and exits. No interactive session, no waiting for follow-up.

On its own that sounds boring. What makes it interesting is that it turns Claude Code from a thing you sit inside into a thing you can pipe into:

Ask one question, get one answer, back to your shell

claude -p "what does auth.js actually do"

Pipe a file straight in instead of asking Claude to find it

cat error.log | claude -p "summarise these errors by root cause" cat changes.diff | claude -p "review this diff for security issues"

Continue your last session but just get one answer

claude -c -p "any type errors left?"

The piping is the part I lean on most now. Feeding a log file or a diff directly into Claude is faster than describing where the file is and waiting for it to read from disk, and it works on files outside your project folder.

Try this now: Find any log file on your machine and run: cat thatfile.log | claude -p “what is going wrong here”. It takes about ten seconds and it is the fastest way to understand what -p is for.

Output formats, once you start scripting

Once -p is in your toolkit, output formats become relevant. Text is the default. JSON gives you something parseable. Stream JSON gives you an event stream for real-time pipelines:

claude -p "list all API routes" --output-format json claude -p "query" --output-format stream-json --verbose

And if you are calling Claude Code from a script a lot, --bare is worth knowing. It skips auto-discovery of hooks, skills, plugins, MCP servers, and CLAUDE.md so the call starts faster. Claude still has Bash and file tools, nothing else loads:

claude --bare -p "quick question about this one file"

1. Where I Was Quietly Burning Money

This section exists because of a bill I did not enjoy looking at.

Claude Code has an effort setting that controls how much reasoning it applies to a task. I had never touched it, which meant every trivial task got the same deep-thinking treatment as a hard architecture problem.

claude --effort low # small edits, quick questions claude --effort medium # standard day-to-day coding claude --effort high # complex refactors, architecture work claude --effort ultracode # xhigh effort with ultracode on (v2.1.203+)

Matching effort to the task is the single easiest cost lever in the tool. A one-line fix does not need max effort.

Hard limits for anything automated

For scripted or automated runs, two flags stop things getting out of hand. I now treat both as mandatory in any pipeline:

Stop once API spend hits two dollars

claude -p --max-budget-usd 2.00 "large refactor task"

Stop after five agentic turns

claude -p --max-turns 5 "investigate this bug"

As of v2.1.217, spend from subagents counts toward –max-budget-usd, and once the cap is hit Claude Code stops background subagents that are still running. Before that version, subagent spend could quietly overshoot the cap.

There is a lot more depth on cost control than I can fit here. If this is your concern, 23 Tips for Claude Code Token Saving goes properly deep on model choice, effort tuning, and reusable subagents, and it is where I picked up most of my own habits.

1. The Setting I Had Wrong for Months

Permission modes control how much Claude Code does without checking with you first. I ran on the default for a long time, approving every single file edit by hand, and assumed that was the only safe option.

It is not. There are six modes, and picking the right one for the task removes a lot of friction without giving up control where it matters:

ModeWhat it allowsWhen I use it

defaultPrompts before every edit and tool useUnfamiliar codebases

acceptEditsAuto-accepts file edits, still asks before BashMost of my actual work

planPlans only. Writes nothing, runs nothing.Understanding a change before allowing it

autoDecides for itself what is safe to allowProjects I know well

dontAskSuppresses prompts but keeps safety checksLonger trusted tasks

bypassPermissionsSkips all permission promptsCI only, in a sandbox

claude --permission-mode plan claude --permission-mode acceptEdits

Same as bypassPermissions, deliberately verbose so you notice it

claude --dangerously-skip-permissions

Plan mode was the real find for me. When I am about to let Claude touch something I do not fully understand yet, I start in plan mode, read what it intends to do, then switch modes and let it run. It costs one extra step and has caught flat-out wrong assumptions more than once.

Restricting tools instead of modes

Separately from permission modes, you can limit which tools Claude has at all:

FlagEffect

--tools "Bash,Edit,Read"Only these built-in tools are available this session.

--tools ""No tools. Claude can only produce text.

--allowedTools "Bash(git log *)"Auto-allow matching calls without prompting.

--disallowedTools "Bash(rm *)"Always deny matching calls, tool stays otherwise usable.

--disallowedTools "mcp__*"Deny every MCP tool for this session.

1. MCP From the Terminal

MCP is what lets Claude reach into your database, GitHub, Slack, and anything else you connect. I am not going to re-explain the setup here because we have a full walkthrough in How to Connect MCP Servers with Claude, covering both Claude Desktop and Claude Code. What I do want to flag are the CLI commands that are easy to miss.

The three I actually use

Check what is connected and what is broken

claude mcp list

Authenticate a server showing 'needs authentication'

claude mcp login sentry

Bring over everything already set up in Claude Desktop

claude mcp add-from-claude-desktop

That last one saved me a tedious afternoon. I had five servers configured in Claude Des

[truncated for AI cost control]