{"slug": "claude-code-everything-you-can-configure-that-the-docs-don-t-tell-you", "title": "Claude Code – Everything You Can Configure That the Docs Don't Tell You", "summary": "Claude Code's source code reveals undocumented configuration capabilities, including a \"YOLO Classifier\" auto-mode permission system that accepts plain English environment descriptions to determine safe auto-approvals. Hooks can return JSON on stdout with event-specific fields that modify Claude Code's behavior in real time, such as rewriting tool inputs mid-flight or programmatically allowing or denying permissions. These findings come from version 2.1.87 of the npm package, with some features explicitly flagged as experimental and subject to change.", "body_md": "# I Read the Claude Code Source Code. Here's Everything You Can Configure That the Docs Don't Tell You.\n\n### Hook fields that rewrite commands mid-flight, persistent agent memory, auto-mode rules in plain English, self-improving dream loops, and every example is copy-paste ready.\n\nClaude Code’s auto-mode permission system is internally called the “YOLO Classifier.” That’s the actual variable name in yoloClassifier.ts. And you can configure it with plain English descriptions of your environment, things like “this is a staging server, destructive operations are acceptable,” that the classifier reads to decide what’s safe to auto-approve. This isn’t in any documentation.\n\nIt’s one of dozens of undocumented capabilities buried in the Claude Code source code, which is sitting right there in your node_modules as a publicly distributed npm package. The official docs cover the basics well enough. But the source code reveals fields, response formats, and settings that dramatically expand what you can build. Everything here works right now, and every example is designed to be dropped into your project as-is.\n\nA note on versioning: These findings come from @anthropic-ai/claude-code@2.1.87. Undocumented features can change between releases, so treat this as a snapshot of what’s available today. Fields with “EXPERIMENTAL” in their names are explicitly flagged as unstable by Anthropic’s own engineers, and I’ll call those out individually.\n\n## Before you start\n\nQuick reference for where everything lives:\n\n**Settings:**`~/.claude/settings.json`\n\n(personal) or`.claude/settings.json`\n\n(project, shared via git)**Skills:**`~/.claude/skills/<name>/SKILL.md`\n\n(personal) or`.claude/skills/<name>/SKILL.md`\n\n(project)**Agents:**`~/.claude/agents/<name>.md`\n\n(personal) or`.claude/agents/<name>.md`\n\n(project)**Hook scripts:**`~/.claude/hooks/`\n\nis a good convention. Remember to`chmod +x`\n\nyour scripts.\n\nProject-level files in `.claude/`\n\ncan be committed to git and shared with your team. Personal files in `~/.claude/`\n\nare yours alone.\n\n## Your hooks can talk back, and nobody told you how\n\nThis is the biggest gap in the documentation. The docs tell you hooks receive JSON on stdin and that exit code 2 blocks an operation. What they don’t tell you is that hooks can return JSON on stdout with event-specific fields that modify Claude Code’s behavior in real time. The source code reveals exactly what each event type accepts.\n\n**PreToolUse** hooks can return:\n\n`updatedInput`\n\n- rewrite the tool’s input before it executes. You can modify commands mid-flight.`permissionDecision`\n\n- force “allow” or “deny” without prompting the user.`permissionDecisionReason`\n\n- explain the decision (shown in UI).`additionalContext`\n\n- inject text into the conversation context.\n\n**SessionStart** hooks can return:\n\n`watchPaths`\n\n- set up automatic file watching that triggers FileChanged events.`initialUserMessage`\n\n- prepend content to the first user message in the session.`additionalContext`\n\n- inject context that persists for the whole session.\n\n**PostToolUse** hooks can return:\n\n`updatedMCPToolOutput`\n\n- modify what Claude sees from an MCP tool response.`additionalContext`\n\n- inject context after a tool runs.\n\n**PermissionRequest** hooks can return:\n\n`decision`\n\n- programmatically allow or deny with`updatedInput`\n\nor`updatedPermissions`\n\n.\n\nThis is powerful stuff. Here’s a PreToolUse hook that automatically adds `--dry-run`\n\nto any git push command before Claude executes it.\n\nIn your `settings.json`\n\n:\n\n```\n{\n  \"hooks\": {\n    \"PreToolUse\": [{\n      \"matcher\": \"Bash\",\n      \"hooks\": [{\n        \"type\": \"command\",\n        \"command\": \"~/.claude/hooks/dry-run-pushes.sh\"\n      }]\n    }]\n  }\n}\n```\n\nAnd the script at `~/.claude/hooks/dry-run-pushes.sh`\n\n:\n\n``` bash\n#!/bin/bash\nINPUT=$(jq -r '.tool_input.command' < /dev/stdin)\nif echo \"$INPUT\" | grep -q 'git push'; then\n  jq -n --arg cmd \"$INPUT --dry-run\" '{\"updatedInput\": {\"command\": $cmd}}'\nfi\n```\n\nClaude thinks it’s running `git push origin main`\n\n, but your hook quietly rewrites it to `git push origin main --dry-run`\n\nbefore execution. The `updatedInput`\n\nfield isn’t in any docs.\n\nHere’s a SessionStart hook that watches your config files and injects git context into every session.\n\n`settings.json`\n\n:\n\n```\n{\n  \"hooks\": {\n    \"SessionStart\": [{\n      \"hooks\": [{\n        \"type\": \"command\",\n        \"command\": \"~/.claude/hooks/session-context.sh\",\n        \"statusMessage\": \"Loading project context...\"\n      }]\n    }]\n  }\n}\n```\n\n`~/.claude/hooks/session-context.sh`\n\n:\n\n``` bash\n#!/bin/bash\nBRANCH=$(git branch --show-current 2>/dev/null)\nCHANGES=$(git status --porcelain 2>/dev/null | wc -l | tr -d ' ')\n\njq -n \\\n  --arg branch \"$BRANCH\" \\\n  --arg changes \"$CHANGES\" \\\n  '{\n    \"watchPaths\": [\"package.json\", \".env\", \"tsconfig.json\"],\n    \"additionalContext\": \"Current branch: \\($branch). Uncommitted changes: \\($changes) files.\"\n  }'\n```\n\nNow Claude Code automatically watches your `package.json`\n\n, `.env`\n\n, and `tsconfig`\n\nfor changes, and it knows what branch you’re on and how many uncommitted files you have before you even type anything.\n\nAnd here’s one that auto-approves read-only bash commands without prompting.\n\n`settings.json`\n\n:\n\n```\n{\n  \"hooks\": {\n    \"PreToolUse\": [{\n      \"matcher\": \"Bash\",\n      \"hooks\": [{\n        \"type\": \"command\",\n        \"command\": \"~/.claude/hooks/auto-approve-readonly.sh\"\n      }]\n    }]\n  }\n}\n```\n\n`~/.claude/hooks/auto-approve-readonly.sh`\n\n:\n\n``` bash\n#!/bin/bash\nCMD=$(jq -r '.tool_input.command' < /dev/stdin)\nif echo \"$CMD\" | grep -qE '^(ls|cat|echo|pwd|whoami|date|git status|git log|git diff)'; then\n  echo '{\"permissionDecision\": \"allow\", \"permissionDecisionReason\": \"Safe read-only command\"}'\nfi\n```\n\nYou’re basically building your own permission classifier with shell scripts. The `permissionDecision`\n\nfield isn’t in any docs.\n\n## Three hook fields the docs forgot to mention\n\nThe documented hook fields are `type`\n\n, `command`\n\n, `matcher`\n\n, `timeout`\n\n, `if`\n\n, and `statusMessage`\n\n. The source code parser accepts three more that fundamentally change how hooks behave.\n\n`once: true`\n\nfires the hook exactly once, then auto-removes it. Perfect for first-session setup:\n\n```\n{\n  \"hooks\": {\n    \"SessionStart\": [{\n      \"hooks\": [{\n        \"type\": \"command\",\n        \"command\": \"[ -f .env ] || cp .env.example .env && echo 'Created .env from template'\",\n        \"once\": true,\n        \"statusMessage\": \"First-time setup...\"\n      }]\n    }]\n  }\n}\n```\n\nSimple enough to inline. It checks if `.env`\n\nexists, copies the template if not, and never runs again.\n\n`async: true`\n\nruns the hook in the background without blocking Claude. Fire and forget:\n\n```\n{\n  \"hooks\": {\n    \"PostToolUse\": [{\n      \"matcher\": \"Bash\",\n      \"hooks\": [{\n        \"type\": \"command\",\n        \"command\": \"jq '{timestamp: now, command: .tool_input.command, session: .session_id}' < /dev/stdin >> ~/.claude/audit.jsonl\",\n        \"async\": true\n      }]\n    }]\n  }\n}\n```\n\nThat logs every bash command to an audit file without adding any latency to your session.\n\n`asyncRewake: true`\n\nis the clever one. It runs in the background like async, so it doesn’t block on the happy path. But if it exits with code 2, it wakes the model back up and blocks the operation. Non-blocking when everything’s fine, blocking when something’s wrong:\n\n`settings.json`\n\n:\n\n```\n{\n  \"hooks\": {\n    \"PostToolUse\": [{\n      \"matcher\": \"Write|Edit\",\n      \"hooks\": [{\n        \"type\": \"command\",\n        \"command\": \"~/.claude/hooks/scan-secrets.sh\",\n        \"asyncRewake\": true,\n        \"statusMessage\": \"Scanning for secrets...\"\n      }]\n    }]\n  }\n}\n```\n\n`~/.claude/hooks/scan-secrets.sh`\n\n:\n\n``` bash\n#!/bin/bash\nFILE=$(jq -r '.tool_input.file_path // .tool_response.filePath' < /dev/stdin)\nif grep -qE '(password|secret|api_key)\\s*=' \"$FILE\" 2>/dev/null; then\n  exit 2  # Block: secrets detected\nfi\nexit 0    # Clean: carry on\n```\n\nThis scans every file Claude writes for hardcoded secrets. If it finds one, it blocks and tells Claude. If not, you never even notice it ran.\n\n## Skill frontmatter fields the docs don’t show\n\nThe documentation covers `name`\n\n, `description`\n\n, `allowed-tools`\n\n, `argument-hint`\n\n, `when_to_use`\n\n, and `context`\n\n. The actual frontmatter parser in the source code accepts six more.\n\n`model`\n\nlets you override which model runs the skill. Use haiku for cheap, fast tasks and opus for complex analysis:\n\n```\n---\nname: quick-lint\ndescription: Fast lint check using the cheapest model\nmodel: haiku\neffort: low\nallowed-tools: Bash, Read\nargument-hint: \"[file]\"\n---\nRun the project linter on: $ARGUMENTS\nDetect the linter from config (eslint, ruff, clippy) and run it. Report only errors, not warnings.\n```\n\nThat runs on Haiku at low effort, so it’s fast and cheap. For a deep architecture review you’d want `model: opus`\n\nand `effort: max`\n\n.\n\n`effort`\n\ncontrols how hard the model thinks. `low`\n\n, `medium`\n\n, `high`\n\n, or `max`\n\n. This maps to the same effort system that internally controls reasoning depth per response.\n\n`hooks`\n\ndefines hooks scoped to when the skill is active. They register when the skill fires and deregister when it completes:\n\n```\n---\nname: strict-typescript\ndescription: Write TypeScript with type checking on every save\nallowed-tools: Bash, Read, Write, Edit, Grep, Glob\nhooks:\n  PostToolUse:\n    - matcher: \"Write|Edit\"\n      hooks:\n        - type: command\n          command: \"~/.claude/hooks/typecheck-on-save.sh\"\n          statusMessage: \"Type checking...\"\n        - type: command\n          command: \"~/.claude/hooks/lint-on-save.sh\"\n          async: true\n---\nWrite TypeScript with strict enforcement. Every file you touch gets type-checked and linted automatically.\n$ARGUMENTS\n```\n\n`~/.claude/hooks/typecheck-on-save.sh`\n\n:\n\n``` bash\n#!/bin/bash\nFILE=$(jq -r '.tool_input.file_path // .tool_response.filePath' < /dev/stdin)\n[[ \"$FILE\" == *.ts ]] && npx tsc --noEmit 2>&1 || true\n```\n\n`~/.claude/hooks/lint-on-save.sh`\n\n:\n\n``` bash\n#!/bin/bash\nFILE=$(jq -r '.tool_input.file_path // .tool_response.filePath' < /dev/stdin)\n[[ \"$FILE\" == *.ts ]] && npx eslint --fix \"$FILE\" 2>&1 || true\n```\n\nWhile this skill is running, every TypeScript file Claude writes gets type-checked synchronously and linted in the background. When the skill finishes, those hooks disappear. The scoping is clean.\n\n`agent`\n\ndelegates the skill to a custom agent:\n\n```\n---\nname: deep-review\ndescription: Thorough security review delegated to the review agent\nagent: security-review\n---\nReview the following: $ARGUMENTS\n```\n\n`disable-model-invocation: true`\n\nprevents auto-invocation. Only explicit `/skill-name`\n\nworks. Use this for destructive skills you don’t want firing accidentally.\n\n`shell: bash`\n\nspecifies which shell to use for execution.\n\n## Agent fields you won’t find in any docs\n\nCustom agents in `.claude/agents/`\n\nsupport frontmatter fields the documentation doesn’t mention.\n\n`color`\n\nsets the UI color: `red`\n\n, `orange`\n\n, `yellow`\n\n, `green`\n\n, `blue`\n\n, `purple`\n\n, `pink`\n\n, or `gray`\n\n. Helps visually distinguish agents when multiple are running.\n\n`memory`\n\nis the big one. It gives the agent persistent memory across invocations:\n\n`user`\n\n- global, persists across all projects`project`\n\n- per-project persistence`local`\n\n- private per-project (gitignored)\n\nThis means you can build an agent that learns. A security reviewer that tracks past findings. A code reviewer that remembers your patterns across sessions. The memory uses the same frontmatter format as the auto-memory system.\n\n```\n---\nname: codebase-guide\ndescription: Answer questions about the codebase, learning more with each session\ntools: [Read, Grep, Glob, Bash]\ncolor: green\nmemory: project\n---\nYou are a codebase guide with persistent memory. Check your memory first before exploring the code.\n\nAfter answering a question, save useful context to memory:\n- Architecture decisions (type: project)\n- Code locations for common tasks (type: reference)\n- Patterns and conventions (type: feedback)\n\nOver time, you should answer faster because you remember where things are.\n```\n\nAfter a few sessions, this agent builds a knowledge base about your codebase and starts answering from memory before grepping.\n\n`omitClaudeMd: true`\n\nskips loading the CLAUDE.md instruction hierarchy. Useful for a “fresh eyes” reviewer that applies industry standards rather than your project’s conventions:\n\n```\n---\nname: fresh-eyes\ndescription: Review code without project-specific biases\ntools: [Read, Grep, Glob]\nomitClaudeMd: true\neffort: high\ncolor: blue\n---\nReview this code purely from first principles. You have no project context. Focus on correctness, security, performance, and readability by industry standards.\n```\n\n`criticalSystemReminder_EXPERIMENTAL`\n\nis a short message re-injected at every turn as a system reminder. Even after conversation compaction, this stays in context:\n\n```\n---\nname: prod-deployer\ndescription: Manages production deployments with strict safety checks\ntools: [Bash, Read, Grep]\ncolor: red\ncriticalSystemReminder_EXPERIMENTAL: \"Always run migrations with --dry-run first. Never skip the staging verification step.\"\n---\n```\n\nWarning: This field has EXPERIMENTAL in its actual name in the source code. Anthropic’s engineers consider it unstable. It works right now, but it could be removed or renamed in any release. Use it for nice-to-have safety reminders, don’t build critical infrastructure on it.\n\n`requiredMcpServers`\n\nlists MCP server name patterns that must be configured. If the servers aren’t available, the agent won’t appear. Prevents agents from loading when their dependencies aren’t set up.\n\n## The auto-mode classifier accepts plain English\n\nThe `autoMode`\n\nfield in `settings.json`\n\nconfigures what Anthropic internally calls the “YOLO Classifier.” This controls what gets auto-approved in auto mode:\n\n```\n{\n  \"autoMode\": {\n    \"allow\": [\n      \"Bash(npm test)\",\n      \"Bash(npm run *)\",\n      \"Bash(git status)\",\n      \"Bash(git diff *)\",\n      \"Bash(git log *)\",\n      \"Read\",\n      \"Grep\",\n      \"Glob\"\n    ],\n    \"soft_deny\": [\n      \"Bash(git push *)\",\n      \"Bash(rm *)\",\n      \"Write(.env*)\"\n    ],\n    \"environment\": [\n      \"NODE_ENV=development\",\n      \"This is a local dev machine with no production database access\",\n      \"All Docker containers use isolated networks\",\n      \"The test suite is safe to run repeatedly, it uses a dedicated test database\"\n    ]\n  }\n}\n```\n\n`allow`\n\npatterns get auto-approved. `soft_deny`\n\npatterns always require confirmation. The `environment`\n\narray is the interesting one, it’s not patterns at all. These are plain English context strings the classifier reads to understand your setup. You can write “This project uses Docker, all commands run in containers” and the classifier factors that into its safety decisions for ambiguous commands.\n\nThink of it like giving the classifier a briefing about your environment. The more specific you are, the better it makes decisions. “No production access” tells it to be less paranoid about destructive operations. “Test database is isolated” tells it running tests is always safe.\n\n## The learning loop toggles nobody documented\n\nTwo `settings.json`\n\nfields activate Claude Code’s self-improvement system:\n\n```\n{\n  \"autoMemoryEnabled\": true,\n  \"autoDreamEnabled\": true\n}\n```\n\n`autoMemoryEnabled`\n\nmakes Claude Code automatically extract durable memories from your sessions. After each conversation, a background agent pulls out things worth remembering, your preferences, your codebase patterns, decisions you made, and writes them to `~/.claude/projects/<path>/memory/`\n\nusing the standard memory frontmatter format.\n\n`autoDreamEnabled`\n\nactivates background “dream” consolidation. Every 24 hours, if 5 or more sessions have accumulated, a background agent reviews past session transcripts and consolidates memories. It merges duplicates, resolves contradictions, converts relative dates to absolute, and prunes stale entries.\n\nTogether these create a compound learning loop: sessions produce memories, dreams consolidate memories, consolidated memories inform future sessions. Turn both on and after a few weeks you’ll notice Claude Code remembering your preferences, conventions, and common patterns without being told. It’s genuine learning from experience without any model retraining.\n\n## Magic Docs: the exact format\n\nThe source reveals the regex: `/^#\\s*MAGIC\\s+DOC:\\s*(.+)$/im`\n\n. It must be an H1 heading, it’s case insensitive, and the next line can be italicized instructions (wrapped in `_underscores_`\n\nor `*asterisks*`\n\n) that scope what the update agent focuses on:\n\n```\n# MAGIC DOC: API Endpoint Reference\n_Only document public REST endpoints. Include method, path, request body, response schema, and auth requirements._\n\n## Endpoints\n\n(content auto-maintained by Claude Code)\n```\n\nWithout the instruction line, the agent tries to update everything. With it, you tell it “only track public endpoints” or “focus on breaking changes” and it respects that. The update agent runs in the background and is restricted to editing only that specific file. Deleting the header stops tracking automatically.\n\n## The full permission rule syntax\n\nThe docs show basic examples like `Bash(git *)`\n\n. The source reveals the complete pattern language:\n\n```\nBash(npm *)              # wildcard after \"npm \"\nBash(git commit *)       # specific subcommand\nRead(*.ts)               # file extension\nRead(src/**/*.ts)        # recursive directory with extension\nWrite(src/**)            # recursive, all files\nmcp__slack               # all tools on slack server\nmcp__slack__*            # explicit wildcard (same effect)\nmcp__slack__post_message # specific tool\nBash(npm:*)              # legacy colon prefix (word boundary)\n```\n\n`*`\n\nmatches within boundaries like shell globbing. `**`\n\nmatches recursively through directories. MCP tool permissions use double underscores: `mcp__<server>__<tool>`\n\n. The `if`\n\nfield in hooks uses this exact same syntax. No regex, just globs.\n\n```\n{\n  \"permissions\": {\n    \"allow\": [\n      \"Bash(npm *)\", \"Bash(git status)\", \"Bash(git diff *)\",\n      \"Read(src/**)\", \"Read(tests/**)\", \"Grep\", \"Glob\",\n      \"mcp__database__query\"\n    ],\n    \"deny\": [\n      \"Bash(rm -rf *)\", \"Write(/etc/**)\", \"Write(.env*)\",\n      \"mcp__slack__delete_*\"\n    ],\n    \"ask\": [\n      \"Bash(git push *)\", \"Write(*.json)\", \"Write(*.lock)\",\n      \"mcp__slack__post_message\"\n    ]\n  }\n}\n```\n\n## context: fork and why your model choice matters\n\nWhen you set `context: fork`\n\non a skill, it runs as a background forked subagent. The source reveals that forks share the parent’s prompt cache through a typed contract called `CacheSafeParams`\n\n. All forks produce byte-identical API request prefixes to maximize cache hits.\n\nThe practical implication: if you set a different model on a forked skill, you break the cache. The parent conversation is on Opus, the fork is on Haiku, the prefixes diverge, cache miss, you pay full price. Either omit the model field or use `model: inherit`\n\non forked skills to keep the cache working.\n\nUse `context: fork`\n\nfor heavy work: security scans, dependency analysis, documentation generation, test suite runs. The fork runs in the background and notifies you when done, keeping your main conversation responsive.\n\n```\n---\nname: full-audit\ndescription: Comprehensive codebase audit running in the background\ncontext: fork\nallowed-tools: Bash, Read, Grep, Glob, WebSearch\neffort: high\n---\nRun a comprehensive audit:\n- Security scan (grep for dangerous patterns, check dependencies for CVEs)\n- Code quality (duplicated logic, dead code, missing error handling)\n- Test coverage (untested critical paths)\n- Dependency health (outdated packages, unused deps, license issues)\n\nWrite a detailed report to /tmp/audit-report.md when complete.\n```\n\n## Putting it all together\n\nA self-improving code reviewer with persistent memory and scoped hooks:\n\n`.claude/agents/reviewer.md`\n\n:\n\n```\n---\nname: reviewer\ndescription: Code reviewer that learns your codebase patterns over time\ntools: [Read, Grep, Glob, Bash]\neffort: high\ncolor: yellow\nmemory: project\nhooks:\n  PostToolUse:\n    - matcher: \"Bash\"\n      hooks:\n        - type: command\n          command: \"~/.claude/hooks/log-review.sh\"\n          async: true\n---\nBefore reviewing, read your memory for past findings on this codebase.\n\nReview git diff HEAD~1 for:\n- Patterns you've flagged before (check memory)\n- New issues worth flagging\n- Resolved issues from past reviews\n\nAfter review, save to memory:\n- New patterns found (type: feedback)\n- Recurring issues (type: project)\n\nEnd with VERDICT: PASS, FAIL, or NEEDS_REVIEW.\n```\n\nThis agent remembers what it found last time. It knows which patterns keep recurring. After a few reviews, it starts catching project-specific issues that a generic reviewer would miss.\n\nA SessionStart hook with file watching plus an asyncRewake safety net:\n\n`settings.json`\n\n:\n\n```\n{\n  \"hooks\": {\n    \"SessionStart\": [{\n      \"hooks\": [{\n        \"type\": \"command\",\n        \"command\": \"~/.claude/hooks/session-context.sh\",\n        \"statusMessage\": \"Loading project context...\"\n      }]\n    }],\n    \"PreToolUse\": [{\n      \"matcher\": \"Bash\",\n      \"hooks\": [{\n        \"type\": \"command\",\n        \"command\": \"~/.claude/hooks/auto-approve-readonly.sh\"\n      }, {\n        \"type\": \"command\",\n        \"command\": \"~/.claude/hooks/block-dangerous.sh\",\n        \"asyncRewake\": true,\n        \"statusMessage\": \"Safety check...\"\n      }]\n    }]\n  }\n}\n```\n\n`~/.claude/hooks/block-dangerous.sh`\n\n:\n\n``` bash\n#!/bin/bash\nCMD=$(jq -r '.tool_input.command' < /dev/stdin)\necho \"$CMD\" | grep -qE '(rm -rf /|sudo rm|chmod 777|> /dev/)' && exit 2 || exit 0\n```\n\nRead-only commands get auto-approved instantly. Dangerous commands get blocked. Everything in between goes through normal permission flow. The safety scanner runs async so it doesn’t slow anything down on the happy path.\n\nA skill with model override, effort control, and agent delegation:\n\n```\n---\nname: architecture-review\ndescription: Deep architecture review using max effort, delegated to fresh-eyes agent\nagent: fresh-eyes\neffort: max\n---\nReview the architecture of this project. Ignore existing conventions (the agent has omitClaudeMd: true).\nFocus on: $ARGUMENTS\n\nEvaluate structural decisions, dependency graph health, separation of concerns, and scalability characteristics.\n```\n\nThis chains three undocumented features: `effort: max`\n\nfor deep thinking, agent delegation to a specific agent, and that agent uses `omitClaudeMd: true`\n\nfor unbiased analysis.\n\nThese undocumented features reveal the gap between what Claude Code is today and what Anthropic is building it to become. The hooks system with event-specific response fields is a programmable middleware layer for AI tool use, more flexible than most CI/CD pipelines. Persistent agent memory creates AI specialists that accumulate genuine expertise across sessions. The dream consolidation system is learning from experience without model retraining. The auto-mode classifier accepts natural language descriptions of your environment to make safety decisions.\n\nThese aren’t hidden settings or easter eggs. They’re the scaffolding for persistent, learning, autonomous AI development environments, and they’re already functional in the npm package on your machine. The docs will probably catch up eventually, but if you want to build on the cutting edge of what Claude Code can actually do, the source code is where the real documentation lives.", "url": "https://wpnews.pro/news/claude-code-everything-you-can-configure-that-the-docs-don-t-tell-you", "canonical_source": "https://buildingbetter.tech/p/i-read-the-claude-code-source-code", "published_at": "2026-05-29 02:13:20+00:00", "updated_at": "2026-05-29 02:45:48.118372+00:00", "lang": "en", "topics": ["ai-tools", "ai-agents", "large-language-models", "ai-products", "ai-infrastructure"], "entities": ["Claude Code", "Anthropic", "YOLO Classifier"], "alternates": {"html": "https://wpnews.pro/news/claude-code-everything-you-can-configure-that-the-docs-don-t-tell-you", "markdown": "https://wpnews.pro/news/claude-code-everything-you-can-configure-that-the-docs-don-t-tell-you.md", "text": "https://wpnews.pro/news/claude-code-everything-you-can-configure-that-the-docs-don-t-tell-you.txt", "jsonld": "https://wpnews.pro/news/claude-code-everything-you-can-configure-that-the-docs-don-t-tell-you.jsonld"}}