DEV Community: Vildanden

Show the model and git branch in Claude Code with a 6-line status line script

Vildanden — Thu, 29 Oct 2026 01:14:55 +0000

When you run Claude Code in a few repos at once, it's easy to lose track of which branch you're on and which model is answering. Claude Code has a configurable status line for exactly this: a small script whose output shows up under the prompt.

How it works

You point statusLine in your settings at a command. Claude Code runs it, passes session details as JSON on stdin, and shows the first line the script prints.

In ~/.claude/settings.json:

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}

The script

~/.claude/statusline.sh:

#!/usr/bin/env bash
input=$(cat)
model=$(echo "$input" | jq -r '.model.display_name')
dir=$(echo "$input" | jq -r '.workspace.current_dir')
branch=$(git -C "$dir" branch --show-current 2>/dev/null)
echo "[$model] ${dir##*/}${branch:+ on $branch}"

Make it executable with chmod +x ~/.claude/statusline.sh, and you'll see something like [Sonnet] api on fix/login-timeout under the prompt.

Tips

Keep it fast. It runs often, so avoid network calls or slow git commands.
It needs jq. If you'd rather not install it, the same script works in a few lines of Python reading sys.stdin.
Put it in your user settings, not the project file, since it's a personal preference rather than a team rule.
Type /statusline in Claude Code if you'd like it to draft a script for you.

The team-side setup that goes with this (a short CLAUDE.md, shared permissions, a risky-git hook and a read-only reviewer subagent) ships in Vildanden Agent Config. The free sample is enough to get started today.

Keep personal Claude Code settings out of git with settings.local.json

Vildanden — Wed, 28 Oct 2026 01:10:49 +0000

Claude Code reads settings from more than one file, and most teams only use one of them. If you've ever committed your own allow-list tweak by accident, or argued about whose model choice goes in the repo, the fix is to split shared rules from personal ones.

The three files

~/.claude/settings.json holds your user settings, applied in every project on your machine.
.claude/settings.json holds project settings. Commit this one so the whole team gets the same rules.
.claude/settings.local.json holds your personal settings for this project. Claude Code configures git to ignore it when it creates the file, so it stays on your machine.

When the same setting appears in more than one file, the more specific one wins: local beats project, and project beats user. Managed enterprise policy, if your company uses it, sits above all three.

A split that works

Shared, in .claude/settings.json:

{
  "permissions": {
    "allow": ["Bash(npm test:*)", "Bash(git diff:*)"],
    "ask": ["Bash(git push:*)"],
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

Personal, in .claude/settings.local.json:

{
  "permissions": {
    "allow": ["Bash(docker compose up:*)"]
  }
}

The team keeps the safety rails, and you get your extra command without a pull request.

Tips

Put deny rules in the project file. A teammate's local file shouldn't be where .env protection lives.
Check .gitignore once if you created settings.local.json by hand rather than through Claude Code.
Run /permissions inside Claude Code to see which rules are active and where each one came from.

The project-side file, plus a short CLAUDE.md, a risky-git hook and a read-only reviewer subagent, ships in Vildanden Agent Config. The free sample is enough to set this up today.

Make Claude Code ask before git push with one "ask" rule

Vildanden — Tue, 27 Oct 2026 01:13:37 +0000

Allow-lists and deny-lists get most of the attention, but Claude Code's settings.json has a third list that is often the most useful: ask. A command on it isn't blocked and isn't silently allowed. Claude stops and asks you first, every time.

The settings

Put this in .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(npm test:*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(git commit:*)",
      "Bash(npm publish:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Why "ask" beats "deny" for push

If you deny git push, the agent can never finish a task end to end, and people end up deleting the rule. If you allow it, one bad loop can push a half-finished branch. ask keeps the agent fast on everything local and puts you in front of the one step that leaves your machine.

Tips

Deny rules win over ask, and ask wins over allow, so you can be broad in allow and still catch the risky cases.
Commit .claude/settings.json so teammates get the same prompts; keep personal tweaks in .claude/settings.local.json.
Add git commit to ask only if you want to read every message; many people keep just push and publish.

The same three lists ship with a short CLAUDE.md, a risky-git hook and a read-only reviewer subagent in Vildanden Agent Config. The free sample is enough to set this up today.

Give Claude Code a read-only reviewer subagent in one file

Vildanden — Mon, 26 Oct 2026 01:17:08 +0000

The agent that wrote the code is a poor judge of it. Claude Code lets you define subagents with their own prompt and their own tool list, so you can keep a reviewer around that can read everything and change nothing.

The file

Save this as .claude/agents/reviewer.md:

---
name: reviewer
description: "Reviews the current diff for bugs, missing tests and risky changes. Use after finishing a task and before committing."
tools: Read, Grep, Glob, Bash(git diff:*)
---

You are a strict code reviewer. You cannot edit files.

1. Run `git diff` and read every changed file in full, not just the hunks.
2. List real problems only: bugs, unhandled errors, missing tests, secrets, breaking API changes.
3. For each one give the file, the line, and a one-sentence fix.
4. If nothing is wrong, say "No blocking issues" and stop.

Using it

Ask "use the reviewer subagent on my changes", or add a line to CLAUDE.md telling the main agent to call it before every commit. The reviewer runs in its own context, so a long review doesn't eat the main session's memory, and its limited tools mean it can't "fix" things behind your back.

Tips

Keep the tool list tight. Read, Grep and Glob plus git diff covers almost every review.
Commit .claude/agents/ so the whole team gets the same reviewer.
Pair it with a /review slash command if you prefer to trigger it by hand.

I ship this reviewer with a short CLAUDE.md, a risky-git hook, .env deny rules and a Bash allow-list in Vildanden Agent Config. The free sample is enough to try the setup today.

Block risky git commands in Claude Code with one PreToolUse hook

Vildanden — Fri, 23 Oct 2026 01:13:38 +0000

An agent with shell access will eventually try git push --force or git reset --hard when it gets confused. You don't need to watch every command. A small PreToolUse hook can stop the dangerous ones before they run.

The hook

Save this as .claude/hooks/block-risky-git.sh and make it executable (chmod +x):

#!/usr/bin/env bash
# Reads the tool call as JSON on stdin; exit code 2 blocks it.
cmd=$(jq -r '.tool_input.command // ""')

if echo "$cmd" | grep -Eq 'git (push .*(--force|-f)|reset --hard|clean -fd|branch -D|checkout -- \.)'; then
  echo "Blocked: '$cmd' can destroy work. Ask the user to run it themselves." >&2
  exit 2
fi
exit 0

Then register it in .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": ".claude/hooks/block-risky-git.sh" }]
      }
    ]
  }
}

What happens

When Claude tries one of those commands, the hook exits with code 2. The command never runs, and the message on stderr goes back to Claude, so it explains the situation to you instead of retrying blindly.

Tips

Keep the pattern list short and specific. Blocking all of git push just trains you to turn the hook off.
Commit the hook so everyone on the repo gets the same guardrail.
Pair it with a Bash allow-list so ordinary commands don't prompt you every time.

I ship this hook alongside a Bash allow-list, .env deny rules, a /review command, and a short CLAUDE.md in Vildanden Agent Config. The free sample is enough to try the pattern today.

A /review slash command that makes Claude Code check its own diff before you commit

Vildanden — Thu, 22 Oct 2026 01:08:52 +0000

Most bad commits from an agent aren't wrong code. They're leftover debug prints, a half-renamed variable, or a test that got skipped "for now". A one-file custom slash command catches most of that before it lands.

The command

Create .claude/commands/review.md in your repo:

---
description: Review the staged diff before committing
allowed-tools: Bash(git diff:*), Bash(git status:*)
---

Run `git diff --staged` and review only what changed.

Report, in this order:
1. Leftover debug output, commented-out code, or TODOs added in this diff.
2. Renames or signature changes that weren't applied everywhere.
3. Tests that were skipped, deleted, or weakened.
4. Anything that touches secrets, auth, or config files.

Do not edit files. End with "OK to commit" or a short list of what to fix.

Now /review in a session runs it. Because allowed-tools only lists read-only git commands, the review can't quietly "fix" things behind your back.

Why it works

Scoped input. It only looks at the staged diff, so the answer stays short and specific.
Fixed checklist. The same four questions every time beats "does this look good?".
No edits. You decide what to change, and the agent re-runs /review after.

Make it a habit

Commit the .claude/commands/ folder so the whole team gets the same command. Pair it with a Stop hook that reminds you to run /review when a session ends with uncommitted changes.

I ship this command alongside a Bash allow-list, .env deny rules, safety hooks, and a short CLAUDE.md in Vildanden Agent Config. The free sample is enough to try the pattern today.

Stop Claude Code from reading your .env with three deny rules

Vildanden — Wed, 21 Oct 2026 01:07:57 +0000

An agent that can read any file in your repo can also read .env, and whatever it reads can end up in a prompt, a log, or a commit message. You don't need to trust it to behave. You can just say no in settings.json.

The rules

Put this in .claude/settings.json at the repo root so it applies to everyone who opens the project:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Deny rules win over allow rules, so even if someone later adds a broad Read allow, these files stay off limits.

Things people miss

Example files are fine. If you keep a .env.example, it's caught by ./.env.* too. Rename it to env.example or add it back with a narrower pattern.
Shell is a side door. A deny on Read doesn't stop cat .env through Bash. Keep Bash on an allow-list of specific commands instead of allowing everything.
Commit the file. .claude/settings.json is meant to be checked in. Personal overrides go in .claude/settings.local.json.
Check your version. Permission rule syntax has changed between Claude Code releases, so confirm against the settings docs for the version you run.

Test it

Ask the agent to "show me the contents of .env". It should refuse with a permission message rather than print anything. If it prints, your rule path doesn't match.

I ship this deny list together with a Bash allow-list, safety hooks, and a short CLAUDE.md in Vildanden Agent Config. The free sample is enough to try the pattern today.

Keep your CLAUDE.md under 40 lines so Claude Code actually follows it

Vildanden — Tue, 20 Oct 2026 01:10:34 +0000

Most CLAUDE.md files I see grow into a wiki: architecture notes, style essays, a changelog, three pasted READMEs. Then people wonder why the agent ignores the one rule that mattered.

CLAUDE.md is loaded into context at the start of a session, so every line competes with your actual task. Short, concrete house rules beat long explanations.

A shape that works

# House rules

## Before you edit
- Read the file and its tests before changing it.
- Ask before adding a new dependency.

## Commands
- Test: `npm test`
- Lint: `npm run lint -- --fix`
- Never run: `git push --force`, `rm -rf`, database migrations.

## Done means
- Tests and lint pass locally.
- You list the files you changed and why, in one line each.

## Style
- Match the surrounding code. No drive-by refactors.

That is the whole file. Each line is something you could check in a diff.

Rules of thumb

Commands over prose. "Test: npm test" is better than a paragraph about the test philosophy.
Enforce, don't plead. If a rule really must hold (no force-push, tests after edits), put it in a hook or the allow-list in settings.json. CLAUDE.md is guidance; hooks are guarantees.
Move reference material out. Link to docs/architecture.md and let the agent read it when needed instead of loading it every session.
Prune monthly. If a rule never changed a diff, delete it.

Check the memory docs for your installed Claude Code version; how nested and user-level files are loaded can change between releases.

I ship this short house-rules file together with the allow-list and the safety hooks in Vildanden Agent Config. The free sample is enough to try the pattern today.

Get a desktop ping when Claude Code is waiting on you, with a Notification hook

Vildanden — Mon, 19 Oct 2026 01:08:01 +0000

You kick off a long Claude Code task, switch to another window, and come back twenty minutes later to find it stopped after two minutes, waiting for you to approve one command.

A Notification hook fixes that. Claude Code fires it when it needs your attention, such as a permission prompt or an idle wait for input, and the hook receives a small JSON payload on stdin with a message field.

The script

Save as .claude/hooks/notify.sh and chmod +x it:

#!/usr/bin/env bash
# notify.sh: desktop ping when Claude Code needs you
set -uo pipefail
msg=$(python3 -c 'import sys,json; print(json.load(sys.stdin).get("message","Claude Code needs you"))' 2>/dev/null || echo "Claude Code needs you")
if command -v osascript >/dev/null; then
  osascript -e "display notification \"${msg//\"/}\" with title \"Claude Code\""
elif command -v notify-send >/dev/null; then
  notify-send "Claude Code" "$msg"
else
  printf '\a'  # terminal bell as a last resort
fi
exit 0

Register it

In .claude/settings.json:

{
  "hooks": {
    "Notification": [
      {
        "hooks": [
          { "type": "command", "command": ".claude/hooks/notify.sh" }
        ]
      }
    ]
  }
}

Check the hooks page for your installed Claude Code version; payload fields and matcher options can change between releases.

Keep it useful

Always exit 0. A notification hook should never block the session.
Pair it with a sensible allow-list in settings.json, so you get pinged for decisions that matter, not for every ls.
Keep the message short. You want to know which repo is waiting, not read a log.

I keep this hook alongside the allow-list, the safety hooks, and a short house-rules file in Vildanden Agent Config. The free sample has enough to try the pattern today.

Give Claude Code a fresh repo briefing on every session with a SessionStart hook

Vildanden — Fri, 16 Oct 2026 01:08:20 +0000

Every new Claude Code session starts cold. It doesn't know which branch you're on, what's uncommitted, or that CI went red an hour ago, so the first few turns get spent rediscovering it.

A SessionStart hook fixes that. It runs when a session starts (or resumes), and whatever the command prints to stdout is added to the session context.

The script

Save as .claude/hooks/session-brief.sh and chmod +x it:

#!/usr/bin/env bash
# session-brief.sh: short repo briefing for a new Claude Code session
set -uo pipefail
echo "[repo briefing]"
echo "branch: $(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo 'not a git repo')"
echo "uncommitted files: $(git status --porcelain 2>/dev/null | wc -l | tr -d ' ')"
echo "last 3 commits:"
git log --oneline -3 2>/dev/null | sed 's/^/  /'
if [ -f TODO.md ]; then
  echo "open TODOs (first 5):"
  grep -m5 '^- \[ \]' TODO.md | sed 's/^/  /'
fi

Register it

In .claude/settings.json:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          { "type": "command", "command": ".claude/hooks/session-brief.sh" }
        ]
      }
    ]
  }
}

Check the hooks page for your installed Claude Code version; matcher options (startup, resume, clear) and exact fields can change between releases.

Keep it small

Ten lines of briefing beats a hundred. The goal is orientation, not a dump of git diff.
Don't print secrets or .env values. Anything on stdout goes into the model's context.
Pair it with a short CLAUDE.md for standing house rules and deny/ask rules in settings.json, so each piece does one job.

I keep the session hook, the settings file, and the short house-rules file together in Vildanden Agent Config. The free sample has enough to try the pattern today.

Inject a budget line into every Claude Code prompt with UserPromptSubmit

Vildanden — Thu, 15 Oct 2026 01:20:24 +0000

Hooks are not only for blocking bad tool calls. UserPromptSubmit runs when you send a message, before the model sees it — so you can inject a short context block every turn without bloating CLAUDE.md.

Use it for a standing budget reminder: context window, spend ceiling, or “prefer local tools over network.”

Minimal hook

Put this under .claude/hooks/ (exact registration path can vary by Claude Code version — confirm against your installed docs):

#!/usr/bin/env bash
# user-prompt-submit.sh — stdout is appended into the turn context
set -euo pipefail
cat <<'CTX'
[session budget]
- Prefer tools already in the repo; do not install packages unless asked.
- Keep diffs small; one concern per turn.
- If the task needs secrets or spend, stop and ask.
CTX

Wire it so Claude Code runs the script on UserPromptSubmit. Keep the injected text short (a few lines). Long dumps here fight the same context limit you are trying to protect.

Why not put this in CLAUDE.md?

CLAUDE.md is loaded once and drifts into a novel. A hook stays one focused reminder.
You can change the budget file without rewriting house rules.
Pair with a short stack map in CLAUDE.md (under ~80 lines) and put deny/ask policy in .claude/settings.json.

I keep the hooks, settings, and short house-rules file together in Vildanden Agent Config. The free sample is enough to try the pattern.

Put your Claude Code shell allow-list in settings.json, not in the prompt

Vildanden — Wed, 14 Oct 2026 01:13:31 +0000

Prompts are suggestions. Settings are rules.

If you only write "never run dangerous shell commands" in CLAUDE.md, the model can still try them. Claude Code lets you put an explicit allow / deny list in .claude/settings.json so the runtime blocks the tool call before it runs.

Minimal example

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)",
      "Bash(sudo *)"
    ],
    "ask": [
      "Bash(npm publish*)",
      "Bash(gh pr merge*)"
    ]
  }
}

Exact matcher syntax can vary by Claude Code version — treat this as the shape, then confirm against your installed docs. The point is: put the policy where the tool layer enforces it.

Why this beats a longer prompt

A deny in settings fails closed. A sentence in AGENTS.md is soft.
You can keep CLAUDE.md short (house rules + stack map) and still be strict on shell.
Pair with a PreToolUse hook for patterns settings cannot express, and a Stop hook so the agent cannot say "done" while tsc is red.

I keep the deny list, hooks, and short house-rules file together in Vildanden Agent Config. The free sample is enough to try the pattern.