How I used Claude Code to fix my Claude Code workflow
I type claude --dangerously-skip-permissions dozens of times a day. Not an exaggeration. I run parallel Claude Code sessions across multiple projects, spin up new chats constantly, and every single time I open a new terminal tab, I paste the same 40-character flag. Copy from somewhere. Paste. Enter. Repeat. For weeks.
Then one afternoon, mid-session, I stopped and thought: why am I still doing this? I have a tool that writes shell scripts, generates configs, and automates workflows for a living. And I'm manually pasting a CLI flag into my own terminal like it's 2004.
So I did the obvious thing. I asked Claude.
This post is about a specific workflow optimization, but the real takeaway is the pattern behind it: using your AI tool to improve how you use your AI tool. That feedback loop is where the biggest productivity gains hide.
Why a CLI flag was costing me more than I realized
Here's my typical workday. I have three or four Claude Code sessions running at any given time. One is working through a test suite refactor. Another is helping me debug an API integration. A third is drafting documentation. When I need a fresh context — a new question, a different repo — I open a new terminal tab and start another session.
Every new session means typing or pasting claude --dangerously-skip-permissions. It takes maybe five seconds. That's nothing, right?
Except it's not five seconds. It's the clipboard management. It's the mental interruption of switching away from whatever I was thinking about to find the flag. It's the micro-annoyance that builds up across 20 or 30 new sessions a day.
Research backs this up. Gloria Mark at UC Irvine found that it takes an average of 23 minutes and 15 seconds to regain focus after an interruption. Now, pasting a CLI flag isn't the same as a coworker tapping your shoulder. But the principle holds: every friction point in a repetitive workflow costs more than the raw seconds suggest. The context switch is the tax. The flag itself is just the trigger.
And here's the thing — the flag exists for a good reason, but in my workflow it had become pure friction. According to Anthropic's own engineering blog, users accept 93% of permission prompts without changing anything. They call it "approval fatigue." When you're approving every single action anyway, the permission system stops being a safety check and starts being a speed bump.
What --dangerously-skip-permissions actually does
--dangerously-skip-permissions is a CLI flag for Claude Code that bypasses all permission prompts during a session. Instead of asking you to approve file edits, command execution, and other actions one by one, Claude just does them.
It sounds reckless if you read the name without context. But Claude Code has six permission modes, and they sit on a spectrum:
| Mode | What it does |
|---|---|
| Default | Asks permission for most actions |
| acceptEdits | Auto-approves file edits, asks for everything else |
| plan | Read-only, no execution at all |
| auto | Allows most actions, blocks risky ones (network, destructive commands) |
| dontAsk | Fewer prompts, still some guardrails |
| bypassPermissions | Skips all prompts — what --dangerously-skip-permissions enables |
The auto mode is Anthropic's middle ground. Their engineering team designed it with a 0.4% false positive rate while catching 83% of genuinely dangerous actions. It's smart. For many people, it's the right choice.
But I work on personal projects where I'm the only contributor. I trust the tool. I've been using it long enough to know what it will and won't do. For my workflow, bypassPermissions is the right mode. The problem was never the flag's behavior — it was typing it out every time.
I asked Claude to fix it
I was mid-session, about to open yet another terminal tab, when I decided to stop copying and pasting. I didn't Google "zsh alias syntax." I didn't dig through my .zshrc from three years ago to remember the format. I asked the tool that was already open.
The conversation was about four lines long. I told Claude I was tired of typing the flag. Claude gave me this:
alias cc="claude --dangerously-skip-permissions"One line in my .zshrc. Two characters — cc — instead of forty. I ran source ~/.zshrc, and it worked.
The whole thing took 30 seconds. Not 30 seconds of Googling and scanning Stack Overflow answers. Thirty seconds of describing what I wanted and getting the answer inside the tool I was already using.
That's it. That's the fix. Two characters.
To set this up yourself: open your shell config file (~/.zshrc for zsh, ~/.bashrc for bash), add the alias line, then run source ~/.zshrc (or source ~/.bashrc) to apply it immediately. From that point on, typing cc in any new terminal launches Claude Code with permissions skipped.
The feedback loop most people miss with Claude Code
The alias itself is trivial. What caught my attention was the pattern.
I used Claude Code to fix a problem with how I use Claude Code. That's a feedback loop. And most people don't think to close it.
Here's what I mean. I see developers use Claude for their application code all day long. They'll ask it to refactor a function, write tests, debug a tricky race condition. But when their own development environment has friction — a long command they keep retyping, a git workflow that takes too many steps, a project setup they do manually every time — they don't think to ask Claude about that.
The tool doesn't care whether the code it writes is for your app or for your shell. A .zshrc alias is just text in a file. A git hook is just a script. A Makefile target is just a recipe. Claude writes all of them equally well.
Since that first alias, I've started treating my whole development workflow as something Claude can optimize. I've asked it to write shell scripts that set up new project directories with my preferred structure. I've had it generate git aliases for commands I run ten times a day. I've used it to write CLAUDE.md files — the project-level instruction files that shape how Claude Code behaves in a specific repo.
Each one of these took less than a minute. None of them would have been worth opening a browser and researching. But all of them compound. The two-character alias saves me maybe 30 seconds per session. Across 25 sessions a day, that's over 12 minutes. Across a month, it's hours. And that's just one alias.
When to skip permissions and when not to
I want to be honest about the trade-offs here because "skip all permissions" isn't always the right call.
My rule is simple. If I'm the only person who will ever touch this codebase — personal projects, side experiments, learning repos — I skip permissions without thinking twice. The risk is low and the friction savings are real.
For shared codebases, production environments, or anything where a mistake could affect other people, I use a different approach. Anthropic built auto mode specifically for this. It catches the dangerous stuff (network requests, destructive file operations, system-level commands) while letting routine actions through. That 83% catch rate with 0.4% false positives is solid engineering.
The point isn't that everyone should run --dangerously-skip-permissions. The point is that I identified a friction point in my own workflow, chose the right permission level for my context, and used the tool itself to make that choice permanent. That process — notice friction, evaluate options, automate the solution — works regardless of which permission mode you pick.
The best developer tools aren't the ones with the most features. They're the ones you can reshape to match how you actually work. A shell alias is the smallest possible example of that. Two characters in a config file. But the habit behind it — treating workflow friction as a solvable problem, in real time, with the tool that's already running — is the real productivity gain.
The next time you find yourself copying and pasting the same command for the tenth time today, don't just sigh and keep going. Ask Claude to fix it. It probably takes 30 seconds.
What's your go-to Claude Code shortcut? I'm collecting workflow tricks — reach out if you've got one worth sharing.