Claude Code Operation, Configuration, and Extension Surfaces

A developer should operate Claude Code by choosing one surface for each kind of control. Use CLAUDE.md and Rules for persistent instructions, settings.json for supported behavior and policy configuration, Skills for reusable model-invoked or user-invoked workflows, slash commands for explicit session actions, agents for delegated work with a separate context, plugins for distributing a reviewed bundle of extensions, hooks for deterministic lifecycle actions, and permissions for deciding which tool requests are allowed, denied, or require approval. Keep each session focused, and choose interactive, headless, streaming, or auto operation according to the task's need for human supervision and machine-readable output.

The hierarchy is equally important: organization-managed controls and command-line choices can override lower-scope defaults, while project and local configuration should express repository-specific behavior without weakening higher-authority policy. Instructions, settings, extension packages, session state, and agent memory are related but not interchangeable. A clear operational map prevents a rule written in the wrong layer from appearing to work while being unenforced where it matters.

Start with the Claude Code Operating Mode

The Claude Code features overview presents Claude Code as a coding agent that can inspect a codebase, edit files, run commands, and integrate with development tools. Its operating mode should match the control boundary of the task.

Interactive sessions

Interactive operation is the default fit for exploratory development, requirements clarification, and changes that need frequent judgment. The developer can inspect proposed actions, answer questions, change direction, and review diffs while the task is underway.

Use an interactive session when:

the request is still ambiguous;
the work crosses unfamiliar components;
a tool action could have a broad effect;
the developer expects to compare alternatives; or
the result needs iterative visual or behavioral inspection.

Interactivity does not replace version control or review. It supplies a human decision point while work is in progress.

Headless and streaming operation

The programmatic Claude Code documentation describes headless use for scripts, pipelines, and other non-interactive workflows. In this mode, the caller supplies a prompt and selects an output format appropriate to the consumer. Text is useful for a person or simple wrapper; JSON is useful for a single structured result; streaming JSON is useful when a controller must process incremental events.

Headless operation needs a stronger contract than an interactive session. Define the working directory, permitted tools, expected output, timeout, exit handling, logs, and failure path before placing it in automation. Do not build a pipeline around terminal formatting intended for a person, and do not treat a successful process exit as proof that the requested engineering outcome is correct.

Streaming is an output and integration choice, not a separate trust model. The consumer still needs to handle partial events, errors, and final completion deliberately. Detailed application-streaming recovery belongs to Claude API integration; here the operational concern is selecting a stable Claude Code output contract for the calling system.

Auto mode

Auto mode can reduce repeated approval prompts for bounded work when it is available under the current Claude Code version and organization policy. It should be selected only after the repository scope, tool reach, network access, and rollback path are understood. Auto mode is not equivalent to unrestricted execution, and it must not be used to bypass managed settings or organizational policy.

Because mode names and availability are living product behavior, verify the current feature and permission documentation before relying on auto mode in a team workflow. For consequential or poorly bounded changes, keep explicit human review in the loop.

Separate the Configuration Hierarchy

Claude Code configuration works best when each scope has a named owner and a narrow purpose. The current settings documentation distinguishes managed, command-line, local-project, shared-project, and user-level controls. The effective value follows documented precedence rather than file discovery order or developer expectation.

A practical precedence model, from higher to lower authority, is:

organization-managed settings and policy;
explicit command-line arguments for the invocation;
local project settings that are not intended for source control;
shared project settings committed for the repository; and
user settings that supply personal defaults.

Verify the exact current precedence in the settings documentation before designing a control that depends on it. Higher-precedence enforcement belongs at the managed layer; a repository file should not be expected to override organization policy. Conversely, personal preferences should not be committed as if they were team requirements.

Give each settings scope a clear job

Scope	Appropriate responsibility	Avoid
Managed	Organization policy and controls that users or projects must not weaken	Personal formatting preferences
Invocation	Deliberate one-run mode or output choices	Undocumented permanent team policy
Local project	Machine- or developer-specific repository settings	Shared rules that teammates require
Shared project	Reviewable repository behavior and approved project defaults	Secrets or workstation-specific paths
User	Cross-project personal defaults	Controls that must be enforced for everyone

Treat settings files as configuration, not as a secret store. Review shared changes with the same care as other repository changes, and test how the effective configuration behaves in the intended environment.

Use CLAUDE.md, Rules, and Memory for Different Lifetimes

The Claude Code memory documentation explains how persistent instructions are discovered at supported managed, user, project, and directory scopes. A CLAUDE.md file is durable guidance read by Claude Code; it is not application runtime configuration and not a place to hide credentials.

Put durable repository guidance in CLAUDE.md

Project CLAUDE.md guidance should contain information that applies broadly to work in the repository:

build and test commands;
architecture and directory conventions;
naming and code-style rules that tools cannot enforce automatically;
review expectations and safety constraints; and
links to deeper project documentation.

Keep instructions concise, concrete, and verifiable. Contradictory or obsolete guidance creates unpredictable behavior and wastes context. When the same requirement can be enforced by a formatter, linter, test, permission, or hook, use that deterministic mechanism and let CLAUDE.md explain the workflow around it.

Claude Code can load instructions from broader scopes and more specific project or directory contexts. More specific guidance should refine the broader rule for its subtree rather than silently contradict it. Managed policy remains authoritative. If behavior appears surprising, inspect which instruction files are active instead of adding another conflicting instruction.

Use Rules for modular and path-relevant guidance

Rules let a project split instruction content into focused files instead of turning one CLAUDE.md into a long policy manual. A rule can describe a concern such as testing, documentation, database migrations, or frontend conventions; where supported, path targeting can limit when the rule is relevant.

Use Rules when several independently maintained instruction topics need different ownership or applicability. Use CLAUDE.md for the concise repository map and high-value guidance that should be seen together.

Distinguish instructions from Agent Memory

Agent Memory records durable information an agent can carry according to its configured memory scope. It should contain useful learned context, not credentials, access tokens, or an unreviewed substitute for project policy. Instructions tell an agent how to work; memory preserves relevant knowledge learned across work. Session context, by contrast, is the current conversation and tool history.

Those lifetimes should remain separate:

put stable team policy in reviewed project instructions or settings;
put reusable task procedure in a Skill;
put agent-specific learned context in the supported Agent Memory scope;
keep task-specific reasoning and transient details in the session; and
put durable business facts in the system that owns those facts, not only in Claude Code memory.

Initialize and Maintain Repository Context

Repository initialization should create a small, accurate starting point rather than an exhaustive generated manual. The built-in /init command can inspect a repository and propose a CLAUDE.md. Review that output before adopting it: remove guesses, confirm commands, preserve local project instructions, and avoid including secrets or generated noise.

A maintainable initialization sequence is:

run Claude Code from the intended repository root;
inspect the project and identify authoritative build, test, and contribution files;
use the built-in initialization flow or create CLAUDE.md deliberately;
verify every command and path it names;
split specialized guidance into Rules where that improves scope; and
commit only the guidance and shared settings the team has reviewed.

Revisit repository guidance when build tooling, architecture, or team policy changes. Stale instructions can be more harmful than missing instructions because they appear authoritative.

Choose the Right Extension Surface

Claude Code exposes several ways to extend behavior. Select the smallest surface that matches the owner, invocation model, distribution need, and enforcement requirement.

Slash commands for explicit session control

Built-in slash commands provide explicit actions inside an interactive session, such as inspecting status, managing context, or invoking supported workflows. They are appropriate when a user should choose the action at a visible point in the session.

Custom command-style workflows and Skills overlap in current Claude Code. Prefer the current Skills documentation for reusable capabilities, and preserve older command layouts only when current documentation supports their compatibility. Do not assume that a familiar slash name is available in every installed version.

Skills for reusable procedures

A Skill packages instructions and supporting resources for a repeatable task. It can describe when it applies, the procedure to follow, validation requirements, and any scripts or references it needs. Skills are useful when the same workflow should be discoverable and reusable without placing all of its detail into persistent repository memory.

Keep a Skill focused. A Skill that attempts to govern every repository action becomes difficult to trigger correctly and difficult to review. Security-sensitive enforcement still belongs in permissions, sandboxing, hooks, or external controls rather than in prose alone.

Agents and subagents for delegated context

The subagent documentation describes specialized agents with their own prompt, context, tool access, and optional memory. Use an agent when a bounded task benefits from role-specific instructions, context isolation, or restricted tools. Use the main session when separation would only add coordination overhead.

An agent definition selects how delegated work is performed; it does not by itself design a production agent system. Manager loops, application agents, framework selection, and deployment architecture belong to agent construction rather than Claude Code operation.

Plugins for distribution

The plugin documentation describes a package that can distribute Claude Code extensions such as Skills, agents, hooks, Model Context Protocol servers, and related configuration. Choose a plugin when a reviewed collection must be installed, versioned, and maintained as a unit across projects or teams.

Packaging does not establish trust. Record the plugin source, version, included components, settings effects, update policy, and rollback path. Keep project-specific instructions outside a general plugin unless their reuse boundary is explicit.

Hooks for deterministic lifecycle actions

The hooks guide documents commands or agent actions triggered at supported Claude Code lifecycle events. Hooks are appropriate when an action must occur deterministically around an event—for example, formatting changed files, recording an audit signal, or blocking a known unsafe condition.

Hooks execute with real environment consequences and can become a security boundary. This article identifies their operational role; hook hardening, sandboxing, and destructive-action controls belong to the security architecture.

Permissions for tool decisions

The permissions documentation controls whether requested tool actions are allowed, denied, or require approval. Permissions answer “may this action be attempted?” A Skill or CLAUDE.md instruction answers “how should this task be performed?” Keeping those questions separate prevents advisory prose from being mistaken for enforcement.

Start with the least privilege needed for the task. Use managed policy for organization requirements, project settings for reviewed repository behavior, and explicit approval for sensitive or unusual actions. Detailed threat modeling and secure-deployment design remain outside this operational overview.

Maintain Session Hygiene

A session should have one coherent objective and a controlled context. Long sessions accumulate assumptions, tool output, and decisions that may no longer apply. Session hygiene means making state visible and resetting or resuming it deliberately.

Use these practices:

begin from the correct repository and working tree;
state the current objective, boundary, and acceptance check;
inspect relevant project instructions and effective settings;
clear context before unrelated work rather than carrying hidden assumptions forward;
compact only when the retained summary is adequate for the remaining task;
resume a prior session only when its repository state and objective still match; and
review the final diff and verification output independently of the conversation history.

Headless callers should treat session identifiers and streamed events as application data. Do not expose one user's session to another workflow, and do not depend on implicit terminal state as the only record of what automation performed.

Common Operational Mistakes

Putting every control in CLAUDE.md. Instructions cannot replace settings precedence, permissions, hooks, tests, or organization policy.
Confusing settings scopes. A user preference is not a shared project rule, and a project setting cannot be assumed to override managed policy.
Using one session for unrelated work. Old context can introduce stale assumptions and unnecessary disclosure.
Treating a Skill as enforcement. A reusable procedure guides behavior; deterministic controls must enforce sensitive boundaries.
Using a subagent for simple linear work. Delegation is valuable for isolation or specialization, not as mandatory ceremony.
Installing a plugin without inventorying it. A plugin can introduce several extension types and configuration effects at once.
Automating headless output without a contract. Pipelines need a documented output format, failure path, permissions model, and verification step.
Equating auto mode with unrestricted access. Automation remains bounded by current product behavior, policy, permissions, and the task's risk.

Relevance to Claude Certified Developer – Foundations

Claude Code Operation in the CCDV-F Exam Guide v1.0 covers Rules, Skills, Commands, Agents, Agent Memory, sessions, slash commands, headless use, streaming, auto mode, CLAUDE.md hierarchy, repository initialization, and settings.json. Related Claude Application Design, Configuration Management, and Agentic Customization skills add the need to choose and govern plugins, hooks, permissions, and subagents without conflating their responsibilities.

The important capability is not memorizing a directory list. It is explaining which surface owns an instruction, default, reusable workflow, delegated context, distributed extension, deterministic event action, enforced permission, or transient session—and then applying the documented precedence and scope.

Conclusion

Reliable Claude Code operation depends on separating modes, scopes, and extension responsibilities. Interactive work supports ongoing judgment; headless and streaming modes support automation with explicit contracts; auto mode is appropriate only for bounded work under current policy. CLAUDE.md, Rules, settings, Skills, commands, agents, plugins, hooks, permissions, memory, and sessions each solve a different problem.

Use the narrowest surface that can own the requirement, place enforceable controls at the highest appropriate authority, and keep transient work out of durable policy. This approach makes Claude Code behavior easier to understand, review, troubleshoot, and change without turning development configuration into production agent architecture or a substitute for security controls.