← Back to martymcenroe.ai

Working Around Permission Friction in Claude Code: A Power User's Journey

February 2026 Claude Code Tooling

I love Claude Code. I also run 12 agents simultaneously across 4 repos. Here's what I learned about pushing the permission system to its limits—and the tools I built to make it work.

The Setup: Multi-Agent Workflows

I'm not a typical Claude Code user. On any given day, I have:

Claude Code is designed for interactive use—a human at the keyboard, thoughtfully reviewing each action. That's a great default. But when you're running multiple agents and want to step away, the permission system becomes a bottleneck.

This isn't a criticism of the design philosophy. Safety-first is correct. But power users need escape hatches, and I ended up building my own.

The Five Friction Points

After months of intensive use, I've identified five areas where the permission system creates friction for advanced workflows:

1. Permissions Don't Survive Compaction

When a conversation gets long enough, Claude Code compacts the context. The summary preserves facts but loses operational state—including which permissions were granted.

Post-compaction, an agent that was happily running git commit commands suddenly needs approval again. If you're not at your keyboard, the agent stalls.

What would help: Persisting granted permissions across compaction, or a way to "lock in" session permissions.

2. Permission Syntax is Tricky

Getting patterns to match requires experimentation:

"Bash(git:*)"           // Does this work?
"Bash(git -C:*)"        // Or this?
"Bash(git -C /path:*)"  // Or this?

On Windows, there's additional complexity with path formats (C:\ vs /c/), tilde expansion, and the MSYS path conversion issue where /aws/lambda/... becomes C:/aws/lambda/....

What would help: Better documentation of pattern syntax, or a pattern tester tool.

3. Permissions Replace, Not Inherit

I assumed permissions would cascade:

~/.claude/settings.local.json          # Base permissions
~/Projects/.claude/settings.local.json  # Add project permissions
~/Projects/Talos/.claude/settings.local.json  # Add Talos-specific

But they replace entirely. If Talos has its own permissions block, it ignores everything above. This means duplicating the full permission set in every project.

What would help: An inheritance model, or a way to "include" parent permissions.

4. Multi-Repo Workflows Are Hard

When working across repos, each has its own permission context. An agent in Talos can't reference patterns approved in Aletheia. Switching between projects means re-establishing permissions.

What would help: User-level permissions that apply everywhere, with project-level additions.

5. The .claude Directory Protection

Every change to .claude/ requires human approval. This makes sense—it's configuration that affects agent behavior. But when you're iterating on hooks, skills, or settings, the approval frequency is high.

I understand the caution here. You don't want an agent modifying its own guardrails. But for power users actively developing their configuration, it's a speed bump.

What would help: A "developer mode" that relaxes .claude protections, or batch approval for related changes.

What I Built: AssemblyZero

Rather than fight the permission system, I built tools to work alongside it.

Permission Hygiene: assemblyzero-permissions.py

Every manual approval saves the exact command as a new permission. After a few sessions:

"Bash(git -C /c/Users/mcwiz/Projects/Aletheia commit -m \"docs: cleanup 2026-01-10\")"

That's not reusable—it has a specific date baked in. These "session vends" accumulate and clutter the settings file.

assemblyzero-permissions.py cleans them up:

poetry run python tools/assemblyzero-permissions.py --clean --project Aletheia
# Removed 47 session vends, kept 56 reusable patterns

Friction Logging: /zugzwang

When I hit a permission prompt I didn't expect, I log it:

/zugzwang
> .b git -C /c/Users/mcwiz/Projects/Talos commit -m "feat: add tests"

The log helps me identify patterns I should add to my allowlist. Over time, friction decreases as I build up the right permissions.

The Nuclear Option: Unleashed

For sessions where I want to step away entirely, I built Unleashed—a wrapper that auto-approves after a 10-second countdown.

It's not for everyone. You're trusting the agent completely. But for low-risk tasks where I've already reviewed the approach, it lets me run unattended.

Suggestions for the Claude Code Team

These aren't complaints—they're suggestions from someone who uses the product heavily and wants it to scale to advanced workflows:

  1. Permission persistence across compaction—Remember what was approved, even after summarization
  2. Pattern syntax documentation—A reference for wildcards, path formats, and tool-specific patterns
  3. Permission inheritance—Let project-level settings extend rather than replace parent settings
  4. User-level permissions—Patterns that apply regardless of which project is active
  5. Developer mode for .claude—Optional relaxed protection for users actively developing their configuration
  6. Pattern tester—A way to check if a pattern will match a given command before running it

The Bigger Picture

Claude Code's permission system is doing its job: preventing agents from running amok. The friction I experience is the cost of safety, and that's a reasonable trade-off for most users.

But as AI-assisted development matures, power users will push boundaries. Multi-agent workflows, autonomous sessions, cross-project coordination—these patterns need escape hatches.

AssemblyZero is my escape hatch. Maybe some of these ideas will make it into Claude Code itself. Until then, the tools are open source for anyone facing similar challenges.

Built with Claude Opus 4.5. I've approved approximately 10,000 permission prompts in the making of this blog post.