CLAUDE.md and rules), skills, hooks, and more.
When you omit settingSources, query() reads the same filesystem settings as the Claude Code CLI: user, project, and local settings, CLAUDE.md files, and .claude/ skills, agents, and commands. To run without these, pass settingSources: [], which limits the agent to what you configure programmatically. Managed policy settings and the global ~/.claude.json config are read regardless of this option. See What settingSources does not control.
For a conceptual overview of what each feature does and when to use it, see Extend Claude Code.
Control filesystem settings with settingSources
The setting sources option (setting_sources in Python, settingSources in TypeScript) controls which filesystem-based settings the SDK loads. Pass an explicit list to opt in to specific sources, or pass an empty array to disable user, project, and local settings.
This example loads both user-level and project-level settings by setting settingSources to ["user", "project"]:
<cwd> is the working directory you pass via the cwd option, or the process’s current directory if unset. For the full type definition, see SettingSource (TypeScript) or SettingSource (Python).
Omitting
settingSources is equivalent to ["user", "project", "local"].
The cwd option determines where the SDK looks for project-level inputs. CLAUDE.md and rules load from <cwd> and from every parent directory. Skills load from <cwd> and from every parent directory up to the repository root. Project settings.json and hooks load only from <cwd>/.claude/ with no parent-directory fallback.
What settingSources does not control
settingSources covers user, project, and local settings. A few inputs are read regardless of its value:
Project instructions (CLAUDE.md and rules)
CLAUDE.md files and .claude/rules/*.md files give your agent persistent context about your project: coding conventions, build commands, architecture decisions, and instructions. When settingSources includes "project" (as in the example above), the SDK loads these files into context at session start. The agent then follows your project conventions without you repeating them in every prompt.
CLAUDE.md load locations
All levels are additive: if both project and user CLAUDE.md files exist, the agent sees both. There is no hard precedence rule between levels; if instructions conflict, the outcome depends on how Claude interprets them. Write non-conflicting rules, or state precedence explicitly in the more specific file (“These project instructions override any conflicting user-level defaults”).
For how to structure and organize CLAUDE.md content, see Manage Claude’s memory.
Skills
Skills are markdown files that give your agent specialized knowledge and invocable workflows. UnlikeCLAUDE.md (which loads every session), skills load on demand. The agent receives skill descriptions at startup and loads the full content when relevant.
Skills are discovered from the filesystem through settingSources. When the skills option on query() is omitted, discovered user and project skills are enabled and the Skill tool is available, matching CLI behavior. To control which skills are enabled, pass skills as "all", a list of skill names, or [] to disable all. When skills is set, the SDK adds the Skill tool to allowedTools automatically. If you also pass an explicit tools list, include "Skill" in that list so Claude can invoke skills.
Skills must be created as filesystem artifacts (
.claude/skills/<name>/SKILL.md). The SDK does not have a programmatic API for registering skills. See Agent Skills in the SDK for full details.Hooks
The SDK supports two ways to define hooks, and they run side by side:- Filesystem hooks: shell commands defined in
settings.json, loaded whensettingSourcesincludes the relevant source. These are the same hooks you’d configure for interactive Claude Code sessions. - Programmatic hooks: callback functions passed directly to
query(). These run in your application process and can return structured decisions. See Control execution with hooks.
.claude/settings.json and you set settingSources: ["project"], those hooks run automatically in the SDK with no extra configuration.
Hook callbacks receive the tool input and return a decision dict. Returning {} means allow the tool to proceed. To block execution, return a hookSpecificOutput object with permissionDecision: "deny" and a permissionDecisionReason. The reason is sent to Claude as the tool result. The top-level decision and reason fields are deprecated for PreToolUse. See the hooks guide for the full callback signature and return types.
When to use which hook type
The TypeScript SDK supports additional hook events beyond Python, including
SessionStart, SessionEnd, TeammateIdle, and TaskCompleted. See the hooks guide for the full event compatibility table.Choose the right feature
The Agent SDK gives you access to several ways to extend your agent’s behavior. If you’re unsure which to use, this table maps common goals to the right approach.
Every feature you enable adds to your agent’s context window. For per-feature costs and how these features layer together, see Extend Claude Code.
Related resources
- Extend Claude Code: Conceptual overview of all extension features, with comparison tables and context cost analysis
- Skills in the SDK: Full guide to using skills programmatically
- Subagents: Define and invoke subagents for isolated subtasks
- Hooks: Intercept and control agent behavior at key execution points
- Permissions: Control tool access with modes, rules, and callbacks
- System prompts: Inject context without CLAUDE.md files