For Claude Code users and builders, this is the kind of article that makes you realize the product is a lot more programmable than the official docs suggest. André Figueira’s read-through of the source code surfaces a pile of hidden hooks, frontmatter fields, and agent settings that can change how Claude behaves at runtime, sometimes in surprisingly powerful ways.
PreToolUse hooks can rewrite commands mid-flight with updatedInput, which means you can silently change a command before execution.SessionStart hooks can set watchPaths, add initialUserMessage, and inject additionalContext for the whole session.PostToolUse hooks can alter MCP tool output via updatedMCPToolOutput and add more context after a tool runs.PermissionRequest hooks can programmatically approve or deny actions, turning shell scripts into a custom permission layer.once: true to auto-remove a hook after it fires once.async: true to run a hook in the background.asyncRewake: true to run non-blocking, but wake Claude back up and block if the hook exits with code 2.--dry-run to git push,model, effort, hooks, agent, disable-model-invocation, and shell.model and effort let a skill pick a different model and reasoning depth, which could make lightweight skills cheaper and heavier ones more capable.color and memory, where memory can persist across invocations in different scopes: user, project, and local.What strikes me is how much of Claude Code’s real power seems to live in the seams: not in the obvious CLI surface, but in the hook contracts and frontmatter parsers. I think that’s genuinely exciting for people building internal developer tooling, because it opens the door to workflow-specific guardrails, auto-linting, secret scanning, and project-specific behavior without waiting for a product feature.
At the same time, this is the kind of flexibility that can get messy fast. If you start rewriting commands, auto-approving actions, and injecting context everywhere, you’re basically building a policy engine around an agent; that can be great, but it also adds a lot of invisible behavior. I’d be curious whether teams will actually maintain these scripts responsibly, or whether they’ll become a pile of clever hacks nobody fully understands six months later.
The persistent agent memory part is especially interesting to me. I think that could be very useful if it’s used carefully for long-lived project conventions or user preferences, but it also raises obvious questions about isolation, drift, and what exactly the agent “remembers.” The article makes it sound like a powerful primitive; perhaps the more important question is whether Anthropic gives teams enough control and transparency to trust it.
If I were using Claude Code heavily, I’d probably start with the boringly practical stuff first: read-only auto-approval, type checks on save, secret scanning, and maybe a dry-run guard for destructive commands. The more ambitious pieces — persistent memory, self-updating agent behavior, custom model selection inside skills — are intriguing, but I’d want to see them in a tightly controlled project before I let them anywhere near a real production workflow.
The broader takeaway is simple: Claude Code looks much more configurable than its docs suggest, and the source code exposes a lot of sharp tools. That’s great news for power users, as long as they treat those tools like infrastructure, not magic.