Claude Code 1.3 Deep Dive: Features, Shortcuts, Config 2026

Claude Code 1.3 is a Claude Code release that quietly turned an interactive REPL into a platform — interactive and print modes, hooks across eight events, skills, a three-tier memory hierarchy, MCP-server orchestration, project and user subagents, and a settings.json schema that ties all of it together. Teams that use 10% of the surface area get a smart pair-programmer. Teams that use it all run engineering departments through it.

The gap between those two outcomes is configuration, not capability. The features below have been shipping for months — what changes outcomes is whether your team has agreed on a settings.json schema, knows which hook fires when, has a skills library that encodes your repo's conventions, and has subagents wired into the workflows that actually consume engineering time.

This guide is a complete reference: every feature, every shortcut worth remembering, every settings.json field, every hook event, the skills and memory contracts, MCP and subagent wiring, and the four configuration anti-patterns that stall rollouts. It is meant to be read once and bookmarked — the next time someone asks how to silence a noisy PreToolUse hook, the answer is here.

The default Claude Code experience is genuinely useful out of the box. Install the CLI, run claude, ask it to refactor something, and you get most of the value that GitHub Copilot promised. That is roughly 10% of what the 1.3 release actually ships — and it is also where most teams stop.

The other 90% is where engineering departments start to outpace their tooling. Print mode turns Claude Code into a scriptable primitive that fits into shell pipelines, git hooks, and CI jobs. Skills encode repeatable procedures that any teammate can invoke by name. Subagents enforce least-privilege execution — your code reviewer cannot accidentally git push --force because its tool allowlist never included Bash. Hooks let you instrument every tool call for cost, safety, and audit. MCP servers let Claude Code reach into Zoho, Supabase, Vercel, Linear, and whatever else your stack runs on.

None of these surfaces are particularly hard to learn in isolation. The friction is that the documentation is spread across docs pages, release notes, blog posts, and code samples — so each team rediscovers them piecemeal, usually after running into a problem that one of them would have solved. The point of this guide is to collapse that discovery cost into a single reference.

One signal of how seriously to take this: the most productive engineering teams we work with treat their .claude/ directory the same way they treat their CI config — a versioned, reviewed, team-owned artifact that defines how the system behaves. New hire onboarding includes a walkthrough of the skill library and the subagent kit, not just "here is the README". That shift in posture is what 1.3 invites; the rest of this guide is the mechanics.

Claude Code 1.3 ships four primary modes. They are not exclusive — most teams use all four across different workflows — but it is worth understanding what each one is for, because the right decisions about hooks, output discipline, and approval gates depend on the mode the agent is running in.

Two implications worth pulling out. First, print mode is the secret-handshake feature. Most product engineers never leave the REPL; the platform engineers who quietly automate everything live in print mode, embedding claude -p in pre-commit hooks, deployment guards, scheduled compliance audits, and slack bots. If your team has never written a print-mode integration, you are leaving a category of leverage on the table.

Second, the IDE integration is a thin shell on top of the same CLI. That means everything in this guide — settings.json, hooks, skills, subagents — works identically inside VS Code and the terminal. A team that configures the CLI well configures the IDE well by default; there is no separate IDE configuration story to learn.

Claude Code 1.3 inherits the usual REPL conventions plus a small set of agent-specific shortcuts. The block below is the working list we keep pinned next to every developer's desk — by frequency of use, not alphabetical. If you only memorize the top ten, you will recover roughly half the productivity teams report from learning the full set.

# Session control
Ctrl+C              Cancel the in-flight tool call (keeps session open)
Ctrl+D              Exit Claude Code (end the session)
Ctrl+L              Clear the screen (history retained)
Esc                 Interrupt the model mid-response

# Input editing
↑ / ↓               Cycle through prior prompts
Ctrl+R              Reverse-search through prompt history
Tab                 Path / slash-command completion
Shift+Enter         Newline inside a multi-line prompt

# Slash commands
/help               List available slash commands
/agents             List, select, or edit subagents
/skills             List installed skills (built-in + project)
/memory             Open the memory file for the current scope
/permissions        Edit permission allow / deny rules
/model              Switch backing model (sonnet / opus / haiku)
/clear              Clear context window (keeps session metadata)
/init               Generate CLAUDE.md scaffold for a new project
/login              Re-authenticate the CLI
/cost               Show current session token spend

# Plan-mode workflow
/plan               Enter plan mode (propose then execute)
y                   Approve the proposed plan
n                   Reject and revise
e                   Edit the plan before approving

# File and tool focus
@<path>             Insert a file reference into the prompt
@<path>:<line>      Reference a specific line for context anchoring
!<command>          Suggest a shell command for one-shot Bash use

# Quick toggles
Cmd+Shift+P         (IDE) Open command palette inside VS Code-hosted session

Three of these earn their keep many times over. Esc to interrupt is the single most-used shortcut — Claude Code 1.3 is obedient about stopping mid-response, which means you do not have to let a wrong direction finish. @<path> file-references collapse multi-step context discovery into a single keystroke; teach this to every new user on day one. And the /plan workflow with y / n / e approval keys is what makes multi-file edits safe without slowing the interactive loop to a crawl.

settings.json is the contract that ties every Claude Code surface together. It lives in three places, precedence running from highest to lowest: project-local .claude/settings.local.json (gitignored, machine-specific), project-shared .claude/settings.json (committed, team standard), and user-scoped ~/.claude/settings.json (your personal defaults across all repos). When two files set the same key, the higher-precedence file wins.

The schema is small but every field has long-lever consequences. The five panels below are the ones to budget time on:

The pattern we recommend across client repos: keep the user-scope file thin (your personal model preference, your status line, your global denylist), keep the project-shared file canonical (team permissions, project MCP servers, the hooks every teammate inherits), and keep the project-local file empty by default — it is the emergency override, not the daily-driver.

One trap to avoid early: do not paste production secrets into settings.json environment variables. The shared file is committed, the user file is sync-able across machines, and even the local file is easy to accidentally check in. Use env placeholders that resolve from the host environment, or wire a secrets manager into the MCP server definition.

Hooks are the instrumentation surface. Eight events fire across the session lifecycle, each one capable of running a shell command with the event payload as stdin. The shell command can decide whether to allow, block, or annotate the event — which is how Claude Code 1.3 lets you enforce policy without writing custom plugins.

The four most-used events:

• PreToolUse. Fires before every tool call. Exit non-zero to block. Use to deny dangerous bash patterns, redact prompts containing secrets, or require approval for specific file paths.
• PostToolUse. Fires after the tool returns. Use to log tool calls into an audit stream, push diffs into review, or trigger downstream automation.
• Stop. Fires when Claude Code finishes a turn. The right place for completion notifications (speak the result, ping a Slack channel, append to a log).
• SubagentStop. Fires when a subagent finishes. Same shape as Stop but scoped to delegated work — useful for orchestration patterns where the parent session wants to react to each delegated result.

The pattern most under-deployed in the field is the PreToolUse + PostToolUse pair. PreToolUse gates dangerous operations (deny Bash(rm -rf *) outright, require approval for Bash(git push origin main)), while PostToolUse logs the structured event payload to a per-repo audit file. Together they give you a tamper-resistant trail of every action Claude Code took on a repo — useful for compliance, invaluable when debugging a session that misbehaved hours ago.

Skills and memory are two halves of the same idea — making Claude Code remember things across sessions. The difference is what kind of thing. Skills are procedures Claude can invoke by name; memory is context Claude carries between invocations.

Skills

A skill is a folder under .claude/skills/<name>/ (project) or ~/.claude/skills/<name>/ (user). Inside, a SKILL.mdfile declares the skill's name, description, trigger phrases, and the procedure to follow when invoked. Optional scripts and assets sit alongside.

The contract is simple: skills are advertised by their description, invoked by name (/skills lists them, slash-prefix shorthand runs them), and they execute their procedure against the current session context. A team that ships ten well-defined skills — release-notes-from-PRs, audit-status-history, deploy-staging, rollback-last-merge, generate-fixture-data — gives every teammate a shared verb vocabulary that the agent already understands.

Memory hierarchy

Memory has three tiers. Each is loaded automatically when Claude Code starts a session, with predictable precedence:

1. Project memory · CLAUDE.md at the repo root. Committed. Shared across the team. The canonical place for project conventions, tech stack defaults, and team-specific quirks.
2. User memory · ~/.claude/CLAUDE.md. Personal. Never committed. Useful for the cross-project preferences (preferred IDE, voice cues, project locations).
3. Auto-memory · ~/.claude/projects/<project-id>/memory/. A directory of small markdown files Claude Code maintains itself. Each file captures a durable lesson learned mid-session. Loaded-on-relevance rather than always-on, so it scales without blowing the context window.

The discipline that separates teams that get value from this from teams that fight it is keeping CLAUDE.md lean. Bloated project memory files cause the model to skim — every section is loaded every session, so every paragraph competes for attention with every other paragraph. Aim for under 300 lines, prune quarterly, push richer detail into auto-memory or skills.

The last two surfaces in 1.3 are where most of the upside lives for teams already comfortable with the basics. MCP servers extend the tool inventory beyond what ships in the CLI; subagents partition that inventory into focused, least-privilege experts.

MCP servers

Model Context Protocol is the open standard for exposing tools and data sources to LLM agents. Claude Code 1.3 is a first-class MCP client. Add a server in settings.json under mcpServers, restart the session, and the server's tools appear in the inventory automatically.

Three patterns of MCP server worth knowing. Vendor servers are published by SaaS providers — Supabase, Zoho, Linear, Vercel — and let Claude Code reach into your live operational data. Open-source servers are community projects for common needs (filesystem search, GitHub API, Postgres). And internal servers are the ones your team writes to expose proprietary tooling — release scripts, observability dashboards, ticket systems — through the same protocol.

Subagents

Subagents are markdown files under .claude/agents/<name>.md (project) or ~/.claude/agents/<name>.md(user). YAML frontmatter declares the agent's name, description, tool allowlist, and backing model. The markdown body is the system prompt. Each invocation runs as a fresh Claude session with that pre-baked prompt and a restricted toolset — no memory of prior calls, no access to the main session's chat history.

That isolation is the entire point. A read-only code-reviewer subagent cannot accidentally write files; a researcher subagent cannot run bash commands; an orchestrator subagent cannot edit code. The tool allowlist is a safety boundary that the main session can rely on. For the full walkthrough — frontmatter, system-prompt structure, orchestration patterns — our step-by-step subagent guide covers it end-to-end.

The combined picture is what matters. A well-configured team ships: MCP servers for the operational tools the agent needs to reach, subagents for the recurring expert roles (reviewer, test-writer, security-auditor, deployment-guard), skills for the named procedures the team invokes by verb, a hooks layer that instruments the whole thing, a memory hierarchy that keeps CLAUDE.md lean, and a settings.json that wires them together. That stack is what 1.3 makes practical, and what 1.2 did not.

If you want this calibrated to your specific repos rather than built from scratch, our AI digital transformation engagements ship custom Claude Code deployments end-to-end — skill libraries, subagent kits, hook automation, memory discipline — tuned to the team and the codebase.

The same four mistakes show up across most struggling Claude Code rollouts. None of them are obvious failures — the agent still answers, the session still runs — but each is a tax on every interaction that compounds over weeks. If your team's rollout is stuck, these are the first four places to look.

The meta-pattern under all four: treat .claude/ as production infrastructure. Review the changes the way you review CI config. Promote them through the same channels as code (PRs, review, merge). Audit them at the same cadence (quarterly, or after any major incident). Teams that operate Claude Code this way stay in the productive 90%; teams that treat configuration as personal preference end up in the stalled 10%.