DEV Community: Vanja Petreski

Configure Claude Code for Maximum Power

Vanja Petreski — Mon, 13 Apr 2026 01:55:47 +0000

No prompts, max effort, zero friction. The complete permissions setup for power users who want Claude Code fully unleashed.

Claude Code ships with six permission modes, protected paths, allow/deny rules, hooks, and a deprecated flag that still half-works. Most people never touch any of it. They either get prompted constantly or they set one flag and think they are done.

This is the complete setup for running Claude Code at maximum power. No prompts. Max effort. Zero friction. I debugged this on my own machine after allow: ["*"] was not doing what I thought it was doing.

The Setup: Two Files, One Alias

You need three things configured correctly. Miss one and you will still get prompted.

1. Global Settings

Create or edit ~/.claude/settings.json:

{
  "permissions": {
    "allow": ["*"],
    "deny": [],
    "defaultMode": "bypassPermissions"
  },
  "skipDangerousModePermissionPrompt": true,
  "alwaysThinkingEnabled": true,
  "effortLevel": "max"
}

2. Shell Alias

Add to your .zshrc (or .bashrc):

alias c="CLAUDE_CODE_NO_FLICKER=1 claude --permission-mode bypassPermissions --effort max"

Now c launches Claude Code in bypass mode with max thinking effort and the smooth terminal renderer.

3. Source Your Shell

source ~/.zshrc

That is it. From now on, c runs Claude Code with zero prompts.

Why You Need Both Settings AND the Flag

This is the part that tripped me up.

defaultMode: "bypassPermissions" in settings means even launching with plain claude (no alias) starts in bypass mode
--permission-mode bypassPermissions in the alias is belt-and-suspenders. Explicitly sets it for the aliased command.
skipDangerousModePermissionPrompt: true skips the "are you sure?" warning when entering bypass mode
allow: ["*"] is a blanket allow for all tools. But without defaultMode it only works within default mode rules, which still protect certain paths.

The key lesson: allow: ["*"] is NOT the same as bypassPermissions. The allow rule works within the current mode's framework. bypassPermissions skips the framework entirely. You need defaultMode: "bypassPermissions" to truly remove all prompts.

The Deprecated Flag Trap

If you are using this:

alias c="claude --dangerously-skip-permissions --effort max"

It still works. But --dangerously-skip-permissions is deprecated. The canonical flag is now --permission-mode bypassPermissions. Update your alias before the old flag stops working.

Protected Paths: Why allow: ["*"] Still Prompts

Even with allow: ["*"] in default mode, these paths always prompt:

.git/, .vscode/, .idea/, .husky/ - editor and repo config
.claude/ - Claude's own config (except commands, agents, skills, worktrees)
.gitconfig, .gitmodules
.bashrc, .bash_profile, .zshrc, .zprofile, .profile - shell configs
.mcp.json, .claude.json

This is exactly what happened to me. I had allow: ["*"] and was still getting prompted for .claude/ edits. Adding defaultMode: "bypassPermissions" fixed it because bypass mode skips the protected paths check entirely.

The Six Permission Modes

default - Most restrictive. Prompts for every non-read operation. Protected paths always prompt.
acceptEdits - Auto-approves file reads and edits. Still prompts for Bash commands and network access.
plan - Read-only. Claude can read and search but cannot edit or run commands.
auto - AI classifier (Sonnet 4.6) reviews every action. Auto-approves safe actions, blocks dangerous ones. Requires Team/Enterprise/API plan.
dontAsk - Pure allowlist. Anything in permissions.allow executes. Everything else is silently denied. For CI/CD.
bypassPermissions - Skips the permission layer entirely. No rules checked, no prompts. Maximum speed.

Press Shift+Tab during a session to cycle: default, acceptEdits, plan (and bypass/auto if enabled). Note: dontAsk is startup-only and never appears in the cycle.

Allow/Deny Rules: The Fine-Grained Option

If you want something between "prompt everything" and "bypass everything," rules let you pre-approve specific tools.

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(git *)",
      "Bash(npm *)",
      "Bash(python3 *)",
      "WebFetch(domain:github.com)"
    ],
    "deny": [
      "Bash(rm -rf *)"
    ]
  }
}

Rules evaluate in order: deny > ask > allow. If a tool is denied at any level, no other level can allow it. Deny always wins.

Path rules use gitignore-style patterns. One gotcha: /path is relative to the project root. Use //path (double slash) for absolute filesystem paths.

Every Setting Explained

{
  "permissions": {
    "allow": ["*"],
    "deny": [],
    "defaultMode": "bypassPermissions"
  },
  "skipDangerousModePermissionPrompt": true,
  "alwaysThinkingEnabled": true,
  "effortLevel": "max"
}

Settings files load in priority order: managed (highest) > CLI flags > local project > shared project > user global (lowest). A deny at any level blocks everything below it.

The Mistakes I Made So You Do Not Have To

Thinking allow: ["*"] = bypass mode. It is not. allow works within the mode's framework. Protected paths still prompt in default mode.
Using --dangerously-skip-permissions. Deprecated. Use --permission-mode bypassPermissions.
Missing defaultMode in settings. Without it, you start in default mode regardless of allow rules.
Forgetting to uninstall the old npm binary. If you switched to the native installer, the old npm claude may still be in your PATH taking precedence. Run which -a claude to check.

Conclusion

The maximum power configuration is two files and one alias. The settings file tells Claude Code to start in bypass mode with max effort. The alias makes it a single-character command. Once it is set up, you stop thinking about permissions entirely and just work.

Originally published at vanja.io

Claude Code: GUI vs Terminal — A Tale of Two Workflows

Vanja Petreski — Mon, 13 Apr 2026 01:49:59 +0000

I've been using Claude Code in the terminal for a while now. Sonnet model, JetBrains IDE open on the side, watching changes flow in real-time, git branches under my control. Life was good. Sure, there were annoyances - the dreaded "compacting conversation" message that makes you wonder what context just got sacrificed to the token gods, or losing everything when the terminal session dies. But overall? Solid workflow.

Then Anthropic dropped the GUI preview. Shiny new interface. Opus model. "This is going to be amazing," I thought.

Reader, it was not amazing.

The GUI Experience: A Horror Story in Three Acts

Act I: The Worktree From Hell

First thing I noticed: Claude Code GUI doesn't work in your project directory. Oh no. It creates its own little universe - a git worktree tucked away in some .workspaces folder, completely isolated from your actual codebase.

"That's fine," you might think. "I'll just open it in my IDE."

Nope. JetBrains sees the branch exists but throws errors when you try to switch to it. Something about worktrees. Something about suffering.

The workaround? There's a cute little "Open in VSCode" button that works because apparently VSCode and Claude are best friends now. Great for VSCode users. For those of us who've spent years customizing our JetBrains setup? Pain.

Act II: Where Did My Environment Go?

Here's the thing about git worktrees - they're a fresh checkout. You know what doesn't get checked into git? Your .env file. Your local config. All those gitignored secrets that make your app actually run.

So Claude spins up in its pristine worktree, tries to run your app, and... nothing works. No database connection. No API keys. Just vibes and error messages.

Act III: Shell Shock

I use zsh. Like most developers in 2025. Claude Code GUI? Bash only.

This means nothing on my PATH works. My aliases? Gone. My carefully curated shell environment? Invisible.

The workaround: tell Claude to wrap everything in zsh -c "...". Then put that instruction in CLAUDE.md so it doesn't forget. Then watch it forget anyway and wonder why nvm isn't a command.

The Cleanup Crew

Once you're done with a session, you get to manually:

Delete the orphaned git branch
Clean up the workspace directory
Question your life choices

This cruft accumulates. Your .workspaces folder grows. Your branch list becomes a graveyard of abandoned Claude sessions.

But Wait, There's Good Stuff Too

I'm not completely hating here. The GUI does solve real problems:

No more compacting. Those long sessions where terminal Claude starts forgetting your project structure? Gone. The GUI maintains full context.

Session persistence. Close the window, come back later, pick up where you left off. Terminal Claude? Session dies with the terminal.

It's pretty. Look, the interface is nice. If you're into that sort of thing.

Opus is genuinely better. This was the revelation. Working with Opus instead of Sonnet means less ping-pong. You describe what you want, Claude does it right the first time. No more "okay but you broke the tests" followed by "okay but now you broke something else" loops.

The Plot Twist

Here's the thing: you can run Opus in terminal Claude Code.

The GUI's advantages - session persistence, no compacting, better model - only one of those is exclusive to the GUI. And it's not the model.

Terminal + Opus gives you:

Opus-level reasoning (fewer iterations, correct on first try)
Your JetBrains IDE working normally
Your .env and gitignored files intact
Your zsh config and PATH
Clean git workflow on branches you control

You lose:

Session persistence (mitigate with good CLAUDE.md)
Conversation compacting (mitigate with good CLAUDE.md)
The pretty interface (you're a terminal person, you'll survive)

The Verdict

Terminal + Opus. Not even close.

The GUI preview is solving problems I don't have while creating problems I very much do have. The worktree isolation might make sense for beginners who need guardrails, but for developers with established workflows, it's actively hostile.

The real MVP features - better reasoning, fewer iterations - come from Opus, not from the GUI wrapper. Run Opus in your terminal. Keep your workflow. Watch Claude get things right the first time while you maintain full visibility in your actual IDE.

Will the GUI improve? Probably. Anthropic ships fast and iterates faster. Maybe we'll get configurable worktree behavior. Maybe JetBrains integration. Maybe zsh support.

But I'm not going to fight my tools waiting for "maybe later." Terminal + Opus works today.

Now if you'll excuse me, I have a CLAUDE.md file to update. Gotta make sure Claude remembers to use zsh... wait, that's only the GUI. Never mind. Terminal life is good.

Originally published at vanja.io

How to Install Claude Code the Right Way in 2026

Vanja Petreski — Mon, 13 Apr 2026 01:46:41 +0000

I've installed Claude Code three different ways in the past month. Homebrew first, then npm, now the native installer. Each time I thought I had the right answer. Here's what I learned.

Homebrew: Where I Started

I was running Claude Code v2.1.81 via Homebrew. The new /buddy command — the terminal pet everyone was talking about — needed v2.1.89+. I ran brew upgrade. Nothing happened. Homebrew was 9 versions behind.

The problem: Homebrew wraps Claude Code as a cask. Someone has to update the formula after each release, then it goes through review. There's always a delay — sometimes hours, sometimes days.

npm: Better, but Not the Answer

I switched to npm. Updates landed faster because @anthropic-ai/claude-code is the actual package Anthropic publishes. No middleman. I even added a quick-update alias:

alias cu="npm update -g @anthropic-ai/claude-code"

This worked well — until I noticed a yellow banner in my terminal telling me npm installation is deprecated.

The Native Installer: The Right Way

Anthropic now ships a native binary — no Node.js required, no npm, no dependency chain. It's code-signed by Anthropic (notarized by Apple on macOS), and it auto-updates in the background.

Install it with one command:

curl -fsSL https://claude.ai/install.sh | bash

That's it. The binary lands at ~/.local/bin/claude. Make sure it's in your PATH:

export PATH="$HOME/.local/bin:$PATH"

If you're coming from npm or Homebrew, uninstall the old version:

# From npm
npm uninstall -g @anthropic-ai/claude-code

# From Homebrew
brew uninstall claude-code

Auth tokens live in ~/.claude/, completely independent of the install method. No re-authentication. You pick up right where you left off.

Why Native Wins

Auto-updates. Claude Code updates itself in the background. No manual brew upgrade or npm update. You always have the latest version. If you want to trigger an update manually: claude update.

Zero dependencies. No Node.js. No npm. No version manager conflicts with nvm, asdf, or fnm intercepting your PATH.

Code-signed. The binary is signed by Anthropic and notarized by Apple. Integrity verification via GPG-signed manifests with SHA256 checksums.

Release channels. Choose latest (default, immediate updates) or stable (roughly one week behind, skips regressions).

The Alias

My update alias is now just:

alias cu="claude update"

Though honestly, with auto-updates you barely need it.

The Gotcha: Ghost npm Still in PATH

If you previously installed via npm and then installed the native binary, you might still see this warning:

Claude Code has switched from npm to native installer. Run `claude install` or see https://docs.anthropic.com/en/docs/claude-code/getting-started for more options.

This means the old npm binary is still in your PATH and taking precedence over the native one. Check with:

which -a claude

If you see /opt/homebrew/bin/claude (npm) above ~/.local/bin/claude (native), the stale npm version is winning. The fix:

npm uninstall -g @anthropic-ai/claude-code

After that, which claude should resolve to ~/.local/bin/claude and the warning disappears.

Three install methods, three different trade-offs. Homebrew lags behind. npm works but is deprecated. The native installer auto-updates, has zero dependencies, and is the only one Anthropic actively recommends. Switch once, stop thinking about it.

Originally published at vanja.io