Use --dangerously-skip-permissions for Fully Autonomous Claude in Trusted CI
Claude Code asks for permission before running commands, editing files, and using tools. In interactive sessions, that's a safety feature. In CI, it's a blocker — there's no human to click "approve". The --dangerously-skip-permissions flag removes the prompts entirely.
claude --dangerously-skip-permissions -p "run the tests and fix any failures"
Claude reads, writes, and executes without asking — fully autonomous. The flag name is deliberately alarming because this is powerful and should only be used in environments you trust.
A typical CI setup:
# GitHub Actions example
- name: Auto-fix failing tests
run: |
claude --dangerously-skip-permissions \
--model haiku \
--max-turns 20 \
-p "run the tests, fix any failures, and commit the fixes"
Combine it with other safety controls:
# Limit tool access even without permission prompts
claude --dangerously-skip-permissions \
--allowedTools "Read,Glob,Grep" \
--max-turns 10 \
-p "review this code for issues"
This gives you autonomous execution with guardrails — Claude can read and search freely but can't edit files or run arbitrary commands, even with permissions skipped.
Practical CI use cases:
# Automated code review on every PR
claude --dangerously-skip-permissions \
--max-turns 15 \
-p "review the changes in this PR for bugs and security issues" \
--output-format json
# Auto-fix linting issues
claude --dangerously-skip-permissions \
-p "fix all linting errors and commit the changes"
# Generate documentation on release
claude --dangerously-skip-permissions \
-p "update the API docs to match the current endpoints"
Important safety notes:
- Never use this flag on untrusted input — it grants full system access
- Always combine with
--max-turnsto prevent runaway execution - Use
--allowedToolsto restrict what Claude can do even in autonomous mode - Only run in isolated environments (CI containers, sandboxed VMs)
Automation needs autonomy. --dangerously-skip-permissions gives it — but only use it where you'd trust a script with the same access.
via Claude Code
Log in to leave a comment.
When Claude writes error messages, button labels, validation text, or onboarding flows, it defaults to generic developer-speak. Add a "Users" section to your CLAUDE.md describing who your actual users are — their technical level, industry jargon, and what they care about — so Claude writes copy that makes sense to THEM, not to developers.
Use the --agent flag with custom markdown files in .claude/agents/ to launch purpose-built Claude sessions with restricted tools and scoped system prompts.
Every project has traps — the billing module that silently fails if you forget to queue the job, the legacy table with column names that don't match the model, the config value that must be set before tests run. Document these gotchas in your CLAUDE.md so Claude avoids the same mistakes your team spent days debugging.