Claude Code Features and Run Modes: Sessions, Headless, and Slash Commands

From components to operation

The previous knowledge point named the core components of Claude Code, the Rules, Skills, Commands, Agents, and Agent Memory that customise it inside a repository. This one is about actually operating the tool: the features and run modes you use to get work done. Where identifying the components is a remember-level task, this is an understand-level task on the Claude Certified Developer - Foundations (CCDV-F) exam, so the questions ask you to reason about which feature or mode fits a situation, not merely to name them.

Three ideas carry most of the weight here: session management, the different run modes (headless, streaming, and auto), and custom slash commands. Learn what each one is for and, just as importantly, learn the pairs the exam deliberately blurs, interactive versus headless, and streaming versus auto. Those confusions are where the marks are won and lost.

Session management: resume and fork

Session management is what lets your work with Claude Code persist across separate runs instead of starting cold every time. Two capabilities matter. You can resume a session, picking up a prior conversation with its context intact so you continue where you left off rather than re-establishing everything. And you can fork a session, branching from an existing one to explore a different direction while keeping the original untouched.

The point of both is context preservation. A long piece of work does not have to live in one unbroken sitting; resuming carries the accumulated context forward, and forking lets you try an alternative path without losing the line you were on. This connects to the durable-context idea from the components: sessions are how the work itself is carried across runs, complementing the Agent Memory that holds durable facts within them.

Headless mode: running without a human

Headless mode runs Claude Code non-interactively. There is no live chat at a terminal; instead the tool is invoked programmatically, driven by a script or a pipeline, and it does its work without a person prompting it turn by turn. This is the mode that makes automation and continuous integration possible: you can wire Claude Code into a CI job, a scheduled task, or any workflow where no human is sitting at the keyboard to answer questions.

Understanding headless mode is what dismantles the most common misconception on this knowledge point, that interactive chat is the only way to run Claude Code. It is not. Interactive mode is the default experience, but headless mode is a first-class way to operate the tool, and it is precisely what you reach for when the work needs to run unattended. Recognising that automation path exists is often the whole point of an exam item here.

Streaming mode versus auto mode

These two are the sharpest trap in the knowledge point because they sound similar and are easily conflated, yet they describe entirely different things.

Streaming mode is about how output is delivered. Rather than waiting for a complete response and returning it all at once, streaming returns the output incrementally, token by token or chunk by chunk, as it is produced. It affects when you see results, not what the tool is allowed to do.

Auto mode is about how work is executed. It lets Claude Code proceed autonomously, carrying out steps with less step-by-step human approval, so the tool drives its own execution further before pausing. It affects the degree of autonomy, not the delivery of text.

Hold the two axes apart: streaming is a delivery mechanism, auto is an autonomy setting. A run could stream its output while still asking for approval at each step, or execute autonomously while returning results only when finished. Conflating "output appears incrementally" with "the tool acts on its own" is exactly the error the exam sets, and keeping delivery separate from autonomy is how you avoid it.

Custom slash commands: packaging workflows

Claude Code ships with built-in slash commands, and it also lets a team define custom ones. A custom slash command packages a repeatable prompt or workflow behind a single invokable name, so that instead of retyping a long instruction every time, a teammate types the command and the packaged workflow runs. This is the same Command component from the previous knowledge point, now viewed as an operational feature: it is how a team turns its recurring prompts into shared, one-line actions.

The value is consistency and reuse across a team. A well-designed custom slash command captures the right way to do a recurring task once, then makes it trivially repeatable for everyone. Because these commands are configured as part of a project's setup, they live alongside the broader CLAUDE.md and settings.json configuration that shapes how Claude Code behaves in a repository, and they pair naturally with focused work split out through subagents.

What the exam trips candidates on

The CCDV-F exam tests two specific confusions on this knowledge point, and both come from underestimating how flexibly Claude Code can be operated.

The first is assuming interactive mode is the only way to run Claude Code, and therefore missing headless automation entirely. If a scenario describes needing Claude Code to run inside a CI pipeline or a scheduled job with no human present, and an answer implies that is impossible or that you must sit and chat with it, that answer is wrong. Headless mode is the non-interactive path built for exactly this, and knowing it exists is frequently the crux of the question.

The second is confusing streaming mode with auto mode. Streaming is incremental output; auto is autonomous execution. Because both are "modes" and both sound like they make things faster or more hands-off, they get swapped. Anchor streaming to delivery and auto to autonomy, and treat any option that describes streaming as "the tool acting on its own," or auto as "showing output as it types," as the distractor it is.

Common misreadings to avoid

How it shows up on the exam

Domain 3, Claude Code, is a small, focused domain, and this knowledge point is its understand-level item under task statement 3.1. Expect scenarios rather than definitions: a team needs Claude Code to run somewhere without a person, or a candidate mixes up which mode produces incremental output, and you are asked to pick the feature that fits or to correct the mistake. Because it is an understand-level target, naming the mode is not enough; you have to reason about which one solves the described need.

The reliable strategy is to keep the vocabulary crisp and the two trap-pairs separated. Session management is resume-and-fork for preserving context; headless is non-interactive for automation; streaming is incremental delivery; auto is autonomous execution; custom slash commands package workflows for reuse. This knowledge point builds directly on the core components, so if the difference between a Command and the other building blocks is still fuzzy, revisit that first, and the slash-command half of this topic will click into place.