Managing OpenClaw Hooks from the CLI - Enable, Disable, and Install

I wrote recently about OpenClaw's hooks system and why event-driven automation matters for AI agent workflows. That post covered the concepts - what hooks are, why they exist, what problems they solve.

This post is the practical follow-up. How do you actually manage hooks day to day? How do you see what's available, turn things on and off, and install new hook packs from the community? The CLI tooling for this is solid but not immediately obvious if you haven't spent time with it.

Listing Your Hooks

The starting point is seeing what you've got. Run openclaw hooks or openclaw hooks list and you'll get a summary of every hook that OpenClaw has discovered across all your configured directories - workspace hooks, managed hooks, bundled hooks, and any extras you've installed.

Hooks (4/4 ready)

Ready:
  boot-md - Run BOOT.md on gateway startup
  bootstrap-extra-files - Inject extra workspace bootstrap files during agent bootstrap
  command-logger - Log all command events to a centralized audit file
  session-memory - Save session context to memory when /new or /reset command is issued

The output tells you two things immediately: how many hooks exist, and how many are actually ready to run. "Ready" means all the hook's requirements are met. If a hook needs a specific config value or a workspace directory and those aren't set up, it'll show as not ready.

For more detail, add --verbose. This shows you the missing requirements for any hook that isn't eligible, which is exactly the information you need to fix things. If you need to pipe this into another tool or script, --json gives you structured output.

openclaw hooks list --verbose
openclaw hooks list --json

There's also openclaw hooks check which gives you just the summary numbers without the full list. Useful if you just want to quickly verify that everything's healthy after a config change.

Getting Hook Details

When you want to know exactly what a specific hook does, where it lives, and what events trigger it:

openclaw hooks info session-memory

This gives you everything - the source directory, the path to the hook's handler, its homepage URL, and which events it responds to. For the session-memory hook, that's command:new and command:reset. It also shows you its requirements and whether they're met.

I find this particularly useful when evaluating whether to enable a hook. Before I turn something on, I want to know exactly what events it subscribes to and what it's going to do when they fire. The info command gives you that clarity.

Enabling and Disabling Hooks

Here's something that catches people out: workspace hooks are disabled by default. Just because a hook appears in your openclaw hooks list doesn't mean it's active. You need to explicitly enable it.

openclaw hooks enable session-memory

This updates your OpenClaw config file (typically ~/.openclaw/openclaw.json) to set that hook's enabled flag to true. After enabling, you need to restart the gateway for the change to take effect.

Disabling works the same way:

openclaw hooks disable command-logger

Again, restart the gateway after disabling.

This explicit opt-in model is a deliberate design choice, and I think it's the right one. Workspace hooks could contain anything - they're user-created code that runs in response to agent events. Having them auto-enable would be a security risk, especially in shared environments. The fact that you have to actively choose to turn each one on means you've at least looked at what it does.

One exception: hooks managed by plugins can't be enabled or disabled through the hooks CLI. You control those through the plugin system instead. The hooks list output makes this clear by showing plugin:<id> next to plugin-managed hooks.

Installing Hook Packs

Beyond the bundled hooks that ship with OpenClaw, there's a growing ecosystem of hook packs you can install. The installation goes through the plugins system now (the old openclaw hooks install still works but prints a deprecation warning).

# From npm
openclaw plugins install @openclaw/my-hook-pack

# From a local directory
openclaw plugins install ./my-hook-pack

# From a local archive
openclaw plugins install ./my-hook-pack.zip

# Link a local directory without copying
openclaw plugins install -l ./my-hook-pack

The installer supports npm packages, local directories, and archive files (.zip, .tgz, .tar.gz, .tar). When you install from npm, it runs with --ignore-scripts for safety - a sensible default that prevents install scripts from running arbitrary code.

There's a nice safety feature around prerelease versions too. If you run a bare install or use @latest and npm resolves to a prerelease version, OpenClaw stops and asks you to explicitly opt in with a tag like @beta or @rc. This prevents you from accidentally running unstable code in your agent workflow.

The --pin flag records the exact resolved version in your config, which is useful for reproducibility. If you're setting up OpenClaw across a team, pinning ensures everyone runs the same hook versions.

When you install a hook pack, OpenClaw copies it to ~/.openclaw/hooks/<id>, enables the hooks, and records the installation metadata. The --link flag is an alternative that adds the directory to your extra hook paths without copying - handy during development when you want changes to take effect immediately.

Updating Hook Packs

For npm-based hook packs, you can update individually or all at once:

openclaw plugins update @openclaw/my-hook-pack
openclaw plugins update --all

There's a --dry-run flag that shows what would change without actually writing anything. Use this first if you're cautious about updates breaking your workflow.

One thing I like is the integrity checking. If you've previously installed a hook pack and its hash was recorded, OpenClaw will warn you if the hash changes on update. This catches cases where a package was republished with different content at the same version - something that shouldn't happen but occasionally does in the npm ecosystem.

The Bundled Hooks Worth Knowing About

OpenClaw ships with several bundled hooks, and three of them are particularly useful:

session-memory saves your session context when you issue /new or /reset. The output goes to ~/.openclaw/workspace/memory/ as a timestamped markdown file. This is probably the first hook you should enable. Without it, every new session starts completely cold. With it, the agent can reference what happened in previous sessions.

bootstrap-extra-files injects additional files during the agent bootstrap process. If you work in a monorepo and have AGENTS.md or TOOLS.md files in subdirectories, this hook ensures they get loaded even if they're not in the root workspace directory. It's a small thing, but it makes working in large repositories much smoother.

command-logger writes every command event to a centralised audit file. This is more useful than it sounds. When you're trying to figure out why something happened in a previous session, or when you want to track usage patterns across your team, having a complete command log is invaluable.

Practical Tips from Our Experience

We've been running OpenClaw for a number of our internal AI agent workflows at Team 400, and here's what we've learned about hooks management.

Start with session-memory enabled, everything else disabled. Session memory is the highest-value hook with the lowest risk. It doesn't change agent behaviour - it just preserves context. Enable it first, use it for a week, and then evaluate what else you need.

Use openclaw hooks check after any config change. It's a quick sanity check that confirms your hooks are in the state you expect. We've had cases where a config file edit accidentally disabled something, and the check command caught it.

Be careful with workspace hooks in shared environments. If multiple people contribute to the workspace hooks directory, review changes the same way you'd review code. A poorly written hook can slow down agent startup or produce unexpected side effects.

Keep hook packs pinned in team setups. When everyone on the team runs the same hook versions, debugging is much simpler. Use --pin on install and coordinate updates deliberately.

If you're building AI agent workflows and want to get more out of OpenClaw's automation capabilities, we run AI agent development projects where hooks and lifecycle management are a core part of the architecture. We also offer managed services for OpenClaw if you want the platform running without having to manage all the moving parts yourself.

For a deeper look at what hooks can do beyond the CLI management, check out the OpenClaw hooks documentation.