DEV Community: VincentChabran

Why Claude Code keeps asking for permission — and how to fix your setup so it stops

VincentChabran — Wed, 08 Jul 2026 17:34:21 +0000

You set up Claude Code, you're in flow, and then: "Allow Bash(git diff)?" You click allow. Thirty seconds later: "Allow Bash(git log)?" Allow. Then the same slash command you already approved yesterday asks again. At some point you're tempted to reach for --dangerously-skip-permissions and be done with it.

Don't. Permission fatigue isn't fixed by surrendering — it's fixed by understanding the three specific reasons Claude Code prompts you, and configuring each one away. That takes about ten minutes, and this article is the complete walkthrough: the permission model, a documented trap inside slash commands that keeps prompting even when you've allowed everything, a copy-paste settings.json, and the case where a hook is safer than a broader allow.

In a previous article I showed the slash commands, subagent, and hooks I install in every repo. This is the deep-dive on the part of that setup that generates the most questions.

Unofficial, community-made. Not affiliated with or endorsed by Anthropic. "Claude" and "Claude Code" are trademarks of Anthropic. This is independent config for Claude Code, not a product of Anthropic.

Everything below was verified by actually running it on Claude Code v2.1.x (July 2026). The tool ships fast — if you're reading this much later, double-check the details against the current docs.

The three reasons you get prompted

Every permission prompt you see is one of these:

No rule covers the tool call. The default answer for anything not explicitly allowed is "ask." Fix: an allowlist in settings.json.
A slash command injects shell output, and nothing covers it — neither the command's allowed-tools frontmatter nor your settings. Fix: list the commands in the frontmatter.
The command is listed, but Claude Code can't statically verify it — because it contains dynamic constructs like $(...). This is the sneaky one, and it prompts on every invocation no matter what you've approved. Fix: rewrite the command (section below).

Let's take them in order.

Reason 1: the allowlist you haven't written yet

Claude Code reads permission rules from three settings files, most specific wins:

~/.claude/settings.json — you, on every project.
.claude/settings.json — this project, committed and shared with your team.
.claude/settings.local.json — this project, just you (git-ignored automatically).

Rules live under a permissions key in three lists: allow, ask, and deny — and deny always beats ask, which beats allow. A rule is a tool name plus an optional specifier:

Bash(git diff:*) — any command starting with git diff (the :* makes it a prefix match; without it, only the exact command matches).
Read(./.env) / Read(./secrets/**) — gitignore-style paths for file tools.
WebFetch(domain:docs.anthropic.com) — fetches scoped to a domain.

Two practical notes. First, when you click "always allow" on a prompt, Claude Code writes the rule to your local project settings — handy, but it means your allowlist grows ad hoc and never transfers to the next repo. Writing it deliberately in ~/.claude/settings.json fixes the fatigue everywhere at once. Second, run /permissions inside Claude Code any time to see exactly which rules are in effect and where each one comes from.

Reason 2: slash commands have their own gate

A custom slash command (a markdown file in .claude/commands/) can inject live shell output into its prompt with !`command`. That's the feature that makes commands like /review work on your actual diff. But those injected commands run the moment you invoke the slash command — so each one needs approval first. On v2.1.x, an injection is auto-approved if any of three things covers it: the command's own allowed-tools frontmatter, an allow rule in your settings, or Claude Code's built-in pass for a few safe read-only commands (like date). If none of the three covers it, you get prompted. The frontmatter is the one to reach for:

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

- Changed files: !`git status --short`
- Full diff: !`git diff HEAD`

Both injections are covered, so this runs silently — for everyone. Skip the frontmatter and the command may still seem fine on your machine, if your own settings happen to allow git status and git diff — and then it prompts the teammate who cloned the repo without your allowlist. The frontmatter is what makes a slash command portable and self-sufficient: it carries its own permissions instead of borrowing yours. If a command of yours always asks, this is the first thing to check.

So far, so documented. Now the trap.

Reason 3: the "too complex to verify" trap

Here's a command that looks perfectly configured — and prompts on every invocation anyway:

---
description: Summarize what this branch changes compared to main
allowed-tools: Bash(git log:*), Bash(git diff:*), Bash(git merge-base:*)
---

## Context

- Commits on this branch: !`git log --oneline $(git merge-base main HEAD)..HEAD`
- Files touched: !`git diff --stat $(git merge-base main HEAD)...HEAD`

## Task

Summarize this branch for a teammate: what changed, why, and what looks risky.

Every piece is listed in allowed-tools — git log, git diff, git merge-base. And yet: permission prompt, each time.

The reason: to auto-approve an injected command, Claude Code has to statically prove it matches an allowed pattern. git diff --stat HEAD is a literal string — provable. git diff --stat $(git merge-base main HEAD)...HEAD contains a command substitution whose output can't be known before running it — so the analyzer classifies the whole command as too complex to verify and falls back to asking you. In my testing on v2.1.x this applies to $(...), backticks, and even innocent-looking git expansions like @{u} (!`git log @{u}..HEAD` prompts too, despite containing no substitution at all).

This is a security feature, not a bug — a $(...) buried inside a pre-approved-looking command is exactly how a prompt-injection attack would smuggle something past your allowlist. So don't fight the analyzer. Restructure instead:

Keep the injections static. Move the dynamic logic into the task, where Claude resolves it at runtime.

---
description: Summarize what this branch changes compared to main
allowed-tools: Bash(git branch:*), Bash(git log:*), Bash(git diff:*), Bash(git merge-base:*)
---

## Context

- Current branch: !`git branch --show-current`
- Recent commits (fallback view): !`git log --oneline -15`

## Task

1. Find where this branch forked: run `git merge-base main HEAD`.
2. Read the exact range using the real SHA from step 1: `git log <base>..HEAD --oneline`
   and `git diff --stat <base>...HEAD` (substitute the SHA for `<base>` — don't nest
   `$(git merge-base ...)` inside the command, or it will trigger a permission prompt).
3. Summarize this branch for a teammate: what changed, why, and what looks risky.

Same capability, zero prompts. The injections are now literal strings the analyzer can match. The fork-point lookup happens as a normal tool call during the task: Claude runs git merge-base main HEAD (covered by Bash(git merge-base:*)), reads the SHA, then runs git log a1b2c3d..HEAD (covered by Bash(git log:*)). Note the warning inside the prompt itself: the same rule applies at runtime, so telling Claude to substitute the literal SHA — instead of nesting $(...) — is what keeps step 2 prompt-free.

Rule of thumb: !`...` injections should be commands you could type from muscle memory — fixed strings, no substitutions, no expansions. Anything conditional belongs in the task instructions.

A clean, copyable `settings.json`

Here's a complete baseline that removes the everyday prompts without opening anything scary. It also includes an auto-format hook (from the free kit linked at the end) so you can see how permissions and hooks coexist in one file:

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(git branch:*)",
      "Bash(git show:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git merge-base:*)",
      "Bash(ls:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push --force:*)"
    ]
  },
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "f=$(jq -r '.tool_input.file_path // empty'); [ -z \"$f\" ] && exit 0; case \"$f\" in *.js|*.jsx|*.ts|*.tsx|*.json|*.css|*.scss|*.html|*.md|*.yml|*.yaml) command -v prettier >/dev/null 2>&1 && prettier --write \"$f\" >/dev/null 2>&1 ;; *.py) command -v black >/dev/null 2>&1 && black -q \"$f\" >/dev/null 2>&1 ;; *.go) command -v gofmt >/dev/null 2>&1 && gofmt -w \"$f\" >/dev/null 2>&1 ;; *.rs) command -v rustfmt >/dev/null 2>&1 && rustfmt \"$f\" >/dev/null 2>&1 ;; esac; exit 0"
          }
        ]
      }
    ]
  }
}

Why these choices:

The allows are read-mostly. Status, diffs, logs, tests, lint — the commands Claude runs constantly and that can't hurt you. git add and git commit are there because committing is the point; there's deliberately no git push in the allowlist, so anything leaving your machine still asks.
The denies protect secrets from being read, not just edited. Claude never needs the contents of .env to help you code.
Put it in ~/.claude/settings.json for yourself everywhere, or .claude/settings.json to share the policy with your team. Restart Claude Code after saving.

When a hook beats a broader allow

Notice the deny rule Bash(git push --force:*). It works — but it's a string prefix. git push -f sails right past it. Permission rules are a convenience layer; when you want a guarantee, use a PreToolUse hook, which runs before the tool executes and can block it regardless of what the permission rules would have allowed.

Say you've allowed file edits broadly because the edit prompts were driving you mad. This hook makes sure that no matter what, credential files stay untouched:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "f=$(jq -r '.tool_input.file_path // empty'); case \"$f\" in *.env|*.env.*|*.pem|*.key) echo \"Blocked: $f looks like a credentials file. Edit it yourself.\" >&2; exit 2 ;; esac; exit 0"
          }
        ]
      }
    ]
  }
}

The hook reads the tool's JSON payload on stdin (jq pulls out the file path — brew install jq / sudo apt install jq), and exit code 2 blocks the action and hands your stderr message back to Claude as the reason, so it adapts instead of retrying blindly. Exit 0 stays out of the way.

The mental model: allow rules decide what runs without asking; hooks decide what never runs at all. Broad allow + narrow hard-block is a much nicer place to work than narrow allows + constant prompts — you get the flow back without giving up the guarantees you actually care about.

The 10-minute fix, recapped

Write a deliberate allowlist of read-mostly commands in ~/.claude/settings.json — stop accumulating one-off "always allow" clicks.
Give every custom slash command an allowed-tools frontmatter covering its !`...` injections.
Keep those injections static. Move anything with $(...), backticks, or @{u}-style expansions into the task instructions.
Guard the truly untouchable (secrets, force-pushes) with a PreToolUse hook exiting 2, not with an ever-longer prompt-clicking habit.

Get the files

The slash commands, the subagent, and the auto-format hook from this series — with the permission lessons above already applied — live in a free, MIT-licensed repo you can copy straight into .claude/ (the PreToolUse credentials guard isn't bundled with the kit — copy it straight from this article):

→ Claude Code Starter Kit on GitHub (MIT — use it, change it, ship it)

And if you want the extended set (12 commands, 6 subagents, 5 hooks, a git-aware status line, and a step-by-step guide), that's the paid Power Pack — but everything in this article works with the free repo alone.

Happy building.

The Claude Code setup I install in every repo: slash commands, a review subagent, and hooks

VincentChabran — Tue, 07 Jul 2026 18:04:30 +0000

Claude Code is powerful the moment you install it. But the thing that makes it feel like a real teammate isn't the model — it's the configuration you build up around it: custom slash commands, specialist subagents, and hooks that run at the right moments.

The problem is that a fresh install is a blank .claude/ folder. You get all that value only after you read the docs and write the config yourself.

So here's the config I now copy into every repo. Everything below is a plain file you can paste, read, and change. I'll show you real commands, a subagent, and a hook — with the actual code and why each part is there — so you can rebuild this yourself in an afternoon.

Unofficial, community-made. Not affiliated with or endorsed by Anthropic. "Claude" and "Claude Code" are trademarks of Anthropic. This is independent config for Claude Code, not a product of Anthropic.

Where this config lives

Two locations, and you can use both:

~/.claude/ in your home directory — applies to every project you open.
.claude/ in a repo root — applies to that project, and you can commit it to share with your team.

When a project file and a global file collide, the project one wins. I keep general-purpose commands and subagents in ~/.claude/, and project-specific rules in the repo.

1. A slash command is just a markdown file

The file name is the command name: .claude/commands/review.md becomes /review. The body is the prompt Claude runs. Here's a full, useful one — a pre-commit code review:

---
description: "Review the current changes for bugs, risks and quality before you commit"
argument-hint: [optional path or focus]
allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*)
---

## Context

- Changed files: !`git status --short`
- Full diff: !`git diff HEAD`

## Task

Act as a careful senior reviewer of the diff above (focus on "$ARGUMENTS" if provided).

Report findings grouped by severity — **Blocking**, **Should-fix**, **Nit** — and for
each give the `file:line`, what is wrong, and a concrete fix. Look specifically for:

- **Correctness**: off-by-one, null/undefined, wrong operators, missed edge cases.
- **Security**: injection, unsafe input handling, secrets committed, missing auth checks.
- **Concurrency & resources**: races, leaks, unclosed handles, missing timeouts.
- **Contracts**: API changes that break callers or aren't reflected in tests/docs.

If the diff is clean, say so plainly instead of inventing problems. End with a one-line
verdict: safe to commit, or not yet.

Three things are doing the work here:

! runs a shell command and injects its output into the prompt. !`git diff HEAD` means Claude reviews your actual current diff, not a description of it. This is the single most useful trick in the whole system.
allowed-tools pre-approves exactly those git commands, so /review doesn't stop to ask permission every time it reads the diff. (If Claude Code still prompts you all the time, I wrote a deep-dive on the permission model and how to fix it — including a trap that makes a command prompt on every run even when everything looks allowed.)
$ARGUMENTS is whatever you type after the command. /review the auth changes focuses the review; /review alone reviews everything.

Now /review gives you a consistent, senior-style pass over your changes every time, instead of a fuzzy "can you check this?"

2. Bake your repo's conventions into `/commit`

Same idea, pointed at commits. The trick here is feeding Claude your recent history so the new message matches the style you already use:

---
description: Create a well-formed git commit from the current changes
argument-hint: [optional message or intent]
allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git add:*), Bash(git commit:*), Bash(git log:*)
---

## Context

- Current status: !`git status --short`
- Staged diff: !`git diff --cached`
- Recent commits (match this style): !`git log --oneline -10`

## Task

Create one focused git commit for the changes above.

1. If nothing is staged, stage the files that clearly belong together — never unrelated
   files, build artifacts, or anything that looks like a secret.
2. Write a Conventional Commits message (`type(scope): summary`), imperative mood,
   ≤ 72 chars, matching the tone of the recent commits shown above.
3. Commit with `git commit`. Do **not** push. No co-author trailers or tool ads.

If the staged changes cover several unrelated concerns, say so and propose splitting them.

Because !`git log --oneline -10` injects your last ten commits, Claude writes in your house style — not a generic chore: update files. And "do not push" keeps a human in the loop for the one step that leaves your machine.

3. Subagents: specialists with their own context window

A subagent is a markdown file in .claude/agents/ with a bit of frontmatter and a system prompt. Claude can hand a task to it automatically, or you can call it by name. The win: the subagent works in a separate context window, so a long review or audit doesn't clutter your main conversation.

Here's the code-reviewer I use:

---
name: code-reviewer
description: Expert code reviewer. Use PROACTIVELY right after writing or changing code,
  and before committing, to catch correctness, security and design issues.
tools: Read, Grep, Glob, Bash
model: inherit
---

You are a senior software engineer doing a focused, high-signal code review.
Your job is to catch what matters and say it plainly.

## What you look for, in priority order

1. **Correctness** — logic errors, off-by-one, null/undefined, unhandled error paths.
2. **Security** — untrusted input reaching queries/commands/filesystem, injection,
   missing auth, secrets committed.
3. **Contracts** — API changes that break callers or aren't reflected in tests/docs.
4. **Resource & concurrency** — leaks, races, missing timeouts.
5. **Design & readability** — duplication, dead code, unclear names. Lower priority.

## Rules

- Do not invent problems to seem thorough. If the code is solid, say so and stop.
- End with a one-line verdict: **safe to merge**, **safe after should-fixes**, or **not yet**.

Two details matter:

The description is how Claude decides when to delegate. Writing it as "use PROACTIVELY right after writing code" is what makes the subagent trigger on its own. Vague descriptions never fire.
tools scopes what it can touch. A reviewer only needs to read and search (Read, Grep, Glob, Bash) — it shouldn't be editing your files. Omit tools entirely and it inherits everything.

After this is in place, Claude tends to call the reviewer itself after a change. You can always force it: "have the code-reviewer look at the auth module."

4. Hooks: automate what you'd otherwise forget

Hooks run your shell commands at defined moments in a session. They live in settings.json. The one I'd never work without formats every file the instant Claude edits it:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "f=$(jq -r '.tool_input.file_path // empty'); [ -z \"$f\" ] && exit 0; case \"$f\" in *.js|*.jsx|*.ts|*.tsx|*.json|*.css|*.scss|*.html|*.md|*.yml|*.yaml) command -v prettier >/dev/null 2>&1 && prettier --write \"$f\" >/dev/null 2>&1 ;; *.py) command -v black >/dev/null 2>&1 && black -q \"$f\" >/dev/null 2>&1 ;; *.go) command -v gofmt >/dev/null 2>&1 && gofmt -w \"$f\" >/dev/null 2>&1 ;; *.rs) command -v rustfmt >/dev/null 2>&1 && rustfmt \"$f\" >/dev/null 2>&1 ;; esac; exit 0"
          }
        ]
      }
    ]
  }
}

How to read that:

PostToolUse + matcher: "Edit|Write|MultiEdit" means "run after Claude edits or writes a file." The matcher is a regex on the tool name.
Claude Code sends the hook a JSON payload on stdin. Here jq pulls out .tool_input.file_path — the file that was just touched.
It picks a formatter by extension and no-ops silently if that formatter isn't installed, so it never breaks a session on a machine that doesn't have black.
Exit codes are the contract: 0 = fine, continue. 2 = block the action and hand your message back to Claude as the reason. (A PreToolUse hook that exits 2 on .env paths is a nice guard against Claude ever editing your secrets.)

jq is the only dependency (brew install jq / sudo apt install jq).

Install it in two minutes

Grab the files, drop them in, restart:

mkdir -p ~/.claude/commands ~/.claude/agents
cp commands/*.md ~/.claude/commands/
cp agents/*.md   ~/.claude/agents/
# then merge the hooks block into ~/.claude/settings.json

Restart Claude Code, type /, and the commands are there. Run /agents to see the subagent, /hooks to confirm the hook loaded.

One habit that makes all of this better

Notice a theme in the prompts above: they're written to be honest. The review command is told not to invent problems. A companion /pr command writes "not yet tested" instead of pretending. That matters — the fastest way to lose trust in an AI teammate is catching it claim a test passed when it never ran. Bake that into your prompts and the output stays trustworthy.

Get the files

I put the four commands, the code-reviewer subagent, the auto-format hook, and a CLAUDE.md template in a free, MIT-licensed repo so you can copy them straight in:

→ Claude Code Starter Kit on GitHub (MIT — use it, change it, ship it)

If you end up wanting the full set — 12 commands, 6 subagents, 5 hooks, a git-aware status line, and a full CLAUDE.md template — there's a paid Power Pack that bundles it with a step-by-step guide. But the repo above is enough to get real value today.

Happy building.

One Block to Force a Default AWS Region Across Every Terragrunt Module

VincentChabran — Mon, 06 Jul 2026 17:32:57 +0000

A quiet failure mode in multi-module Terragrunt setups: someone copies an existing module to bootstrap a new one, forgets to check the region in the provider config, and a resource lands in us-east-1 instead of eu-west-1 — three weeks later, someone's debugging why a Lambda can't reach a VPC that "should" be right there.

This isn't a Terraform bug. It's a consequence of region being just another string that every module has to get right, independently, forever.

The default pattern (and why it's fragile)

Most Terragrunt setups declare region per-project:

# projects/some-service/project.hcl
locals {
  aws_region = "eu-west-1"
}

Then the provider generation block in root.hcl reads it:

# root.hcl
locals {
  project = read_terragrunt_config(find_in_parent_folders("project.hcl"))
}

generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite"
  contents  = <<EOF
provider "aws" {
  region = "${local.project.locals.aws_region}"
}
EOF
}

Nothing wrong with this in isolation. The problem shows up at scale: with 20+ modules, aws_region is set 20+ times, by hand, by whoever created each module — usually by copy-pasting an existing project.hcl and hoping they remembered to check every field. New modules silently inherit whatever the copy-paste source happened to have, correct or not.

The pattern: a default that wins unless explicitly overridden

Flip the default. root.hcl computes the region with a fallback, so a project only needs to declare aws_region when it's an actual, deliberate exception:

# root.hcl
locals {
  project = read_terragrunt_config(find_in_parent_folders("project.hcl"))

  # Falls back to the org-wide default if the project doesn't override it.
  aws_region = try(local.project.locals.aws_region, "eu-west-1")
}

generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite"
  contents  = <<EOF
provider "aws" {
  region = "${local.aws_region}"
}
EOF
}

Now a brand-new project.hcl can be empty on the region question and still deploy to the right place by default:

# projects/brand-new-service/project.hcl
locals {
  legacy_prefix = "brand-new-service"
  # no aws_region — inherits eu-west-1 from root.hcl automatically
}

An exception is now a visible, deliberate line, not a silent inheritance from whatever was copy-pasted:

# projects/legacy-email-sender/project.hcl
locals {
  legacy_prefix = "legacy-email-sender"
  aws_region    = "eu-north-1" # locked to this region — legacy third-party integration, see runbook §3
}

The difference is where the burden of proof sits. Before: every module has to actively get the region right. After: every module gets it right by doing nothing, and getting it "wrong" (i.e., different from the default) requires writing a line down and, ideally, a comment saying why.

Where this generalizes

Region is the clearest example because a wrong region is easy to notice, but the same shape applies to any setting that should be consistent across a growing set of modules and currently isn't enforced by anything except habit: default tags, default VPC, default log retention. Anywhere you find yourself saying "just copy an existing module's config and change what's different," that's a signal the common part belongs in the root config with a try() fallback, and only the actual differences belong in each project's own file.

It costs one extra local in root.hcl. It saves the debugging session three weeks from now.

Renaming Terragrunt Projects Without Migrating State

VincentChabran — Mon, 06 Jul 2026 17:31:33 +0000

If you've run Terragrunt across more than a handful of modules for a while, you've hit this: you want to reorganize your repo — rename a folder, group projects differently, fix a naming mistake from six months ago — and Terragrunt's default behavior punishes you for it.

The problem

By default, Terragrunt derives your remote state key from the file path of the module. Something like:

# root.hcl
remote_state {
  backend = "s3"
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite"
  }
  config = {
    bucket = "your-terraform-state-bucket"
    key    = "${path_relative_to_include()}/terraform.tfstate"
    region = "eu-west-1"
  }
}

path_relative_to_include() is convenient until the day you move projects/old-name/ to projects/new-name/. The key changes, Terraform can no longer find the state for those resources, and you're one terragrunt apply away from either a pile of "already exists" errors or, worse, Terraform trying to recreate live infrastructure because it thinks it's gone.

The usual fixes are painful: terraform state mv per resource, or a full terraform import pass. Both work, both are slow, both are one typo away from downtime on something that's just supposed to be a folder rename.

The pattern: decouple the state key from the file path

Give every project a project.hcl with a legacy_prefix — the state key it should keep, independent of wherever the folder happens to live today:

# projects/new-name/project.hcl
locals {
  legacy_prefix = "old-name"   # the prefix this project's state has always used
  aws_region    = "eu-west-1"
}

Then have root.hcl build the state key from that prefix instead of the live path:

# root.hcl
locals {
  project = read_terragrunt_config(find_in_parent_folders("project.hcl"))
}

remote_state {
  backend = "s3"
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite"
  }
  config = {
    bucket = "your-terraform-state-bucket"
    key    = "${local.project.locals.legacy_prefix}/terraform.tfstate"
    region = "eu-west-1"
  }
}

Now the folder path is free to change. Rename it, move it, restructure the whole repo — the state key is pinned to legacy_prefix, not to path_relative_to_include(). A new project just sets legacy_prefix to whatever it wants (usually matching its own path, since it has no history to preserve); an existing project keeps its old prefix forever, regardless of where the folder lives.

The proof, not just the theory

Don't take "it should work" on faith. Before you consider a reorganization safe, run:

terragrunt plan

on every module you touched, and the only acceptable output is:

Plan: 0 to add, 0 to change, 0 to destroy.

Anything else means the key computation didn't land on the same value as before, and you stop right there. This one-line proof requirement is what makes the whole pattern trustworthy enough to use on live infrastructure: you're not hoping the refactor is safe, you're verifying it before it touches anything.

When this is worth it

This pattern earns its keep the moment you have more than a few Terragrunt modules and expect to reorganize them more than once — a new team convention, a naming scheme that didn't survive contact with reality, projects that outgrew their original folder structure. If you have three modules that will never move, plain path_relative_to_include() is simpler and you don't need this.

The core idea generalizes beyond Terragrunt: whenever a tool derives a stable identifier (a state key, a resource ID, a cache key) from something that isn't actually stable (a file path, a display name), that's worth decoupling explicitly — before the first painful migration forces you to do it under pressure.

DEV Community: VincentChabran

Why Claude Code keeps asking for permission — and how to fix your setup so it stops

The three reasons you get prompted

Reason 1: the allowlist you haven't written yet

Reason 2: slash commands have their own gate

Reason 3: the "too complex to verify" trap

A clean, copyable settings.json

When a hook beats a broader allow

The 10-minute fix, recapped

Get the files

The Claude Code setup I install in every repo: slash commands, a review subagent, and hooks

Where this config lives

1. A slash command is just a markdown file

2. Bake your repo's conventions into /commit

3. Subagents: specialists with their own context window

4. Hooks: automate what you'd otherwise forget

Install it in two minutes

One habit that makes all of this better

Get the files

One Block to Force a Default AWS Region Across Every Terragrunt Module

The default pattern (and why it's fragile)

The pattern: a default that wins unless explicitly overridden

Where this generalizes

Renaming Terragrunt Projects Without Migrating State

The problem

The pattern: decouple the state key from the file path

The proof, not just the theory

When this is worth it

A clean, copyable `settings.json`

2. Bake your repo's conventions into `/commit`