I've been using Claude Code heavily in my development workflow, and there's one particular flag that's both incredibly useful and potentially catastrophic: --dangerously-skip-permissions. The name should give you a clue about what you're getting into.

Here's the thing that drove me to this flag in the first place: you set Claude off on a specific task, walk away for a coffee, and come back to find it's stopped at step two because it needs your permission to run mkdir. It's incredibly frustrating when you want Claude to handle a longer task autonomously.

The Problem with Default Permissions

Claude Code's default behaviour is to ask for permission for every command it wants to run. This makes sense from a security perspective, but it becomes a major workflow killer when you're trying to automate longer tasks.

I found myself constantly interrupted by permission requests for basic commands like ls, mkdir, or git status. Even after updating my settings file with approved commands, there are always edge cases - some commands that can't be pre-approved or variations that slip through.

My Solution: The clauded Alias

Rather than constantly typing out the full flag, I created a simple alias that I use for tasks where I'm comfortable with Claude having broader permissions:

# In your ~/.bashrc or ~/.zshrc
alias clauded="claude --dangerously-skip-permissions"

When I want Claude to run autonomously on a well-scoped task, I use clauded instead of claude. The name reminds me that I'm in "dangerous" mode, but it's much faster to type.

My Permissions Configuration

Before we get to the dangerous flag, here's my standard permissions setup in ~/.claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(mkdir:*)",
      "Bash(go:*)",
      "Write(*)",
      "Bash(ls:*)",
      "Bash(git:*)",
      "Update(*:*)",
      "Bash(mv:*)",
      "Bash(echo:*)",
      "Bash(sed:*)",
      "Bash(source:*)",
      "Bash(head:*)",
      "Bash(tail:*)",
      "Bash(npm:*)",
      "Bash(npx:*)",
      "Bash(pkill:*)",
      "Bash(touch:*)",
      "Bash(grep:*)",
      "Bash(deadcode:*)",
      "Bash(sqlite3:*)",
      "Bash(curl:*)",
      "Bash(rg:*)",
      "Bash(chmod:*)",
      "Bash(lsof:*)",
      "Bash(make:*)",
      "Bash(PORT=:*)",
      "Bash(find:*)",
      "Bash(docker:*)",
      "Bash(poetry:*)",
      "Bash(python:*)",
      "Bash(python3:*)",
      "Update(*)"
    ],
    "deny": []
  }
}

Notice I've allowed most common development commands but deliberately left out rm. Even with this extensive list, you'll still hit permission requests for edge cases.

When It Works Brilliantly

I've successfully used the dangerous flag for extended tasks, including one memorable 9-hour session where Claude built an entire financial data analysis system. The requirements were:

• Connect to multiple financial news APIs
• Fetch stock pricing and earnings data
• Analyse the combined data using a specific workflow
• Parse and format the results for daily insights

The key was providing a well-scoped initial prompt that specified exactly what needed to be built, which files to focus on, and what the expected flow should look like. Claude worked through the entire implementation, created tests for each component, and documented the system as it went.

The Real Risks (And My "Oh No" Moments)

The flag isn't called "dangerously" skip permissions for nothing. Here are the actual risks I've encountered:

File Deletion and Modification: The biggest risk is Claude removing or editing files it shouldn't touch. I was working on a development tool that had a config file, and while I was updating the default config creation process, Claude decided to test by putting blank values directly into my existing config file - without creating a backup first.

Scope Creep: Claude sometimes tries to "help" by modifying files outside your intended scope. I've seen it attempt to remove JSON configuration files that were system-related rather than project-related, simply because they seemed connected to what we were working on.

Data Loss: If you're working on AI or ML projects with datasets, this is critical. Claude might decide to "clean up" what it perceives as test data or temporary files.

My Recommended Approach

Here's how I use the dangerous flag safely:

1. Environment Isolation

For greenfield projects or major changes, I work in isolated environments. You can set up a simple Docker container specifically for Claude development:

FROM alpine:latest

# Install packages
RUN apk update && apk add --no-cache \
    bash \
    curl \
    git \
    build-base \
    python3 \
    py3-pip \
    nodejs \
    npm \
    vim

# Install Claude Code CLI
RUN npm install -g @anthropic-ai/claude-code

# Set up working directory
WORKDIR /workspace

# Default command - keep container running
CMD ["bash"]

This gives Claude a safe sandbox to work in without risking your main system. Because I love using Makefiles, here is the one I use for essential tasks:

DOCKER_IMAGE_NAME = claude
DOCKER_CONTAINER_NAME = claude

.PHONY: build run stop shell restart clean logs status

build:
	docker build -f Dockerfile-claude -t $(DOCKER_IMAGE_NAME) .

run:
	docker run -d \
		--name $(DOCKER_CONTAINER_NAME) \
		-v $(PWD):/workspace \
		-it \
		$(DOCKER_IMAGE_NAME)
	@echo "Container started. Use 'make shell' to access it"

stop:
	docker stop $(DOCKER_CONTAINER_NAME) || true
	docker rm $(DOCKER_CONTAINER_NAME) || true

shell:
	docker exec -it $(DOCKER_CONTAINER_NAME) bash

restart: stop run

clean: stop
	docker rmi $(DOCKER_IMAGE_NAME) || true

logs:
	docker logs -f $(DOCKER_CONTAINER_NAME)

status:
	@docker ps -a --filter name=$(DOCKER_CONTAINER_NAME)

2. Task Scoping

The quality of your results depends entirely on how well you scope the initial task. Compare these approaches:

Bad: "Build me a financial analysis system"

Good: "Build me a financial data aggregator that does A, B, and C. Look in these specific files, follow this expected flow, create tests that validate each iteration you make, ensure changes are small and incremental."

3. Sensitive Data Precautions

Never use the dangerous flag in directories containing:

• API keys or secrets
• Production configuration files
• Important datasets without backups
• System configuration files

4. Review Strategy

For longer autonomous runs, I often ask Claude to create documentation or a changelog as it works. This makes the post-work review much more manageable.

The Bottom Line

The --dangerously-skip-permissions flag is incredibly powerful for AI-powered development workflows, but it requires discipline and proper setup.

I use it regularly for well-scoped tasks in safe environments, and it's transformed how I approach larger development projects. The key is understanding that "dangerous" isn't just marketing - it means you need to be intentional about when and how you use it.

If you're interested in more advanced Claude Code session management or how I've integrated AI into my daily development workflow, I've written about those experiences as well. The tooling around AI development is evolving rapidly, and finding the right balance between automation and control is crucial for AI-first software development.

When used properly, this flag can give you hours of uninterrupted development time. When used carelessly, it can give you hours of recovery time. Choose wisely.