Combine Claude Code and Your Favorite IDE

The Essential Claude Code Shortcuts

Targeting the Proper Context with Claude Code

Automate Tasks in Claude Code with Slash Commands

The Cost of Context in Claude Code

Protect Secrets from Being Read by Claude Code

Organizing Personal and Project Settings in Claude Code

Customize Global User Settings and the Status Line in Claude Code

CLAUDE.md Initialization and Best Practices in Claude Code

Type-Safe Claude Code Hooks with Bun and TypeScript

Rewrite Prompts on the Fly with UserPromptSubmit Hooks

Inject Live Data with Custom Hook Functions

Generate Multiple Solutions with Template-Driven Hooks

Block Prompts with Hook Guardrails

Block Tool Commands Before Execution with PreToolUse Hooks

Guide Claude Code with Rich PreToolUse Feedback

Enforce Global Rules with User-Level PreToolUse Hooks

Unleash Claude’s raw power directly in your terminal. Search million-line codebases instantly. Turn hours-long workflows into a single command. Your tools. Your workflow. Your codebase, evolving at thought speed.

claude-code

Claude Code Essentials is the starter kit I wish existed when I first opened Claude inside VS Code. These lessons capture the shortcuts, workflows, and mental models that make the extension feel like an extension of your editor instead of a detached chat window. You’ll see how the IDE bridge provides context, how to move fast in the Claude terminal, and how to give the model precisely what it needs without drowning it in noise.

Each module is a focused walkthrough: installing the extension, targeting the proper context, automating tasks with slash commands, managing token costs, protecting secrets, organizing shared settings, customizing your status line, and keeping a living `CLAUDE.md`. Dip into whichever lesson solves your current problem or watch them in order for a full onboarding path.

New lessons will be added here over time as Claude Code evolves. Check back for fresh tips, deeper dives, and updates that help you stay confident in this constantly improving environment.

Claude Code Essentials

To combine the power of Claude Code and IDEs, you'll need the VS Code extension. Once it is installed, the chat panel understands which files you have open, what you have selected, and the diff it should propose back to you. This lesson is the baseline setup that unlocks every workflow that follows.

## What you’ll learn

- Install and sign in to the Claude Code extension inside VS Code (or Cursor).
- Give Claude Code rich context so it understands your files, selections, and changes.
- Launch the chat fast, reconnect the IDE bridge, and apply diffs with confidence.

## Install the Claude Code extension

1. Open VS Code (or Cursor) and press `Cmd+Shift+X` to open the Extensions view.
2. Search for `Claude Code` and install the official Anthropic extension.
3. Click **Sign in** when prompted and connect with your Anthropic account.
4. Accept the workspace access request so the extension can stream file context.

> If you are in Cursor the extension ships preinstalled—still open the Extensions view to confirm it is enabled and updated.

## Why the extension matters

- **Context bridge:** The extension tunnels your open file, selection, and tabs so Claude Code replies with precise edits instead of generic answers.
- **Diff safety:** Responses arrive as proposed diffs inside VS Code, letting you inspect and apply or discard changes line by line.
- **Command surface:** Slash commands, quick actions, and keyboard shortcuts live in the extension; without it, the Claude CLI runs blind.

## Tips & tricks once it is installed

- **Open Claude instantly:** `Cmd+Escape` opens the panel. Prefer the built-in terminal? Run `claude` from an editor terminal.
- **Reconnect the IDE bridge:** If you see "IDE disconnected," type `/ide` in the Claude terminal to re-establish context streaming.
- **Pin the extension:** Drag the Claude icon to the top of the Activity Bar or set up a custom keybinding so it is always one shortcut away.
- **Verify context:** Watch the prompt header for `@ In FILENAME` or `@ N lines selected` before you send a request.

## Try it

Prompts:
~~~markdown
Explain what this selected function does and list any obvious tests.
~~~

~~~markdown
Refactor this component to use a custom hook. Keep behavior identical.
~~~

Terminal:
~~~bash
claude
/ide
~~~

[00:00] Using VS Code or one of the variants like Cursor, hit command shift P, search for install extensions, and then search for Clod, and you'll see Clod code for VS Code has an extension. Go ahead and click install. I've already installed it, and then once that's installed we'll go ahead and check out the keyboard shortcuts with command shift P. We'll search for shortcuts, open the menu, search for Clod here, and you can see we have a couple of main shortcuts, one for running the extension and one for insert at mentioned. We'll start with command escape for running the extension, And you'll see this is essentially the same as starting a new terminal in editor area to the side, and then running Clod.

[00:38] Now because this offers a bit more flexibility with the ways that you launch Clod, I will definitely be using the terminal more. And as a note, if you ever get this message that the IDE is disconnected. If you type slash IDE you can select the IDE to reconnect and you'll see now this one is disconnected. So I'm going to close out Cloud Code, terminate the process, then reconnect over here, And then I'm going to add a keyboard shortcut for create new terminal in editor area to the side. So create new terminal, and it looks like it'll be this one right here.

[01:09] We'll click add key binding. I'll use command T. The existing commands aren't too important to me, and this input does have search history, so I'll press up and go back to create new terminal. So again command-T, hit enter, and now at any point I can hit command-T and open a new terminal to the side. I can type in clod or clod with any of the settings because the extension version of this doesn't allow you to pass in any settings.

[01:31] So with the IDE connected, represented by this little blue circle, anytime we have a file I'll go ahead and create a readme. I'll go ahead and press command-p, type readme.md, down to create a new file with that path. I'll just type in hello world, and you'll see as soon as this has content that in readme shows up. So with readme in context, any command I give will assume that that's where I want to make the change. So if I say please translate to French, hit enter, you'll see it assumes readme is the proper context, and then because we have the extension installed and we're connected to the IDE, we also get a nice diff that appears any time this dialogue of asking us to accept changes appears.

[02:11] So we'll go ahead and allow this change. The diff disappears and now the readme is updated based on our current session. Then in the file if I create another line I'll say hello world again. I can also select this line and you'll see one line selected here. So if I say translate to Spanish, let this run, now you'll see it's only impacting that individual line.

[02:30] We're getting the diff again and it's only operating on the selection and using that as the main context. So I hit enter to allow the change and then if I create another file we'll call this one license.md, create the file, and I'll just dictate Please use however you want. You'll see that we're now in license MD, but if we want to modify multiple files we can hit this shortcut of command option K. We'll go back to Clod and you'll see it here. Insert at mentioned.

[02:58] So if I go to my license, I'll hit command option K. That'll insert the entire license file. If I select a line here I can command-option-k and insert only the selected line. So if I add a few more lines, hello world, go back to my license, hello world, I'm going to delete this reference, and then select this line with command-option-K. We now have line 3 on license and line 3 on the readme selected.

[03:24] So if I say translate to Italian, you can see it brings those lines into context, and it looks like it's trying to modify line 5. I must have not been explicit enough since so far we've been translating English words, and we had the entire file in context previously. So I'm going to say no, tell Cloud what to do differently by hitting escape, and say please only translate the selected lines. So we'll run this back, and you can see this time it's translating line 3, so we'll accept this, and then it swaps over to the license. We get the nice diff.

[03:53] I'll accept this, and then our selected changes are done.



https://app.egghead.io/api/v1/lessons/combine-claude-code-and-your-favorite-ide~doycf/transcript

Claude Code interactive mode has a few key shortcuts to help you stay productive. Restarting a session, editing like Bash, and rewinding conversations all help you feel more comfortable with each session.

## Core shortcuts

- **Resume instantly**  
  ```bash
  claude --continue
  ```
  Reloads the previous session and context after a crash, restart, or closed editor.

- **Rewind conversation**  
  Double‑tap **Escape** in an empty input to browse history and restore to an earlier point.  
  > Rewinding resets the chat, not your files—pair it with version control or explicit undo prompts for code changes.

- **Explicit undo/redo**  
  Ask Claude to revert the last change, then use your shell history to re-run or tweak the prior prompt.
  ```markdown
  Please undo the previous change to <file>.
  ```

- **Edit like Bash**  
  `Ctrl+A` / `Ctrl+E` start/end of line • `Option+F` / `Option+B` word forward/back • `Ctrl+W` delete previous word • Double‑tap **Escape** clear input • `Ctrl+C` twice hard exit

## Try it

Prompts:

```markdown
Please translate this entire file to German.
```

```markdown
Undo the change and propose a simpler version.
```

[00:00] You can close the terminal tab with command-w and it will warn you before terminating the session. But if you ever accidentally close the terminal or close the editor or your computer restarts and you need to continue from your previous session, type clod dash dash continue, hit enter, and then it'll pick up right where you left off. When the input is empty you can now double tap escape, and you can essentially rewind the conversation to one of the previous user commands. So if we rewind to translate to Spanish, hit enter, you'll see that it essentially clears out the previous messages, but be aware it does not undo any of the changes. If you want to undo changes, please translate this entire file to German, and if you're not using git you essentially have to say please undo the previous change.

[00:45] Then let that run and allow that change. Then if you want to redo the change, the input actually keeps track of the history of commands, so pressing up can bring you back to a previous command that you ran. So simply pressing up and down will help you navigate the history. Then within the input it will respect bash navigation shortcuts such as ctrl-e to jump to the end, ctrl-a to jump to the beginning, option-f and option-b to jump forward and back, and then one I use a lot since I dictate is ctrl-w for deleting a word. So I can jump back a word and delete a word with Option-B then Ctrl-W.

[01:19] To completely clear out the input, simply double tap on escape, or fire off a hard exit with Ctrl-C and Ctrl-C again will completely exit out, and then we can clod continue to bring it back.



https://app.egghead.io/api/v1/lessons/the-essential-claude-code-shortcuts~dgsee/transcript

Targeting the proper context means giving Claude Code only what it needs. Use file and selection scope plus fast at-mentions to assemble precise prompts.

## Choose the right scope

- **Whole file:** Open the file and prompt—Claude reads it automatically.
- **Selection:** Highlight a block; the prompt scopes to only those lines.
- **Multi-file:** Build context by adding several files/selections to the same prompt.

## Two fast targeting workflows

1) **At-mention with `@`**  
Type `@` in the Claude prompt to fuzzy-find any file/dir and insert it into your message.

2) **Editor-first + Insert At-Mentioned**  
- `Cmd/Ctrl+P` to open a file quickly  
- Trigger **Insert At-Mentioned** to add that file/selection to the prompt  
- Repeat to build multi-file context

> Tip: Bind **Insert At-Mentioned** to a convenient key (e.g., `Option+T`) for rapid multi-file assembling.

## Try it

Prompts:
~~~markdown
Summarize these two files and identify cross-cutting concerns.
~~~

~~~markdown
Only update the selected function to remove duplication.
~~~

vscode

[00:00] Type the at sign and then you can fuzzy search for any file to include that in the context of your current conversation. This also works with directories if we want to include the source directory, or you can navigate down the directories doing search as normal. When you find the file you want, hit enter. It will complete the entire path to the file, and then add a space. So you're essentially telling Cloud to read these files as part of the prompt.

[00:23] Now this does support fuzzy search, so you can type JSON and navigate up and down to the file you want, or at tsx, and then you can even type the name of the file after tsx like wordlist, hit enter, and it will expand it. Or part of the path, so at lib, then you can select that, backspace, and invoke the search again, and type out store to quickly navigate to files inside of directories. Then currently the quickest way to clear out a file you've added is just ctrl-w to delete word. Since I'm much more proficient with using cursor to explore files, I like to update this command to option-t or alt-t, and then with command-p when I'm browsing files where I can type things like lib and then store to get this true fuzzy matching, then hit enter and then option T will add the file to the cloud input. Then I can invoke another search.

[01:17] I'll search for components, and then select, hit enter, option T, and bring in files that way. So for me the cursor navigation and cursor search is just far superior, because I'm often thinking in directory and file name, or even something like subscription store where I want to match on partials of the word to filter them out, since so many files usually have consistent naming patterns. And one thing to note here, if you're ever focused over in your editor and you want to jump focus over to this panel, Command 1 will focus on the editors on the left. Command 2 will focus on the second one. And say if we hit Command T again to open another session, Command 2 will jump back here, and Command 3 over here, 2, 1, and it becomes much easier just to jump between editor, clod sessions, and so forth.

[02:03] So I can jump to 3 with command 3, hit command W, close that out, and manage our sessions like that. Now an important thing to note here is if I say something like, please summarize all of these files, and let this run, you'll see it'll start to read each of the files, because they're automatically brought into context. But as an example, if I clear out this session, which essentially starts a brand new session, and I reference a much longer file like package lock, and I say please summarize this file, you'll see that approach it'll take, instead of immediately invoking read, it will attempt to read it in chunks, so reading 100 lines at a time. And you can hit ctrl-o to see exactly what it's doing. Since ctrl-o shows the detailed transcript, You can see the commands it's running and Ctrl-O to go back.

[02:49] But something I'll do often if I want to force multiple large files and context is to use a tool called RepoMix. Now you'll see if I start a new terminal and I run RepoMix help, You'll see we have a lot of options here. The important ones are going to be repo mix include, and I'm going to include the entire source directory, and then standard out to make sure it's all printed out in the terminal, to make sure the contents of all the files are printed out the terminal. So once I hit enter and I scroll back up you will see all of the files and all of their contents. Now if I run the same command with output show line numbers this time we'll get all the contents with all of their line numbers.

[03:29] And this way we can force everything in a directory into context. So I'll clear this out. I'll type to enter command mode, type repo mix, include, source, then standard out, and output, show line numbers, hit enter, And now all of this was forced into context. If we hit Ctrl-O, you can see the entire context which was brought in. Ctrl-O will toggle back.

[03:53] And now if I say summarize all of these files, you'll see it no longer has to read individual files, and it doesn't have to read them 100 lines at a time. You forced all of that context into Cloud to save all of that time it would have had to use searching and reading, which makes a lot of larger tasks like this much faster at the cost of adding a lot of context up front. So even though this video you're watching was edited, that prompt literally only took about three seconds to run.



https://app.egghead.io/api/v1/lessons/targeting-the-proper-context-with-claude-code~2i20r/transcript

Automating Claude Code tasks starts with reusable commands. Use `repomix` to bundle big context, then wrap it in a slash command so the workflow runs with a single trigger.

## Ad-hoc: run repomix from chat

```bash
! repomix --include "src" --stdout --output-show-line-numbers
```

Follow with a prompt:

```markdown
Given the bundled code above, outline the module boundaries and list obvious seams for refactoring.
```

## Make it reusable: a custom slash command

Create `.claude/commands/repomix.md`:

```markdown
---
allowed-tools: Bash(repomix:*)
argument-hint: [glob pattern] [user prompt]
---

!`repomix --include "$1" --stdout --output-show-line-numbers`
```

Use it:

```bash
/repomix src "Summarize the codebase and propose a dependency graph."
```

### Why this pattern works

* **Abstraction:** Hide flags and syntax you’ll forget.
* **Speed:** One command, big context.
* **Consistency:** Teammates can reuse your command, too.

[00:00] So I can't show how to run a bash command without immediately following it up by showing how to write a custom command. So I'm going to create a file in a .clod slash commands directory and call it repomix.md. So we'll create this file and close the other windows. And commands allow you to add a syntax with the exclamation point followed by backticks where you can insert a command that you want to run. So cursor recognizes the command which we talked about earlier which is repo mix include and then I'm going to extract this so that this becomes the first argument passed in.

[00:37] Then I'm going to add some front matter, so dash dash dash dash dash dash, and we're going to add two things, an allowed tools and an argument hint. I will cover this in more detail in future lessons, but essentially this allows us to run RepoMix with a command without having to allow it in any other settings. And then in argument hints we get to add a glob pattern, which becomes the $1 down here. And I'm going to include this in quotes actually. And then the user prompt would be $2 if we want to include that, but we don't actually need that inside this command, since the AI will just essentially run it.

[01:14] So now instead of remembering this entire syntax for whatever command I want to run, I can open a new Clod session, run Clod, and now I can say slash repo mix, hit tab, I'll type src for the source directory, and then in quotes, just because I kind of treat this like invoking a command, and this is essentially going to be this argument here. I'll just say, please summarize all of these files. You'll see once I hit enter that it's allowed to run one tool, and that this command gets run before this starts working. So we've brought in the entire context of the source directory and tossed it against this prompt here. So you'll see that nowhere in here did it ever call a read or try and parse out files 100 lines at a time or anything, it's just walking through and executing my prompt with the entire context to the best of its abilities.

[02:09] So if I clear this out and do the same thing with, I'll press up, instead of source I'll say source slash lib. This time it's going to summarize all the files in the lib directory and save us from remembering these flags, command name, or anything, and simply tuck it away behind that slash command where it also runs much much faster because It avoids any sort of reads, any sort of round trips. We just dump everything in there in the first pass, and the AI can respond with a single response.



https://app.egghead.io/api/v1/lessons/automate-tasks-in-claude-code-with-slash-commands~ylxki/transcript

The cost of context shows up in the Claude Code window. System prompts, enabled tools, your messages, and large inputs (like `repomix`) all consume tokens you pay for.

## See the budget

```bash
/context
```

You’ll get a breakdown: system/tool overhead, messages so far, and free space remaining.

## Practical guidelines

* **Prefer precise context** (Lesson 03) first; use big bundles only when necessary.
* **Batch expensive operations**: run `repomix` once, then work within that bundle.
* **Use a larger-window model** when you truly need it:

  ```bash
  /model sonnet[1m]
  ```
* **Tradeoffs exist:** more context can improve answers but may increase cost and cause history to compress.

[00:00] Run slash context to be able to see how much space you have left in your conversation before it starts compressing it and you lose valuable knowledge. But also the longer the context gets the more challenging it is for Cloud Code to really zero in on the task that you gave it. So if we look at the current context of an empty session for my current setup, you'll see that I'm using the default model on the CloudMax plan with Opus, which has a total context window of 200, 000 tokens. Simply by starting a conversation you're going to lose about 17, 000 tokens. And the word token essentially means just a few characters like IDE.

[00:36] Just think of it as chunks of text. Then once you start adding in MCP tools, which we'll cover later, and I have Playwright installed and DeepWiki installed both globally, Playwright itself is going to take up another 10, 000 plus tokens, and then the custom agents you add in, which we'll dig into soon, leaves us at only about 170, 000 tokens, because we've already taken up 31, 000 tokens in our context window here. So when I talk about the cost of running a command like this repo mix command, so source and summarize these files, I'll let this run. Once this is done we can check on our context again, and you'll see the cost of that one repo mix command was about 12, 000 tokens because we brought in the entire source directory. So it's definitely something to keep in the back of your mind if you're bringing in a huge bulk of text, whether from documentation or from entire code bases, that you still need to put some limits on it to be able to fit everything into the context window and still get good results.

[01:37] Now you can switch over to in the models. You can switch over to Sonnet, which has a 1 million context mode. And then if we check our context again, you'll see we now have a much bigger budget here. But just be aware the more context you use the faster you hit your rate limits and the faster you take up your context budget. So it will always be a trade-off of better context for better solutions versus running out of context and incurring cost against rate limits or cost against the conversation having to compress itself.

[02:12] There is no silver bullet for the situation, but there are a lot of context engineering tips and tricks we'll go over in future lessons.



https://app.egghead.io/api/v1/lessons/the-cost-of-context-in-claude-code~rku9p/transcript

Protecting secrets in Claude Code starts with permissions. Lock the workspace down with explicit deny rules.

## The risk

```bash
# .env
MY_SECRET="I love peanut butter"
```

## Deny with `/permissions`

1. Open the permissions manager:

   ```bash
   /permissions
   ```
2. Add a **Deny** rule for the project:

   ```markdown
   Read(./.env)
   ```
3. Save to **Project settings (local)**, which writes `.claude/settings.local.json`:

```json
{
  "permissions": {
    "allow": [],
    "deny": ["Read(./.env)"],
    "ask": []
  }
}
```

## Verify the guardrail

Prompt:

```markdown
Please read the .env file.
```

Expected result: the system blocks the read and reports permission denied.

[00:00] So most projects have secrets that they store in .end files or other places that you don't want your AI to have access to. And what you can do in Clod is invoke the slash permissions command. We'll tab over to deny and we'll tell it to deny reading in our current directory the .env file. We'll hit enter and this will create a file once I hit enter here inside of our .cloud directory called settings.local.json and it adds this to the deny list. Now I'm going to hit escape out of here.

[00:35] I cleared out my session and I'll ask it to please read the .env file. It will attempt to call the read tool with .env but get a permission denied warning. So as a primary security measure it's best to set up your deny list first, keep your secret safe, so that even if you're ever exposed to a rogue MCP tool or some sort of prompt poisoning or other security issues that arise from AI dev tooling, Clawd will know that it's never allowed to use this sort of tool on these files.



https://app.egghead.io/api/v1/lessons/protect-secrets-from-being-read-by-claude-code~vd9jk/transcript

Organizing Claude Code settings keeps the team aligned. Separate project rules from personal tweaks so the repo stays clean and flexible.

## Ignore personal settings

Add to `.gitignore`:
```bash
.claude/settings.local.json
```

## Personalize locally

Use the local file for machine-specific tweaks (paths, extra directories):

```json
{
  "permissions": { "allow": [], "deny": [], "ask": [] },
  "additionalDirectories": ["/Users/you/dev/docs"]
}
```

## Share team rules

Commit `.claude/settings.json` for org-wide policies (e.g., deny reading `.env`):

```json
{
  "permissions": {
    "allow": [],
    "deny": ["Read(.env)"],
    "ask": []
  }
}
```

### Merge semantics

Settings **combine**; they don’t override. A project-level **deny** cannot be undone by a local **allow**.

[00:00] Now your settings.local.json should be added to your gitignore. I'll go ahead and create one with the gitignore command. We'll say this is a node project and this just generates one. I'll open it up, gitignore. So just make sure that clod settings.local.json is added in there so that it's removed from git.

[00:21] The reason being that it's quite possible when you're configuring your own settings that maybe you have some documentation you want to add. So let's say an add dir. I want my clod to also be able to look into my dev, kit container, docs directory. And I wanted to remember it for this directory so that now in my settings local json my instance of clod is able to access the docs. So if I clear out the session and I just ask it to please ls the docster, you'll see it has access to that directory and is able to, if I hit ctrl-o, run commands and do things in that directory.

[01:02] Now obviously in other people's machines they won't have this directory set up. They'd want to customize that for themselves and for this specific project. But if you want to hoist something like DENY up into the project level, we can essentially copy and paste this. We'll rename this to settings.json, and this is a file that you would check in. And we're going to remove additional directories.

[01:23] We'll keep readenv, and we'll remove readenv from here. This way this file is checked in and everyone on your project will have the same deny list, and you can have your own custom configuration with your custom paths. If you have custom scripts or custom tools you want to run that are only on your machine you could add those here. And don't necessarily treat your local settings as something that overrides these settings, it's more thinking about it as customizing it for your system. Because if the project level denies this, then adding allow here is not going to override the project level settings.

[02:00] Thanks.



https://app.egghead.io/api/v1/lessons/organizing-personal-and-project-settings-in-claude-code~q7qsw/transcript

Customizing global user settings means Claude Code feels the same everywhere. Use the **user** file for quality-of-life improvements that shouldn’t live in repos.

## Global status line

In `~/.claude/settings.json`:

```json
{
  "statusLine": {
    "type": "command",
    "command": "npx -y @owloops/claude-powerline"
  }
}
```

Open and test:

```bash
cursor ~/.claude/settings.json
claude
```

Result: a uniform status line everywhere (directory, git branch, model, token usage, cost), while project configs stay lean.

[00:00] Now there's also the user level status line which is in your home directory in the .cloud directory slash settings. Now what you're usually going to store here, currently I don't have anything, so we have our gitignored settings, our project settings, and then there's also user settings. And the user settings are found in your home directory in the .cloud directory slash settings.json. So open that up, and I currently don't have anything in here. What you generally store in here are things you want in every single project.

[00:34] For example, the way that your status line shows up any time you open up Cloud. Personally I use this Cloud powerline, and you can see that the way that you configure it, just scroll down and add this block of code to your settings.json. So I'll hit save there. You can read the docs of this repo to customize this however you want, but I'm actually going to remove at latest because I have a general distrust for anything without latest. It's a matter of security always installing the latest package, and if this project depends on something malicious then it gets updated.

[01:08] Just be wary of any MCP or tool or anything that says at latest. I recommend always just ditching it and manually updating. With that being said, now when I open up Claude, you'll see it will initialize this nice status line underneath showing my current directory, my commits, branch, my current model, the number of tokens, and estimated cost. Now if you want to get super nerdy with your status line, go ahead and just fork one of the projects we've shared here and customize it to your heart's content. For me personally, I like Powerline and I don't see any need to tweak it.

[01:41] And so because this is at the user level, any project I open will use this status line. It's not checked into Git, it doesn't impact anyone else, but if you wanted to you could configure a status line at the project level, or you could configure it at the local level as well. You can move any of these settings up and down based on your requirements of ignored, ignored from Git, and just for you, for everybody on the project, and then at the user level settings for every single project.



https://app.egghead.io/api/v1/lessons/customize-global-user-settings-and-the-status-line-in-claude-code~gtxfs/transcript

CLAUDE.md initialization primes Claude Code with a single, evolving source of truth. Use it to record team guidance, keep updates flowing, and separate shared memory from personal notes.

## Generate `CLAUDE.md`

Initialize from the codebase:
```bash
/init
```

## Keep it fresh

* Temporarily allow edits:

  ```bash
  claude --permission-mode acceptEdits
  ```
* Update conversationally:

  ```markdown
  Update the build section to use pnpm instead of npm.
  ```

## Layer private context with file references

Add references in `CLAUDE.md`:

```markdown
@~/.claude/info.md
@./.claude/common-commands.md
```

Example personal file:

```markdown
# ~/.claude/info.md
Favorite Pizza: Turkey
```

To permit reading your user file, grant access in your **user** settings:

```json
{
  "permissions": {
    "allow": ["Read((/Users/you/.claude/**))"]
  }
}
```

### Patterns that scale

* Keep team-wide instructions in `CLAUDE.md`.
* Keep individual notes out of the repo via `@~/.claude/...`.
* Break large docs into referenced modules for faster updates.

**You’ve finished the series.** You can now set up Claude Code, work fast, scale context, manage costs, secure secrets, collaborate via settings, and maintain living project memory.

[00:00] When you run slash init on your project, it will read through your project and create a clod.md file. Now this has a custom prompt from Anthropic which explores the repo and gathers a bunch of information. As this is going through, I'm going to press 2 to allow all grep commands. You'll see that will update my settings local to allow Grip, and it will start reading files like package.jsons and readmes trying to figure out what's important and what's not. This can take a couple minutes, might as well go grab a sandwich.

[00:30] Then finally when it's ready to write a file it will ask us to set the permission mode. And permission mode, when I accept this with 2 or shift-tab, I prefer pressing 1, 2, or 3 as the shortcuts. So I'll just press 2 here. You'll see that's not persisted in my settings.json, it's only persisted for the session itself. And I've essentially given it permission to write and update any file in my project.

[00:53] As always please make sure you're using Git to be able to undo any of those changes. You can also see in your status line that accept edits is now enabled. Now as a quick tip you can just start Clawed, immediately hit shift tab to turn on accept edits, or you can even start Clawed with permission mode accept edits, and you'll see it's enabled by default here. Or you can go into your settings and under permissions hardcode default mode to accept edits. And that way once you launch Cloud, accept edits will always be on by default, which is fairly safe provided you're using git, since you're only telling it it can write files.

[01:34] So now that we have a clod.md file created, we'll look at it here. You'll see that this is isolated to our project, and it gathered the custom commands and architecture, and essentially read through here and verify that everything follows the guidelines that you would expect. Now I'd recommend if you see anything out of place just open up an instance of Clod, fire up Clod again. You'll see thanks to the extension we're already referencing Clod MD. Otherwise you can inline the file and then just dictate the things you'd like changed.

[02:04] Please update all of the npm commands to use pnpm because we always want to use pnpm, and other stuff like that based on version numbers or commands or anything you see on here. Just read through and dictate while you're reading and capture all that information, and it will go ahead and update this for you, rather than trying to tweak everything by hand. Now what gets really interesting here is that if you want custom behaviors inside of your ClawedMD file, which is checked in, you can use what are called file references. I can reference a file on my system called info.md in this directory, and if we open this file up, so clod info.md, you'll see that my favorite pizza is turkey. I'm just using that because even if it hallucinates it's never gonna guess turkey.

[02:49] So if you try and run this, I cleared out everything so it's not influenced by any context. We'll open up Claude. Let's make sure that Claude isn't selected. And I'll even go so far as to disconnect from the IDE so we don't accidentally automatically include some file or context over here. And I'll ask it what is my favorite pizza?

[03:12] And you'll see we get turkey back as the answer because our Claw.md file is essentially inlining this information into this Claw.md memory file. Now if it failed to read this file for you for any reason in your Claw.settings.json file, go ahead and add a permissions allow read. So I'll paste this in here, remove all of these, and add a read to wherever that file would be, such as users, John Lindquist, Cloud, and any file in the cloud directory, or anywhere on your system where you want to store those types of files that will be inlined into your Claw.md. This way you can check in your Claw.md file and have various information about your own individual role on the project, maybe some common resources, your documentation, things you always want in context based on your personal workflows on the project. And you can include pretty much as many of these file references as you want, and even nest file references in there.

[04:13] And it becomes up to you on how large your claud.md file gets. If you want to break out some of these sections, let's say common commands, we'll cut that and we'll at and drop this in our current clod directory. Common commands.md and create a file called clod common commands.md Drop this in here. So now this will be inlined here, and if we start another session we'll say clod what are some of our common commands. And again make sure that files are closed so we're not accidentally bringing in context through the extension.

[04:48] So if I say what are some common commands, and it looks like I misspelled the path in my Claw.md. Common commands. So we'll try this again. And one tip here if you're trying something out and you want to run it over and over, is you can provide an initial prompt with what are the common commands. Rather than waiting for the session to start and then typing in the initial prompt, you can actually just provide the initial prompt right away.

[05:13] So you can see that we got the common commands out of CloudMD without ever invoking a read tool. It's just automatically provided. So now we have that. We have what's my favorite pizza, and all of this is provided without ever invoking read tools, with a caveat being this all comes at the cost of context. So the best practices here essentially are anything in your main memory file should be things that apply to the entire team and the entire project.

[05:39] For example, if you expect everyone to read from GitHub issues then put information on how to access and update GitHub issues. But anything else that's not project critical you can export that into file references where individual users on the team can customize how they want their version of Cloud to behave. Then you could check in all of these files into various repos for various team members, for various squads on your team, or however you want to set that up to create that clean separation between project memories and user memories.



https://app.egghead.io/api/v1/lessons/claude-md-initialization-and-best-practices-in-claude-code~jae0x/transcript

Type-safe hooks turn Claude Code's JSON payloads into structured TypeScript. Use Bun to parse stdin, the official SDK for types, and skip the `jq` gymnastics.

## The shell hook problem

Basic hooks work but lack structure:
- JSON parsing needs extra tools
- No autocompletion or type checking
- Complex logic gets messy fast

## Bun + TypeScript solution

Set up a typed hook environment:

```bash
mkdir .claude/hooks && cd .claude/hooks
bun init
bun i @anthropic-ai/claude-code
```

## Write the hook

Create `.claude/hooks/UserPromptSubmit.ts`:

```typescript
import { type UserPromptSubmitHookInput } from "@anthropic-ai/claude-code";

const input = await Bun.stdin.json() as UserPromptSubmitHookInput;
const { cwd, prompt } = input;

// Example: log hook data
await Bun.write(
  ".claude/hooks/last-prompt.json",
  JSON.stringify({ prompt, cwd }, null, 2)
);
```

## Connect it

Update `.claude/settings.local.json`:

```json
{
  "hooks": {
    "UserPromptSubmit": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "bun run .claude/hooks/UserPromptSubmit.ts"
      }]
    }]
  }
}
```

Test:
```bash
claude
hello world
```

### Why this pattern scales

- **Type safety:** SDK types catch errors at write-time
- **One-line parsing:** `Bun.stdin.json()` replaces complex pipes
- **NPM ecosystem:** Use any package for advanced automation

[00:00] When you run the slash hooks command, you'll be prompted to create a hook. I'll select the user prompt submit hook, hit enter to add a new hook, and we'll just have our command be echo hello. We'll add this to our local settings. So then if we look at our project, you'll see we now have a clod directory and in that clod directory a settings local json which has hooks, user prompt submit, matching on everything, and assigning the hook to echo hello. Now what we're going to do to make it much easier to consume the input from the hook is create a .clod hooks directory.

[00:38] And in this clod hooks directory I already have bun installed globally, and I'm going to bun init in this directory with a blank project. Now from here I'm going to bun install the anthropic-ai slash clod code and this will bring the clod code SDK into that directory. So if you look at our hooks directory we have a bun project and I'm going to rename this index file to user prompt submit so that it lines up with the name of the hook itself. So now instead of echo hello we're going to bind this to bun run and pass in the path to our user prompt submit file so that anytime we submit a user prompt it triggers this. So now we can play with our user prompt submit file and configure how we handle the input.

[01:27] Now the amazing thing about bun is that it provides us with a bun.standardIn.json method which we can await from top level and get the input from this, meaning that the payload that is coming in when this is called will automatically be an object we can play with. And because we have the Cloud SDK installed in our project we can grab the user prompt submit hook input type and cast this JSON as that input, which means that we now have the type information if we want to grab something like the current working directory, or we want to grab the prompt that was sent in, we can destructure that from the input and then just as a demo we'll use bun.write to write a file and we'll just call this file user.prompt.submit and we'll just read JSON stringify this and we'll put together a message like message is the prompt was prompt in the current working directory and then jump into json stringify and change this message. Let's word wrap in here so you can see everything. So now every time the user submits a message in Clawd it will invoke this hook, we'll get the input, we'll rip out the current working directory in the prompt, and then write it to a file.

[02:40] Now if we just go back up to our project root, our Clawd hook button project, invoke Clawd, I'll say hello world, hit enter, and you'll see this JSON file get generated. The prompt was hello world in this directory.



https://app.egghead.io/api/v1/lessons/type-safe-claude-code-hooks-with-bun-and-type-script~76nmz/transcript

Rewriting prompts with hooks lets you create custom shortcuts and transform simple commands into complex instructions. Use TypeScript to intercept, modify, and replace prompts before Claude sees them.

## Basic prompt transformation

Read stdin, modify, and output:

```typescript
import { type UserPromptSubmitHookInput } from "@anthropic-ai/claude-code"

const input = await Bun.stdin.json() as UserPromptSubmitHookInput

// Transform any input into a joke request
console.log(`Make a joke about ${input.prompt}`)
```

Test it:
```bash
claude
Pizza
# Output: "Why did the pizza maker go to therapy? He had too many toppings to deal with!"
```

## Custom command syntax

Add conditional logic for specific patterns:

```typescript
import { type UserPromptSubmitHookInput } from "@anthropic-ai/claude-code"

const input = await Bun.stdin.json() as UserPromptSubmitHookInput

if (input.prompt.endsWith(":plan")) {
  // Strip :plan and rewrite
  const task = input.prompt.replace(/:plan$/, "")
  console.log(`Create a detailed step-by-step plan for: ${task}`)
}
// No log = original prompt passes through
```

Usage:
```bash
# Regular prompt - unchanged
> That's funny

# Custom syntax - transformed
> build a CLI app :plan
# Becomes: "Create a detailed step-by-step plan for: build a CLI app"
```

### Pattern ideas

- **`:json`** - Wrap response in JSON format
- **`:test`** - Add "write tests for" prefix
- **`:explain`** - Transform to ELI5 explanation
- **`/v(5)`** - Generate N variations (see lesson 13)

## Try it

Prompts:
```markdown
pizza
```

```markdown
hello world cli :plan
```

[00:00] So now that we have our user prompt submit trigger on every user prompt, anything you console log at the end of your hook can be used to essentially rewrite the prompt. So I can say make a joke about the input, and now when I launch clod here and I say pizza, you'll see that it makes a joke about pizza. So you're essentially intercepting the original prompt and then providing a new one. And this can give you some really interesting options like if the input prompt ends with, and then you can come up with some syntax for your project like colon plan, then we'll intercept the prompt and we'll now log out, create a plan for our original prompt. So now if I enter that's funny you'll see it doesn't create a plan, but if I say a hello world CLI colon plan hit enter you'll now see a I'll create a plan for building a hello world CLI application.



https://app.egghead.io/api/v1/lessons/rewrite-prompts-on-the-fly-with-user-prompt-submit-hooks~76rrt/transcript

Injecting live data through hooks eliminates copy-paste workflows. Create custom functions that fetch real-time info and rewrite prompts with fresh context before Claude sees them.

## The static context problem

Without hooks, live data needs manual steps:
- Find the data source
- Copy the response
- Paste into prompt
- Waste context tokens

## Dynamic data injection

Build a `load()` function that fetches on demand:

```typescript
import { type UserPromptSubmitHookInput } from "@anthropic-ai/claude-code"

const input = await Bun.stdin.json() as UserPromptSubmitHookInput

// Match load(username) pattern
const match = input.prompt.match(/load$(.*)$/)
if (match) {
  const username = match[1]
  const response = await fetch(`https://api.github.com/users/${username}`)
  const data = await response.json()

  // Replace load() with actual data
  console.log(
    input.prompt.replace(
      `load(${username})`,
      JSON.stringify(data, null, 2)
    )
  )
}
```

## Use it naturally

Type prompts with your custom function:

```markdown
How many repositories does John have?
load(johnlindquist)
```

Claude receives:
```markdown
How many repositories does John have?
{
  "login": "johnlindquist",
  "public_repos": 247,
  ...
}
```

### Extension ideas

- **`weather(city)`** - Inject current conditions
- **`stock(AAPL)`** - Latest price data
- **`db(query)`** - Internal database results
- **`jira(PROJ-123)`** - Issue details

## Try it

Prompts:
```markdown
How many repos does Octocat have?
load(octocat)
```

[00:00] We can get into some more dynamic prompt rewriting by adding logic like matchInput.prompt for a load pseudo function. And if we look at this code that Cursor is suggesting, mostly because I just wrote this code, deleted it, and started recording, but we're going to check to see if this regex matches, which will be load with params surrounding any text, and then we're going to treat this matching text as a username and then fetch the result as json. Then essentially just take the prompt itself and rewrite this load section of the prompt as the JSON data result of this. So if I invoke clod now, I'll fire up clod and I'll say how many repositories does John have, and then type load john-lindquist for my github username, Hit enter. Behind the scenes in this hook it invoked this fetch, got the data back, and was able to dynamically populate that information into the prompt.

[00:59] So if I pick someone else I'll just replace John with Octocat and then replace this with Octocat. Hit enter. You'll see Octocat has eight public repos. So you get this complete flexibility of building in these functions with custom logic in them to invoke whatever you want. And this doesn't take up any context.

[01:19] It doesn't take up any MCP definitions or any command definitions. It simply only acts after a user submits some text and then you parse out the text behind the scenes and return a new rewritten prompt.



https://app.egghead.io/api/v1/lessons/inject-live-data-with-custom-hook-functions~6ue6t/transcript

Template-driven hooks turn one instruction into multiple structured solutions. Load templates from disk, replace placeholders, and get consistent output formats every time.

## The manual variation problem

Getting multiple solutions requires:
- Repeatedly prompting with different angles
- Inconsistent output formats
- Lost context between attempts

## Template + hook solution

Store a reusable template with placeholders:

`.claude/prompts/variations.md`:
```markdown
Generate $count possible solutions for the following instruction:

Format each solution with this template:

Steps:
1. ...
2. ...
3. ...

Reasoning:
...

Tradeoffs:
...

Instruction: $instruction
```

Hook to load and fill template:

`.claude/hooks/UserPromptSubmit.ts`:
```typescript
import { type UserPromptSubmitHookInput } from "@anthropic-ai/claude-code"

const input = await Bun.stdin.json() as UserPromptSubmitHookInput

// Match v(N) pattern
const match = input.prompt.match(/v$(\d+)$/)
if (match) {
  const count = match[1]
  const template = await Bun.file(".claude/prompts/variations.md").text()

  // Strip command, keep instruction
  const instruction = input.prompt.replace(match[0], "").trim()

  // Fill template
  const prompt = template
    .replace("$count", count)
    .replace("$instruction", instruction)

  console.log(prompt)
}
```

## Use it

Type your request with the command:

```bash
Build a desktop dictation app v(5)
```

Claude receives the full template with your values filled in, returning 5 structured solutions.

### Debug with transcript

View the transformed prompt:
- Press `Ctrl+O` to toggle detailed view
- See exactly what Claude received
- Refine templates based on results

## Try it

Prompts:
```markdown
desktop app for capturing dictation v(3)
```

```markdown
CLI tool for file organization v(5)
```

[00:00] So a concept I use a lot when prompting is essentially... I'm going to create a Cloud Prompts directory, call it variations.md. Generate three possible solutions for the following instruction, and I'll replace 3 with count. Then we'll drop in a format the instructions with the following template. And let's drop in a template like so.

[00:24] I'm just going to clean this up a bit. Steps one, two, three, reasoning, and trade-offs. Then just kind of leave it at that for now. We could modify this forever. And if we go back to our prompt, instead of matching for load, I'm just going to match for V for variations, swap username for count, and then we're going to bun file and load in this file.

[00:52] We'll call .txt on it. Make sure to await this. So prompt await bun file. And then just clear out the input prompt by input prompt replace, then we'll replace the match with nothing, and then we can just console.log, and then our new prompt will be the prompt that we loaded in, where we replace the instruction with the input prompt, we replace the count with the count. We'll just cast this as string right now to get rid of the error and then log out our new prompt.

[01:23] So if we clear this out and I say a desktop app for capturing dictation I can drop in a v5 at the end or really anywhere in the prompt. You'll see that the result is five different solutions, all with steps in them, all offering reasoning and trade-offs, so that you can pick how you want to continue from your original prompt. Now at any point if you want to see how the hook rewrote it hit ctrl-o and looks like that messed up formatting, but I'll scroll up and hopefully it'll clear up. You'll see we got the original prompt with the v5 and then our hook which took over and said this with all of this text inside of the user prompt submit hook tag. So anytime you need to inspect that just can toggle ctrl-o on and off to go back and inspect how the hooks were impacting the conversation.

[02:17] And again all of this came from this file where we essentially gave it a couple variables to replace. So count was replaced with the number 5 and then the instruction was replaced with the original prompt.



https://app.egghead.io/api/v1/lessons/generate-multiple-solutions-with-template-driven-hooks~0frnb/transcript

Blocking prompts with hooks creates essential guardrails. Validate inputs, enforce conventions, and stop inappropriate requests by exiting with the right code and clear feedback.

## The blocking rules

Two requirements to reject a prompt:
1. **Exit with code 2** - Exactly 2, not 0 or 1
2. **Write to stderr** - User sees your message

## Block forbidden content

Stop prompts with banned keywords:

```typescript
import { type UserPromptSubmitHookInput } from "@anthropic-ai/claude-code"

const input = await Bun.stdin.json() as UserPromptSubmitHookInput

if (input.prompt.includes("Bruno")) {
  console.error("We don't talk about Bruno!")
  process.exit(2)
}
// No exit = prompt continues
```

Test it:
```bash
claude
How's Bruno doing?
# Error: "We don't talk about Bruno!"
```

## Context-aware rules

Use working directory for location-based blocking:

```typescript
const input = await Bun.stdin.json() as UserPromptSubmitHookInput

// Block prompts in production directories
if (input.cwd.includes("/production")) {
  console.error("⚠️ Claude Code disabled in production directories")
  process.exit(2)
}

// Enforce tool preferences
if (input.prompt.match(/\bnpm install\b/)) {
  console.error("Use 'pnpm install' instead (team convention)")
  process.exit(2)
}
```

### Real-world patterns

- **Secret protection:** Block prompts containing API keys
- **Environment safety:** Disable in prod/staging folders
- **Team standards:** Enforce pnpm/yarn over npm
- **Cost control:** Block overly broad requests

## Try it

Prompts:
```markdown
How's Bruno doing?
```

```markdown
npm install react
```

https://app.egghead.io/api/v1/lessons/block-prompts-with-hook-guardrails~vhgyz/transcript

Blocking tool commands with hooks gives you fine-grained control over what Claude Code can execute. Use PreToolUse to intercept commands like `echo`, validate tool usage, and enforce conventions before any tool runs.

## Two ways to block

**Exit code 2** (simple):
- Write error to `stderr`
- Exit with code 2
- Claude sees the error message and stops the tool

**JSON output** (structured):
- Return `permissionDecision: "deny"`
- Provide `permissionDecisionReason`
- Claude sees the reason and can self-correct

## Block with exit code 2

Stop commands with a simple error:

```typescript
import { type PreToolUseHookInput } from "@anthropic-ai/claude-agent-sdk"

const input = await Bun.stdin.json() as PreToolUseHookInput

type BashToolInput = {
  command: string
  description: string
}

if (input.tool_name === "Bash") {
  const toolInput = input.tool_input as BashToolInput

  if (toolInput.command.startsWith("echo")) {
    console.error("echo is not allowed")
    process.exit(2)
  }
}
// No exit or exit 0 = tool continues
```

When Claude tries to use `echo`, the hook blocks it and shows the error message. This approach works but doesn't guide Claude toward the correct alternative—that's where JSON output helps (see lesson 16).

## Set up the hook

Update `.claude/settings.local.json`:

```json
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "bun run .claude/hooks/PreToolUse.ts"
      }]
    }]
  }
}
```

## Common matchers

Match specific tools with the `matcher` field:

- `Bash` - Shell commands
- `Write` - File creation
- `Edit|MultiEdit` - File edits (regex pattern)
- `Read` - File reading
- `*` or `""` - All tools

### Why this pattern works

- **Security:** Block destructive commands before execution
- **Conventions:** Enforce preferred tools (Write over echo)
- **Visibility:** Log or audit every tool call
- **Custom rules:** Any validation logic you need

## Try it

Prompts:
```markdown
use echo to echo hello world
```

```markdown
write a hello world file to the root of this project
```

[00:00] So we'll clear out our logic for user prompt submit and now turn our attention to a pre tool use hook and we'll let cursor fill this out with a tab. We'll leave our matcher blank so we capture all of them and then bun run a pre tool use script. So for our clod hooks pre-tool use script we're now going to import the pre-tool use hook input type and then cast our input to this new pre-tool use hook input. Now I have to call out that while I've been recording these lessons they renamed the SDK from clod-code to clod-agent-sdk. Just one of those things.

[00:40] And we'll navigate into our clod directory, into the hooks, and say bun-clod-code and instead clod-agent-sdk. Now all of the types are essentially the same. They did add some more features which we'll get into, but for now we just have to rename these. And then we can uninstall the clod code SDK. So bun remove.

[01:03] So we should be back in business here. So close this out, go back over to our pretool use, and we're simply just going to write out a file to capture what the input actually is. Launch Cloud Code. You'll see they also updated to Cloud Code 2.0. And you'll see the cute little mascot.

[01:21] They named it Clawd. C-L-A-W-D. And we'll just say use echo to echo hello world. Hit enter. And then if we hit ctrl-o to inspect this you'll see it invoked what they call the bash tool, and you'll see the syntax here in parens where the command and the arguments are wrapped inside of the bash tool.

[01:41] You'll see the result of hello world and you'll see that it ran our pre-tool use with bun, run, and where our script is. So if we check the result of this file in our hooks directory, pre-tool use input, you'll see that, close this out too, we have a tool name of bash which lines up with the tool name and the tool input with the command and description, the command being echo including the arguments. And these slashes just have to escape this so that it's formatted well in JSON. So if we want to prevent something like an echo we can check the tool input to check the command to see if it starts with echo. Now the way they have the types right now if you check the input.toolInput() if I try and check the properties here it's not going to list it because tool input is currently typed as unknown.

[02:32] And that's because based on the type of tool it runs, whether it's bash or the write tool or the edit tool or the other built-in tools, like the write tool would have the file path and the content to write to the file. But right now we're just working with bash. So we're going to say if the input tool name equals bash, it will create a type of bash tool input. And as a general cursor tip, if you have a file open next to your file it makes it much easier to tab auto-complete if you're trying to infer things from this other file. So we'll check on here by grabbing the tool input, casting it as the bash tool input, and then if the tool input command includes echo or starts with echo, We can reject this with process exit2 and give a console error of like echo is not allowed.

[03:25] So now if we close this out, start up Cloud, and run the exact same command we'll just press up to go back in our command history, hit enter. You'll see that this time we run into a bash operation is blocked by the hook and echo is not allowed. So depending on the bash tools you'd want to block you'd put them inside of here. And while this hook will still run on every other pre-tool. So if we say write a hello world file to the root of this project and we'll allow it to write, you'll see if we press ctrl-o it invoked the write tool, it invoked our pre-tool use hook, but it completed successfully because this tool name is named right and since it didn't match bash it just continues and exit successfully.



https://app.egghead.io/api/v1/lessons/block-tool-commands-before-execution-with-pre-tool-use-hooks~erv55/transcript

Guiding Claude Code with rich feedback turns blocked commands into learning opportunities. Return structured JSON with denial reasons and alternatives so Claude self-corrects in real time.

## Exit code vs. JSON output

**Exit code 2** (lesson 15):
- Blocks tool execution
- Shows error to Claude
- No structured guidance

**JSON output** (this lesson):
- Blocks with `permissionDecision: "deny"`
- Provides `permissionDecisionReason` with clear alternatives
- Creates a self-correcting feedback loop

## Return structured feedback

Use `HookJSONOutput` to deny with guidance:

```typescript
import { type PreToolUseHookInput, type HookJSONOutput } from "@anthropic-ai/claude-agent-sdk"

const input = await Bun.stdin.json() as PreToolUseHookInput

type BashToolInput = {
  command: string
  description: string
}

if (input.tool_name === "Bash") {
  const toolInput = input.tool_input as BashToolInput

  if (toolInput.command.startsWith("echo")) {
    const output: HookJSONOutput = {
      hookSpecificOutput: {
        hookEventName: "PreToolUse",
        permissionDecision: "deny",  // "allow" | "deny" | "ask"
        permissionDecisionReason: "echo is not allowed. Always use node -e and console.log instead."
      }
    }
    console.log(JSON.stringify(output, null, 2))
  }
}
```

Key fields:
- `permissionDecision`: `"allow"` (bypass permission), `"deny"` (block + feedback), or `"ask"` (prompt user)
- `permissionDecisionReason`: Message shown to Claude (for deny) or user (for allow/ask)

## See it self-correct

Prompt Claude to use a blocked command:

```markdown
use echo to echo hello world
```

Sequence:
1. Claude attempts `echo`
2. Hook denies with reason: "use node -e and console.log"
3. Claude immediately retries with `node -e 'console.log("hello world")'`
4. Command succeeds

## Permission decisions

Three options for `permissionDecision`:

1. **`"deny"`** - Block tool + show reason to Claude
   Use case: Enforce conventions with guidance

2. **`"allow"`** - Bypass permission system + show reason to user
   Use case: Auto-approve safe operations

3. **`"ask"`** - Prompt user for confirmation + show reason
   Use case: Require manual approval for sensitive operations

### Why this pattern works

- **Self-correction:** Claude learns your conventions in real-time
- **Clear guidance:** Explains why something's blocked and what to use instead
- **No dead ends:** Every denial includes the path forward
- **Consistent enforcement:** Same rules across all sessions

## Try it

Prompts:
```markdown
use echo to echo hello world
```

[00:00] For more fine-grained control, I'm going to import the hook.json output type. And since these are all types, let's do it this way. And then instead of console error and process exit, we can build up some output and then we'll console.log the output as JSON to send a JSON object back through the API. And we're going to bring in the hook specific output and configure this so that the hook event name is pretool-use, our permission decision is deny, and the reason can be echo is not allowed, always use node and console log instead. I'm going to toss in the dash e for evaluate flag.

[00:46] So if I run clod and ask it to use echo to echo hello world, now we'll get an error that would have shown up if we used console error and exiting the process with the exit code, and we can provide instructions like fallbacks on how to accomplish that task instead. So if you look at Ctrl-O here, you'll see it attempted bash with echo and then it successfully used node to execute console log.



https://app.egghead.io/api/v1/lessons/guide-claude-code-with-rich-pre-tool-use-feedback~ex177/transcript

Enforcing global rules with user-level hooks eliminates repetition. Move PreToolUse logic to `~/.claude/settings.json` and apply conventions across all projects from one central location.

## Project vs. User hooks

**Project hooks** (`.claude/settings.local.json`):
- Specific to one repository
- Live in project directory
- Good for project-specific rules

**User hooks** (`~/.claude/settings.json`):
- Apply to *all* projects
- Live in home directory
- Perfect for personal conventions

## Set up global hooks

Create the directory and initialize:

```bash
mkdir ~/.claude/hooks && cd ~/.claude/hooks
bun init
bun i @anthropic-ai/claude-agent-sdk
git init
```

## Configure user-level settings

Create or update `~/.claude/settings.json`:

```json
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "bun run ~/.claude/hooks/PreToolUse.ts"
      }]
    }]
  }
}
```

> Use absolute path (`~/`) or `$CLAUDE_PROJECT_DIR` for project-relative scripts. Global hooks need absolute paths to work from any directory.

## Write the global hook

Create `~/.claude/hooks/PreToolUse.ts`:

```typescript
import type { PreToolUseHookInput, HookJSONOutput } from "@anthropic-ai/claude-agent-sdk"

const input = await Bun.stdin.json() as PreToolUseHookInput

type BashToolInput = {
  command: string
  description: string
}

if (input.tool_name === "Bash") {
  const toolInput = input.tool_input as BashToolInput

  if (toolInput.command.startsWith("npm")) {
    const output: HookJSONOutput = {
      hookSpecificOutput: {
        hookEventName: "PreToolUse",
        permissionDecision: "deny",
        permissionDecisionReason: "Never use npm. Always use pnpm"
      }
    }
    console.log(JSON.stringify(output, null, 2))
  }
}
```

This hook applies to every Claude Code session, regardless of which project directory you're in.

## Test from any project

```bash
cd ~/projects/any-repo
claude
npm install lodash
# Hook denies: "Never use npm. Always use pnpm"
```

## Settings hierarchy

Claude Code merges hooks from multiple locations:

1. Enterprise managed policy settings (highest priority)
2. `~/.claude/settings.json` (user-level)
3. `.claude/settings.json` (project-level)
4. `.claude/settings.local.json` (local project, gitignored)

User-level hooks run in *every* project. Project-level hooks run only in that specific repository.

### Why this pattern works

- **Universal enforcement:** One hook applies to all projects
- **Team alignment:** Share `~/.claude` via dotfiles repo
- **No duplication:** Write once, use everywhere
- **Override flexibility:** Projects can add their own hooks too

## Try it

Prompts:
```markdown
npm i lodash
```

[00:00] When you have a situation where you want to deny a tool across all of your projects, you can take your configuration from your local settings, and we're going to open up our cursor in our home directory.cloud.slash settings, and then create a hooks section in here. And then just simply copy and paste the pre-tool use hook. Make sure to clean up any stray formatting issues, then hop back over to our user settings and inside of here we'll paste this. Now this is no longer a relative path and this is where you have to make a decision for either yourself or your team is where do you want to store hooks for all of your developers. You could store them in your home directory under the .clod folder, which makes a lot of sense.

[00:48] And since Anthropic currently doesn't have a hooks convention, you could version control a hooks directory inside of there. So that's the approach I'm going to take, But I can't guarantee that Anthropic isn't going to use a directory structure like this or conventions like this in the future. So you could decide on a path somewhere on the system to point to. That's just something you'll have to discuss with your team. But for me, I'm going to make a directory in clod slash hooks.

[01:15] I'm going to open up an instance of cursor in clod slash hooks. And then in this directory I will bun init to set this up as a bun project. I will bun install the agent SDK. And then I can just move over my pre-tool use. I'll git init this project, then just stage all the files, generate a commit message, let it commit, then you could create a repo and back it up and everything.

[01:42] But for now we just have to remember that this settings is inside of our .clod directory and the command is pointing to this hook here. So I'm going to configure this so that if a command starts with npm I'm going to deny and say never use npm always use pnpm. And this way no matter where we run our Clod tool, so let's change to a directory like a YouTube download project I have, I'll launch Clod, I'll say npm install lodash to ask it to install lodash, and you'll see that npm was blocked. And I did run into a bug here where the reason that this did not continue and swap over to pnpm is I was playing around with some other properties when testing out these lessons. I had continue false enabled here, so that prevented it from reading our follow-up instructions.

[02:36] So I'll say slash new and then try it again. You'll see that it blocks npm, we get the message back to always use pnpm, and now it's asking me to use PNPM to install this package.



https://app.egghead.io/api/v1/lessons/enforce-global-rules-with-user-level-pre-tool-use-hooks~lljm2/transcript

Claude Code Essentials

John Lindquist

Free Community Resource

Free Community Resource

Course Content