Claude Code Function Hooks: What They Are, Explained

Function Hooks is not an Anthropic announcement. It is a community-authored proposal on the public anthropics/claude-code GitHub repository, and its own text says so directly: whether it becomes a real Claude Code feature depends on how loudly developers ask for it. That distinction matters for how to read everything else in this piece.

• What it is: a proposed hook type where plugins are TypeScript functions that wrap Claude Code's engine in-process, instead of shell scripts reacting to it from outside.
• Core mechanism: a shared, parameterised $ object carries every side effect a hook can perform, and hooks compose via a next() continuation, registration order determining nesting, the same pattern Express and Koa use for middleware.
• Headline demo: Claude Code generates and loads a working secret-redaction plugin from one natural-language sentence, no hand-written TypeScript required.
• Status: proposal stage only. Opened 3 September 2026, no shipping date, no committed build. It ships if, in the issue's own words, the community response says it should.

It helps to be precise about the baseline, because "Claude Code hooks" already exists as a shipped, documented feature at code.claude.com/docs/en/hooks, and the proposal is explicitly an addition to that system rather than a replacement announcement from Anthropic itself.

Today's hooks are configured in settings.json (user, project, local, or enterprise-managed), organised by matchers that can target a tool name exactly or via regex. Lifecycle events include things like PreToolUse, PostToolUse and SessionStart, and a hook returns output that tells Claude Code whether to block an action and what feedback to surface. It is a genuinely useful safety and automation layer, and it works because it is simple: any language that can read stdin and write stdout can be a Claude Code hook.

That simplicity is also the ceiling. A shell-command hook cannot draw a UI element, cannot hold state across calls without its own storage, and needs a separate PreToolUse/PostToolUse pair to wrap a single action rather than genuinely wrapping it the way middleware would. Function Hooks is aimed squarely at that ceiling.

The proposal lives at GitHub issue #91870 on anthropics/claude-code, opened by contributor @poteat on 3 September 2026, tagged area:hooks, area:plugins and enhancement. Its stated goal is to make plugins "10x more powerful", and its core pitch is a single sentence worth quoting directly:

"Function Hooks let you modify CC very deeply, while still being safe through side-effect tracking over a parameterized $ object, and while composing neatly using a registration-order-based 'next' continuation model a la Express, or Koa."

Four hook types are described. Restricting hooks can deny a behaviour outright, for safety and control, the closest analogue to today's PreToolUse blocking. Component hooks can modify props or wrap the render output of Claude Code's own UI components, which today's shell hooks simply cannot touch. Event hooks catch interactions such as a UI button press. And a single audit hook registered on a wildcard * can observe every event that flows through the system, giving a full activity log without instrumenting each event type by hand.

The mechanism the proposal calls an "effect-parameterised continuation model" is really an access-control design wearing a syntax choice. Every side effect available to a hook, writing to the UI, editing a file, logging, registering a tool, is a named method on one object, written with the sigil $. The issue calls that sigil "non-negotiable", with a knowing nod to jQuery's own $ convention.

The payoff of routing everything through one object is administrative. Because a capability is just a property on $, an administrator can remove that property before a plugin ever sees it, and everything downstream of that plugin in the middleware chain loses access to it too. The proposal frames this explicitly as a hierarchy: admins can prepend hooks to establish control first, ordinary plugins append their own defaults afterwards, and admins can strip affordances from $ to prevent every plugin below them from ever reaching a capability, rather than relying on each plugin to self-police.

Composition follows the same registration-order logic Express and Koa developers already know: the first hook registered wraps everything that runs after it, calling next() to hand control to the next hook in the chain, and to itself again on the way back out. That gives a single hook the ability to act before, after, during, or instead of the event it wraps, and to modify what gets passed onward, a materially richer set of positions than a PreToolUse/PostToolUse pair offers today.

Rather than a spec document alone, the issue ships nine short video demonstrations, organised into three tiers, plus a linked architecture PDF (Function Hooks Core Architecture). The basic series, each around 60 seconds, covers a hook written as a plain function with full editor autocomplete, a hook that denies an action for safety, a hook that modifies a rendered UI component's props, and an admin hook removing capabilities from $.

The advanced series covers middleware-style nesting by registration order, a single hook function that works identically whether Claude Code is running in the terminal or the desktop app, and a wildcard audit hook building a complete event log. Two longer case studies, roughly two minutes each, close the issue out, and one of them is the reason this proposal is getting attention beyond the usual developer-tools crowd.

The case study titled "One sentence. One plugin." is the clip driving most of the coverage of this proposal, and for good reason. The prompt given to Claude Code is a single instruction: make a plugin that redacts high-entropy secrets from tool output, and tells the model how many it replaced. From that sentence alone, Claude Code writes the TypeScript, registers it as a Function Hooks plugin, and the redaction behaviour is live, without the developer opening an editor.

That is a materially different claim from "you can write a hook in TypeScript now instead of bash". It is a claim that the hook API is now regular and typed enough that Claude Code itself, which is already good at writing TypeScript against a well-specified interface, can reliably generate working middleware for an arbitrary described behaviour. If that generalises past the redaction example, it turns Function Hooks from a power-user feature into something closer to a natural-language plugin generator, where the hook API design is effectively doing the work of a domain-specific language for Claude Code customisation.

The second case study, "Change what Claude Code shows", applies the same idea to privacy rather than security: a plugin that hides sensitive values on screen until the user hovers over them, aimed at making it safer to share a screen mid-session without a live secret sitting in the terminal scrollback.

Coding agents are converging on a similar problem: how do you let a large, fast-moving developer community extend an agent's behaviour without either locking the agent down to a fixed feature set, or opening a security hole every time a plugin runs with full privileges. Shell-command hooks solve that crudely, by keeping the plugin outside the process entirely. Function Hooks is an attempt to bring the plugin inside the process while keeping the same safety property, using capability removal on a shared object instead of process isolation.

That is a similar shape of problem to the one Claude's Skills API addresses on the model-capability side, and to what Claude's enterprise inference hooks address on the server side for data-loss prevention, worth noting because the name overlap has already caused confusion: those inference hooks intercept model input and output at the API layer for enterprise compliance, an entirely different system built for a different purpose than a developer wrapping Claude Code's local CLI behaviour. If Function Hooks ships, Claude Code would have three conceptually distinct "hook" systems live at once, which is worth Anthropic resolving with clearer naming before general availability, whatever the technical merits.

As of 7 September 2026, Function Hooks is not a shipped feature. There is no announced flag, build number or release timeline from Anthropic attached to the proposal itself, and the issue is deliberately framed as bait for community signal rather than a changelog entry: "If you want this, please engage here, the response from the community likely dictates whether this ships or not."

Practically, that means the correct way to track this feature is to watch issue #91870 on anthropics/claude-code directly, react or comment if it is something you want, and treat any third-party guide claiming a specific flag or build number as unverified until Anthropic confirms it through an official changelog entry or blog post. Community engagement, not a leak, is the mechanism this proposal is explicitly designed around.

• Not an Anthropic commitment: this is a community proposal on a public repository, not an official roadmap item. It may never ship, or may ship in a materially different form.
• No shipping date: the issue explicitly makes shipping conditional on community response, with no timeline attached.
• Naming collision risk: Claude Code already has shell-based hooks, and Anthropic separately ships enterprise inference hooks for DLP. A third "hooks" system needs careful naming to avoid confusing developers and administrators.
• Security surface of the demos is self-reported: the safety story rests on the $ capability-removal model holding up under adversarial plugin code, which has not been independently security-reviewed at the time of writing.
• "One sentence, one plugin" is one example: the redaction plugin demo is impressive, but a single case study does not establish how reliably Claude Code can generate correct Function Hooks plugins for arbitrary, more complex behaviours.

Against Claude Code's existing shell-command hooks, Function Hooks trades simplicity for depth: any language can write a shell hook, but only TypeScript, with the specific $/next() API, can write a Function Hook, in exchange for UI access, typed context and in-process state that shell hooks cannot offer. Against a general-purpose plugin framework like a VS Code extension API, the pitch is narrower and more agent-specific: Function Hooks is designed around wrapping an agent's tool calls and UI, not building a general application.

It is also worth placing next to Claude Code's cross-session messaging and the /design skill, two recent Claude Code extensions that shipped as finished Anthropic features rather than community proposals. Function Hooks is earlier stage than either: those are things you can use today, and Function Hooks, at the time of writing, is something you can only watch.

Engage now if you build Claude Code plugins today and hit the ceiling of shell-command hooks regularly, for example needing to modify what the UI actually shows rather than just blocking an action. Commenting on issue #91870 is the stated mechanism for influencing whether this ships.

Watch and wait if you are choosing a hooks strategy for a production Claude Code deployment right now. Build on the documented, shipped hooks system at code.claude.com/docs/en/hooks, and treat Function Hooks as a possible future migration rather than something to design around today.

Ignore for now if your Claude Code usage does not involve plugin authorship at all. Nothing here changes how Claude Code behaves for a developer who is not building or installing custom hooks.

Function Hooks is a well-specified, well-demonstrated proposal for making Claude Code's plugin system genuinely powerful, and it is still just a proposal. The technical design, an in-process TypeScript middleware chain gated by a single capability object, is a coherent answer to a real limitation in the current shell-hook system, and the "one sentence, one plugin" demo is a legitimately striking demonstration of what a well-typed hook API lets an agent do to itself.

None of that guarantees it ships, and the issue says so in its own words. The right posture for now is interest, not planning: watch issue #91870, keep building on the documented hooks system for anything that matters in production, and expect this piece to need an update the moment Anthropic makes an official call on it.