DEV Community: Mubashir Mohamed

Same hook, other side: how npm worms turned AI agent config into malware

Mubashir Mohamed — Tue, 13 Oct 2026 10:53:23 +0000

Last week I wrote about a Claude Code hook that stops your AI agent from reading your .env file. This year, attackers have been shipping the same kind of hook inside repositories, and it ran every time a developer opened the project. Here's what happened, why uninstalling the package didn't fix it, and how to check your own machine in five minutes.

Same file, same feature. The only difference is who wrote it.

The short version

A hook is a shell command your AI coding tool runs at a set moment, like when a session starts. Hooks live in a plain JSON file, .claude/settings.json, which sits in the repo and gets committed with everything else.

In my last post, that was the whole point: commit the hook, and every teammate gets the same guardrail. This post is about the other side of the same feature. If a hook you commit protects everyone who clones the repo, a hook an attacker commits reaches everyone who clones it.

That's not a hypothetical. Two waves of the same npm worm family did exactly this in May and June 2026.

What happened

Four weeks, two waves, and a jump from npm packages straight into Microsoft's GitHub organization.

May 2026: Mini Shai-Hulud

On May 11, attackers abused a weak spot in TanStack's GitHub Actions setup and got hold of a token that could publish to npm. In about six minutes they pushed 84 malicious versions across 42 @tanstack/* packages. A second wave on May 19 hit the @antv data-visualization packages through a compromised maintainer account. Across the campaign, reports count 170+ affected packages on npm and PyPI, including SDKs from Mistral AI, UiPath and Guardrails AI.

The payload ran from the package's install script. It stole whatever credentials it could find: GitHub and npm tokens, cloud keys, CI secrets. Then it did something that set it apart from older supply-chain attacks. According to the analyses from Microsoft, Snyk and StepSecurity, it made itself at home in the project:

It wrote a SessionStart hook into .claude/settings.json, pointing at a script it dropped in .claude/setup.mjs. That hook runs every time a Claude Code session opens in the repo.
It wrote a .vscode/tasks.json with a task set to run when the folder opens, as a backup in case you use VS Code instead.
Using the GitHub tokens it had just stolen, it committed that config to every repository it could reach, as a commit titled chore: update dependencies, authored as claude@users.noreply.github.com.

The planted file looked roughly like this (simplified, not the real payload):

.claude/settings.json — what the worm planted (illustrative)

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          { "type": "command", "command": "node .claude/setup.mjs" }
        ]
      }
    ]
  }
}

Scroll back up to the cover image and compare it with the hook from last week's post. Same file, same structure, same feature. The only difference is who wrote it.

June 2026: Miasma

In early June, a variant called Miasma started from a compromised Red Hat employee's GitHub account. The attackers added a small workflow to internal repos, used it to publish 32 malicious versions under the @redhat-cloud-services npm scope, and from there reached Microsoft's GitHub organization. More than 70 Microsoft repositories, including Azure/azure-functions-host and the durabletask projects, were taken offline. Reports disagree on whether GitHub or the attackers disabled them.

Two details make Miasma worth knowing about even if you never touched those packages:

It skipped npm entirely for some targets. It planted its runner straight into public repos, set to fire when the repo is cloned and opened in Claude Code, Gemini CLI, VS Code or Cursor. You didn't have to install anything; you only had to open the folder.
The malicious releases had valid provenance. They were published with real CI tokens, so they carried legitimate build attestations. "It's signed" wasn't proof that it was safe.

How a config file becomes a backdoor

Steps 03 to 05 form a loop. Every developer who opens an infected repo becomes the next source of stolen tokens.

The clever part is step 04. The teammate who gets infected next never installed a bad package. They pulled a repo that a colleague's stolen token had quietly pushed to. From their point of view, nothing unusual happened: they opened a project they work on every day, and their agent started up the way it always does.

Why uninstalling the package didn't help

Most of us respond to a bad dependency by removing it: delete it from package.json, reinstall, done. That instinct fails here for two reasons.

npm uninstall cleans up node_modules. Everything that matters is somewhere else.

The damage happens at install time. The install script had already run, read your credentials and sent them off before you ever imported the library.
The persistence isn't in node_modules. The hook lives in .claude/settings.json and the script lives in .claude/. npm uninstall doesn't know those files exist, so the hook keeps firing on every new session.

That's the real lesson. Your agent config used to be a place where you stored preferences. It's now a place where code runs, and it lives outside everything your dependency tooling watches.

Doesn't Claude Code ask before trusting a folder?

It does, and it's worth understanding exactly when that helps. In an interactive session, Claude Code shows a workspace trust dialog the first time you start it in a folder you haven't trusted. VS Code has the same idea: its Workspace Trust opens unfamiliar folders in Restricted Mode, which blocks automatic tasks.

But according to Claude Code's own permissions documentation, a repository's hooks still run in several situations where you never see that dialog:

The dialog protects you once, on the first open. Most real infections arrive after that.

You trusted a parent folder. If you once accepted the dialog in something like ~/code, the projects inside it inherit that trust, and their hooks run without a new prompt.
The project was already trusted. Trust is saved per folder. The worm's hook arrived later, either written by an install script inside a project you already trusted, or delivered by a git pull. No new dialog appears for either.
Headless runs. claude -p and the Agent SDK never show the dialog, and the docs list project hooks as "used" in that mode. That matters a lot if you run Claude Code in CI on pull requests from other people.

So the dialog is a real control, but it's a gate at the front door. The worm mostly came in through the side: through projects you trusted long ago. Cursor is even more exposed. Oasis Security's research found it ships with Workspace Trust turned off by default, so a folder-open task runs as soon as you browse the project.

Check your machine now

There are three files worth reading in any repo before you let an agent loose in it, plus one folder:

If you didn't write it and can't explain it, treat it as a finding.

Here's a read-only script that looks for all of them, plus the worm's commit signature, across every repo under a folder. It only prints; it doesn't change anything.

audit-agent-config.sh

#!/usr/bin/env bash
# Look for agent config that can run code. Read-only: it only prints.
# Usage: ./audit-agent-config.sh [folder-with-your-repos]   (default: current folder)
root="${1:-.}"

echo "== Hooks in Claude Code settings (read every command) =="
find "$root" "$HOME/.claude" -maxdepth 6 \( -name node_modules -o -path '*/.claude/plugins' \) -prune -o \
  -path '*/.claude/settings*.json' -print 2>/dev/null |
while IFS= read -r f; do
  if grep -q '"hooks"' "$f"; then
    echo "HOOKS    $f"
    grep -n '"command"' "$f" | sed 's/^/           /'
  fi
done
echo "== Scripts inside .claude/ folders =="
find "$root" "$HOME/.claude" -maxdepth 6 \( -name node_modules -o -path '*/.claude/plugins' \) -prune -o \
  -path '*/.claude/*' \( -name '*.js' -o -name '*.mjs' -o -name '*.cjs' \) -print 2>/dev/null
echo "== VS Code tasks that run when the folder opens =="
find "$root" -maxdepth 6 -name node_modules -prune -o -path '*/.vscode/tasks.json' -print 2>/dev/null |
while IFS= read -r f; do
  grep -q 'folderOpen' "$f" && echo "AUTORUN  $f"
done
echo "== Project MCP servers (each command starts a program) =="
find "$root" -maxdepth 6 -name node_modules -prune -o -name '.mcp.json' -print 2>/dev/null
echo "== Commits authored as claude@users.noreply.github.com =="
find "$root" -maxdepth 5 -name node_modules -prune -o -type d -name .git -print 2>/dev/null |
while IFS= read -r g; do
  repo="${g%/.git}"
  hits=$(git -C "$repo" log --all --oneline --author='claude@users.noreply.github.com' 2>/dev/null | head -5)
  [ -n "$hits" ] && printf 'SUSPECT  %s\n%s\n' "$repo" "$hits"
done
exit 0

Run it against the folder where you keep your projects:

chmod +x audit-agent-config.sh
./audit-agent-config.sh ~/code

Here's what it looks like when it finds something. One hook is yours; the other one isn't:

A hit usually shows up in more than one section at once: a hook, the script it points to, an autorun task, and the commit that added them.

How to read the output:

HOOKS lines aren't bad on their own. If you followed last week's post, you'll see your own block-secrets.sh there. Read every command it prints. Anything pointing at a .js or .mjs file in .claude/ that you don't recognise is the pattern to worry about.
Scripts inside .claude/: the worm dropped setup.mjs, and reports also mention router_runtime.js. Your own hooks are usually .sh files you can name.
AUTORUN means a task runs as soon as the folder opens in VS Code or Cursor. Some teams use this legitimately, for example to start a dev server. Make sure you know which ones are yours.
SUSPECT means commits exist under the address the worm used. Treat these as real findings unless you can account for them.

If you find something

The order matters here, because the hook runs again every time you start a session.

Rotate before you clean. Otherwise the session you open to clean up can steal the new keys too.

Stop opening an agent in that folder, and don't open it in VS Code or Cursor either, until it's cleaned.
Rotate your credentials first: npm tokens, GitHub tokens and SSH keys, cloud keys, and any CI secrets that machine could reach. Do this before you clean up, from a machine you trust, so a session you start while cleaning can't steal the new ones.
Remove the planted hook from .claude/settings.json and delete the unexpected scripts in .claude/. Check ~/.claude/settings.json too, not just the project.
Revert planted commits with git revert, not git reset, so the history of what happened stays visible to your team.
Check your lockfiles against the published lists of affected versions, and update to clean releases.
Tell your team. If the worm pushed to shared repos, anyone who pulled since then needs to run the same checks.

Harden it so the next one bounces off

No single control stops this whole chain, so stack a few that fail in different ways:

Layer 02 is the cheapest, and it's the one most teams don't have yet.

Layer 1: don't let packages run code on install

Both waves started from an install script. Turning those off cuts the chain at step 01:

~/.npmrc

ignore-scripts=true

A few legitimate packages need install scripts (native modules, mostly), and they'll tell you when they break. Allow those on purpose. If you're on pnpm, recent versions already block dependency install scripts unless you allow them, and its minimumReleaseAge setting can hold back brand-new versions for a few days. Both TanStack waves were caught within hours, so a short delay would have skipped them entirely.

Layer 2: review agent config like code

The worm spread by committing config files. Make those files impossible to change without a named reviewer:

.github/CODEOWNERS

# Agent and editor config can run code. Changes need a security review.
/.claude/      @your-org/security-reviewers
/.vscode/      @your-org/security-reviewers
/.cursor/      @your-org/security-reviewers
/.mcp.json     @your-org/security-reviewers

Then turn on "Require review from Code Owners" in your branch protection rules. Without branch protection, a stolen token can still push straight to main, so the two go together.

The habit matters as much as the file: when a PR touches .claude/, .vscode/ or .mcp.json, read it like a change to your CI pipeline, not like a change to a README. A commit called chore: update dependencies that adds a SessionStart hook should stop you cold.

Layer 3: trust on purpose

Don't accept the trust dialog in a big parent folder like your home directory or ~/code. Trust each project on its own, after you've read its config.
For headless runs in repos you didn't write, tell Claude Code to ignore the project's settings. The docs list three options, from strongest to most targeted:

# Ignore project hooks, skills, plugins and .mcp.json servers
claude -p "summarise this PR" --bare

# Read only your own user settings, not the project's
claude -p "summarise this PR" --setting-sources user

# Keep project settings but turn hooks off for this run
claude -p "summarise this PR" --settings '{"disableAllHooks": true}'

One subtlety from the docs: putting disableAllHooks in your user settings isn't enough on its own, because a repo's project settings take precedence and can switch it back. Pass it on the command line instead.

In VS Code, keep Workspace Trust on, and stop folder-open tasks from running automatically. Put this in your user settings, not the workspace's:

VS Code user settings.json

{
  "security.workspace.trust.enabled": true,
  "task.allowAutomaticTasks": "off"
}

Layer 4: have less worth stealing

Assume one of the first three layers will miss something one day. The question is what's on the machine when it does:

Use short-lived, narrowly scoped tokens for development, not long-lived personal access tokens with write access to everything.
If you publish packages, use trusted publishing over OIDC instead of a stored npm token. And if you maintain a project on GitHub, check your workflows for pull_request_target triggers that run code from forks. That pattern is how the TanStack wave got its token in the first place.
Keep real production secrets out of local files. If something leaks, rotating a scoped dev key is a five-minute job, not an incident.

Quick checklist

[ ] Run audit-agent-config.sh on the folder where you keep your repos
[ ] Read every hook command it prints, and every .js/.mjs file inside a .claude/ folder
[ ] If anything is planted: rotate credentials first, then clean, then git revert
[ ] Add ignore-scripts=true to ~/.npmrc
[ ] Add CODEOWNERS for .claude/, .vscode/, .cursor/ and .mcp.json, and require code-owner review
[ ] Stop trusting broad parent folders; trust projects one at a time
[ ] Run claude -p in CI with --bare or --setting-sources user
[ ] Set task.allowAutomaticTasks to off in your VS Code user settings

Wrapping up

Hooks are one of the best things about modern coding agents. They let you set boundaries once instead of watching every step, and that's still true. But the same property that makes a committed hook useful, that it travels with the repo and runs for everyone, is exactly what made it useful to a worm.

So the takeaway isn't "stop using hooks." It's a change in how you look at a few files. .claude/settings.json, .vscode/tasks.json and .mcp.json aren't preferences anymore. They're code that runs on your machine and your teammates' machines. Agent config is code. Review it like code.

I share practical dev tips like this regularly. You can follow along on Instagram at @mubashi_mohd.builds or find more at ordinarydev.in.

Sources and further reading

Originally published on Medium.

How to stop your AI coding agent from reading your .env file

Mubashir Mohamed — Sun, 11 Oct 2026 10:01:46 +0000

An AI coding agent can open any file in your project. That includes your .env, where your API keys, database URLs and service-role tokens live. Here's a small Claude Code hook that says no before the file is ever opened.

Why one read is enough

The agent doesn’t have to be doing anything wrong for this to happen. Ask it “why can’t the app connect to the database?” and opening .env to check DATABASE_URL is a perfectly reasonable next step. It's trying to help.

The problem is what happens after. Once the agent reads that file, those values are in its context window: the running conversation the model sees on every turn. From there they can end up in places you never intended.

Once a secret is in context, it travels with the conversation. You can’t un-read it.

Every later request. The context is sent to the model again on each turn, so the key rides along for the rest of the session.
Transcripts and logs. Session history is saved to disk in plain text, outside the protections you put on .env itself.
Code, tools and commits. The agent might “helpfully” inline a key into a config file, a test fixture, or an argument to another tool.

So the only reliable fix is to stop the read itself. You can do that with a Claude Code hook: a small script that runs before the agent uses a tool, and can say no. The whole setup takes about five minutes.

What a hook is

Claude Code lets you register shell commands that run at specific points in its lifecycle: when you submit a prompt, before a tool runs, after a tool runs, when Claude finishes, and so on. The one we want is PreToolUse. It fires after the agent decides to call a tool (read a file, edit a file, run a shell command) and before that tool actually runs.

The hook sits between “Claude decided” and “the tool ran”. Its exit code is the verdict.

Your script receives a JSON description of the pending tool call on standard input. It then answers with its exit code:

Exit 0: the tool runs normally. Stderr goes nowhere that matters.
Exit 2: blocked. The tool never runs, and stderr goes back to Claude as the reason.
Anything else: the tool still runs. It’s treated as a hook error, not a “no”, and stderr is shown to you, not Claude.

Two details matter here. First, the agent isn’t just stopped. It’s told why, so it can pick another approach and carry on with the rest of the task. Second, only exit 2 blocks. If your script crashes or exits 1, the call goes through. Keep that in mind; it comes back in Step 4.

Step 1: Register the hook

Add this to .claude/settings.json in your project:

.claude/settings.json

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Edit|Write|Grep|Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-secrets.sh"
          }
        ]
      }
    ]
  }
}

Here’s what each part does:

matcher is a pattern over tool names. Read|Edit|Write|Grep|Bash covers every built-in way to touch a file: reading it, changing it, searching inside it, or going around the file tools with cat .env in a shell.
command is what runs. $CLAUDE_PROJECT_DIR is set by Claude Code to your project root, so the hook still resolves when Claude has cd'd into a subfolder. The quotes keep it working if the path has spaces.

Where you put this decides who it protects:

.claude/settings.json: this project, shared with the team (commit it)
.claude/settings.local.json: this project, just you (kept out of git)
~/.claude/settings.json: every project on your machine, just you

For the user-wide version, keep the script in ~/.claude/hooks/ and point command at ~/.claude/hooks/block-secrets.sh instead, since there's no single project directory to resolve against.

Step 2: Write the script

Before writing it, look at what it will receive. For a Read call, standard input looks like this:

Only two fields matter for this hook: tool_name and tool_input. The field inside tool_input depends on the tool.

Now create .claude/hooks/block-secrets.sh. Start with the simplest version that works:

.claude/hooks/block-secrets.sh — simple version

#!/bin/bash
input=$(cat)
target=$(echo "$input" | jq -r '.tool_input.file_path // .tool_input.command // ""')
if echo "$target" | grep -E '(^|[ /])\.env' | grep -qv '\.example'; then
  echo "Blocked: .env files are off limits. Use .env.example for variable names." >&2
  exit 2
fi
exit 0

Make it executable, and install jq if you don't have it (it's the tool that parses the JSON):

Terminal

chmod +x .claude/hooks/block-secrets.sh
brew install jq          # macOS
sudo apt install jq      # Debian / Ubuntu

What it does, line by line:

Reads the whole tool-call JSON from stdin into input.
Uses jq to pull out the file path (for Read, Edit, Write) or, if there isn't one, the command (for Bash). The // means "or else", so it falls back to an empty string for anything else.
Checks whether that text contains .env at the start, after a slash, or after a space. That catches .env, config/.env and cat .env, but not src/environments/, because there the dot is missing.
Lets .env.example through, because templates hold variable names, not values, and they're genuinely useful for the agent to read.
On a match, prints a reason to stderr and exits with code 2. That message is exactly what Claude will see, so write it as an instruction: say what to do instead.

Step 3: Test it without Claude

You don’t need Claude running to test a hook. It’s just a script that reads stdin, so you can pipe in fake tool calls:

Terminal

echo '{"tool_name":"Read","tool_input":{"file_path":".env"}}' | .claude/hooks/block-secrets.sh
echo "exit code: $?"

Expected: the “Blocked” message and exit code: 2.

I ran the simple version against the obvious cases, and then against a few less obvious ones:

Tool  Input                         Simple version
----  ----------------------------  ----------------
Read  .env                          Blocked (exit 2)
Read  /app/.env.local               Blocked (exit 2)
Bash  cat .env                      Blocked (exit 2)
Read  .env.example                  Allowed (exit 0)
Read  src/app.ts                    Allowed (exit 0)
Bash  cat ".env"                    Allowed: gap
Bash  cat .env.example && cat .env  Allowed: gap
Grep  search inside .env            Allowed: gap
Any   .env, with jq not installed   Allowed: gap

The first five rows are what most tutorials stop at. The last four are why it’s worth running more than one test:

Quotes. In cat ".env" the character before .env is a quote, not a space or slash, so the pattern doesn't match.
A template in the same command. The .example check looks at the whole line. If .env.example appears anywhere, the entire command is waved through, including the cat .env after it.
Grep. Its target lives in tool_input.path, which the script never reads.
Missing jq. The script errors, target ends up empty, nothing matches, and it exits 0. It fails open, silently.

Step 4: Close the gaps

Here’s the version I actually use. It’s still about 20 lines:

.claude/hooks/block-secrets.sh — hardened

#!/bin/bash
# Fail closed: without jq we can't inspect the call, so block it.
if ! command -v jq >/dev/null 2>&1; then
  echo "Blocked: jq is not installed, so the secrets hook can't inspect this call." >&2
  exit 2
fi
input=$(cat)
# Collect every field that can name a file: Read/Edit/Write, Grep, Bash.
target=$(printf '%s' "$input" | jq -r '[.tool_input.file_path, .tool_input.path, .tool_input.glob, .tool_input.command] | map(select(. != null)) | join(" ")')
# Remove the safe templates first, then look for any .env that is left.
rest=$(printf '%s' "$target" | sed -E 's/\.env\.(example|sample|template)//g')
if printf '%s' "$rest" | grep -qE '(^|[^A-Za-z0-9_])\.env'; then
  echo "Blocked: .env files are off limits. Use .env.example for variable names." >&2
  exit 2
fi
exit 0

What changed, and why:

It fails closed. If jq is missing, it blocks with a clear reason instead of silently allowing everything. Annoying for a minute, but far better than thinking you're protected when you're not.
It reads every field that can name a file. file_path, path and glob cover Read, Edit, Write and Grep; command covers Bash. Whatever is present gets joined into one string to check.
It removes templates before checking, instead of after. .env.example, .env.sample and .env.template are deleted from the string first. A template can no longer vouch for the rest of the command.
It matches.env after any non-word character. Quotes, =, (, spaces and slashes all count. A letter before the dot doesn't, so process.env and import.meta.env in code or commands are left alone.

Run both versions through the same cases and the gaps close:

Tool  Input                                    Simple   Hardened
----  ---------------------------------------  -------  --------------------
Bash  cat ".env"                               Allowed  Blocked
Bash  cat .env.example && cat .env             Allowed  Blocked
Grep  path .env or glob .env*                  Allowed  Blocked
Any   jq not installed                         Allowed  Blocked, with reason
Edit  /proj/.env.production                    Blocked  Blocked
Read  .env.example                             Allowed  Allowed
Bash  node -e "console.log(process.env.HOME)"  Allowed  Allowed
Bash  npm run dev                              Allowed  Allowed

To make re-testing a habit, save the cases as a small script and run it whenever you change the hook:

test-hook.sh

for json in \
  '{"tool_name":"Read","tool_input":{"file_path":".env"}}' \
  '{"tool_name":"Bash","tool_input":{"command":"cat \".env\""}}' \
  '{"tool_name":"Bash","tool_input":{"command":"cat .env.example && cat .env"}}' \
  '{"tool_name":"Grep","tool_input":{"pattern":"KEY","path":".env"}}' \
  '{"tool_name":"Read","tool_input":{"file_path":".env.example"}}' \
  '{"tool_name":"Bash","tool_input":{"command":"npm run dev"}}'
do
  printf '%s' "$json" | .claude/hooks/block-secrets.sh 2>/dev/null
  echo "exit $?  $json"
done

You should see four exit 2 lines followed by two exit 0 lines.

What it looks like in practice

If Claude Code is already open, start a new session so it picks up the hook (you can also review registered hooks with the /hooks command). Then ask it to "read the .env file".

Illustration of the exchange. The exact wording in your terminal will vary by Claude Code version.

The call to Read(.env) never runs. Claude sees the hook's message, then moves on. In my case it offered to work from the example config instead, which is exactly what the message told it to do.

Two things that are easy to worry about, but don’t need to:

Your app still works. The hook only inspects the agent’s tool calls. When Claude runs npm run dev, your app loads .env itself through dotenv or your framework, and the command text never mentions the file.
Auto-approve doesn’t skip it. The hook runs before the permission check, so it applies even to tools you’ve told Claude Code to run without asking.

Your secrets stay in the file, and out of the context window.

Limits you should know about

This is a guardrail, not a sandbox. It catches the ordinary, well-meaning ways an agent opens a secret file. It can’t stop something that’s trying to get around it.

It’s a text pattern. The hook only sees the command string. A path built indirectly, like cat ./.e* (a glob the shell expands later) or a filename assembled from variables, doesn't contain .env, so it passes. I confirmed the glob case gets through the hardened script too.
Programs can still read the file. If Claude runs a script that loads .env and prints its values, the hook sees node print-config.js, not the file. Be wary of debug scripts that dump the environment.
It only covers the tools in your matcher. If you add other tools that can read files, such as an MCP filesystem server, add their tool names to the matcher (MCP tools are named like mcp__server__tool, and the matcher accepts patterns such as mcp__filesystem__.*). The hardened script already checks path, which many of them use.
Other secret files exist. .env is the common one. To extend the check to *.pem keys, credentials.json and .npmrc, swap the grep line for the one below (and make the message say "secret files").

block-secrets.sh — extended pattern

if printf '%s' "$rest" | grep -qE '(^|[^A-Za-z0-9_])\.env|\.pem($|[^A-Za-z0-9_])|credentials\.json|\.npmrc'; then

Add a second and third layer

No single control covers everything, so stack a few that fail in different ways:

Each layer covers a gap the others leave open.

Layer 1: permission deny rules. Claude Code’s own settings can refuse to read specific paths, with no script involved. Add them next to the hooks block:

.claude/settings.json

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.local)",
      "Read(./.env.production)"
    ]
  }
}

List your real files by name rather than using a wildcard like .env.*, which would also deny .env.example. Deny rules match on paths, so they don't see cat .env inside a shell command. That's the gap the hook fills.

Layer 2: the hook from this post, which also covers Bash and tells Claude what to do instead.

Layer 3: nothing valuable to leak. Keep real production secrets out of local files whenever you can. Use a secrets manager, and short-lived or tightly scoped keys for development. If something does slip through, rotating a scoped dev key is a five-minute job, not an incident.

Troubleshooting

The hook never fires. Check the script is executable (chmod +x), the path in command is right, and settings.json is valid JSON (jq . .claude/settings.json will complain if it isn't). Then start a new session. Running claude --debug shows hook activity as it happens.
Every call is blocked with “jq is not installed”. That’s the fail-closed check working. Install jq and it clears up.
A file you need is blocked. The pattern also matches names that start with .env, like .envrc. Add the file to the sed line alongside example|sample|template if it's safe to read, or leave it blocked if it holds secrets too (an .envrc often does).

Quick checklist

Add the PreToolUse block to .claude/settings.json
Create .claude/hooks/block-secrets.sh (hardened version) and chmod +x it
Make sure jq is installed
Pipe fake tool calls through it: four exit 2, two exit 0
Add permissions.deny rules for your real .env files
Commit .claude/settings.json and .claude/hooks/ so the whole team gets the same guardrail

Wrapping up

AI coding agents are most useful when you let them move fast, and hooks let you set the boundaries once instead of watching every step. A 20-line script is a small price for keeping your keys out of the context window. Just remember to test it like an attacker would, not only like a user would. That’s where the interesting bugs were.

I share practical dev tips like this regularly. You can follow along on Instagram at @mubashi_mohd.builds or find more at ordinarydev.in.

Originally published on Medium in Artificial Intelligence in Plain English.

GitHub Profile Glow-Up: From Basic to Portfolio in 6 Steps

Mubashir Mohamed — Sun, 11 Oct 2026 09:55:57 +0000

Recruiters and clients open your GitHub before they reply, so make it read like a portfolio, not a code dump. These 6 steps take one weekend.

Before vs after

The code stays the same. What changes is that a visitor can see who you are, what you’ve built and how to reach you in under 10 seconds. The example below uses a made-up developer, Sam Rivera (sam-builds).

Before: Default avatar, no bio, no README, forked tutorials pinned and an almost empty contribution graph.

After: Photo, headline bio, complete sidebar, profile README, six real projects pinned and steady activity.

Basic profile → portfolio profile

Avatar: default identicon → a clear, friendly photo
Header: username only, no bio → name + one-line headline: role, stack, focus
README: none → 3-line intro, grouped stack, project table, contact
Pinned repos: forks, tutorials, test-repo, Untitled-1 → 4–6 shipped projects with descriptions
Sidebar: empty → company, location, website, LinkedIn, email
Takeaway: “Hard to tell what they do” → “Full-stack dev who ships SaaS tools, open to work”

The 6 steps

1. Create a repo named exactly your username

Go to github.com/new and name the repository the same as your username (for example sam-builds/sam-builds). Make it public and tick Add a README file. GitHub shows this README at the top of your profile page, so it becomes your landing page.

2. Open with a 3-line intro

Say who you are, what you do, and what you’re open to. Keep it to three lines so it fits above the fold.

README.md

# Hi, I'm Sam
**Full-Stack Developer** · Remote
Open to: freelance + full-time roles

3. Group your stack, skip the badge wall

Four short lines grouped by area are easier to scan than 40 logo badges. List only what you’d be happy to be hired for.

README.md

## What I work with
**Frontend** · React, Next.js, TypeScript, Tailwind
**Backend** · Node.js, Express, PostgreSQL
**Mobile** · React Native (Expo)
**Delivery** · GitHub Actions, Vercel, Docker

4. Show what you’ve built

Add a table with one row per project: name, what it does in plain words, the stack, and links. A live demo link gets clicked far more often than a code link, so add one wherever you can.

README.md

## Things I've built
| Project | What it is | Stack |
| --- | --- | --- |
| **Shiftly** · [live](https://example.com) · [code](https://github.com/sam-builds/shiftly) | Shift scheduling for small cafes and clinics | Next.js, Postgres |
| **Invoicely** · [live](https://example.com) · [code](https://github.com/sam-builds/invoicely) | Quotes to invoices for freelancers | React, Node, Stripe |

5. Fill the sidebar

Open Settings → Public profile and fill in every field:

Photo: a clear headshot, not the default identicon
Name and bio: a one-line headline, such as Full-Stack Developer · React, Node, Postgres · Building SaaS tools
Company, location, website: add “Open to remote” next to your location if it applies
Social accounts: LinkedIn at minimum
Public email: so people can contact you without searching

6. Pin your best, archive the rest

Pin 4–6 repos you’d show in an interview, each with a one-line description. Archive old tutorials and test repos from each repo’s Settings → Archive this repository. Archived repos stay public and read-only, so nothing is lost, but they stop competing with your best work.

README template

Paste this into your username/username README and replace the sample details with your own.

README.md — full template

# Hi, I'm Sam

**Full-Stack Developer** · Lisbon · Open to remote

I build web and mobile products for startups and small teams.

**Open to:** freelance projects and full-time roles.

## What I work with

**Frontend** · React, Next.js, TypeScript, Tailwind
**Backend** · Node.js, Express, PostgreSQL
**Mobile** · React Native (Expo)
**Delivery** · GitHub Actions, Vercel, Docker

## Things I've built

| Project | What it is | Stack |
| --- | --- | --- |
| **Shiftly** · [live](#) · [code](#) | Shift scheduling for small cafes and clinics | Next.js, Postgres |
| **Invoicely** · [live](#) · [code](#) | Quotes to invoices for freelancers | React, Node, Stripe |
| **PantryPal** · [code](#) | Tracks groceries and expiry dates | Expo, Supabase |

## Work with me

Freelance MVPs, dashboards and React Native apps.
Email: hello@samrivera.dev · [LinkedIn](#) · [Website](#)

Checklist

Repo named exactly after your username, with a README
3-line intro: who, what, open to
Stack grouped into 3–5 lines
Project table with live and code links
Photo, headline bio, location, website, LinkedIn, email
4–6 best repos pinned, each with a description
Old tutorials and test repos archived

Originally published on Medium in CodeToDeploy.