Running Scripts with Claude Code
How Claude Code executes terminal commands, how permission tiers control what runs automatically, and workflows for operators managing multiple client projects.
--- title: Claude Code can write and run its own scripts description: Claude Code doesn't just suggest commands. It writes executable scripts, makes them runnable, and executes them on your machine. Here's what that means for operators and why the permission system is the only thing standing between you and a very bad day. author: FractionalSkill ---
Claude Code doesn't just suggest commands, it runs them
Most operators who pick up Claude Code quickly figure out that it can run terminal commands. Run a Git commit, call a CLI tool, check file output. That part feels natural pretty fast.
What catches people off guard is this: Claude Code can also write its own scripts from scratch, make them executable, and run them. Autonomously. On your machine.
That's a different thing entirely.
When you ask Claude Code to "set up a scripts folder and create a script to launch Chrome in developer mode," it doesn't paste code into the chat. It creates the folder, writes the shell script, makes it executable with the right permissions, and asks to run it. If you say yes, Chrome opens. In developer mode. Because Claude wrote a .sh file and executed it.
That capability is why this section exists in the power features guide and not the basics guide.
What Claude Code actually does when it runs a script
Claude Code has persistent access to your terminal environment. It can:
- Create new files (including executable scripts)
- Set file permissions (
chmod +xmakes a file runnable by the system) - Run those files as programs
- Monitor the output in real time
The workflow looks like this:
You: Please create a scripts folder and write a script to launch Chrome in dev mode
Claude: Creating /scripts directory...
Writing chrome-dev.sh...
Making chrome-dev.sh executable...
Run chrome-dev.sh? (y/n)
You say yes. Chrome opens. The script ran.
This is not Claude "helping you write a script." Claude wrote the script, configured it, and executed it. The distinction matters because it defines your exposure. Every permission prompt Claude shows you is a decision point, not a formality.
> Hard rule: Never auto-accept (Shift+Tab to purple mode) when Claude is writing or running scripts. Each permission prompt is your checkpoint. Treat them that way.
The permission system is doing real work here
Claude Code's permission system was covered in an earlier guide, but it becomes genuinely important once scripts are involved. Three buckets:
| Bucket | What it means | Script-specific guidance |
|---|---|---|
| Allow list | Claude runs these automatically, no prompt | Never put script execution here |
| Deny list | Claude blocks these entirely until you remove them | Good default home for script execution |
| Ask each time | Prompt appears for your approval each time | Acceptable if you're actively monitoring |
Running scripts should almost never go in the allow list. The deny list blocks a permission type completely, which is useful while you're still learning what Claude Code does with script execution. You can remove a script type from the deny list when you specifically need it and add it back after. That's the right posture for anything that modifies files, starts processes, or touches system resources.
The permission prompt isn't friction. It's the entire safety mechanism.
Practical workflows where this actually helps operators
The Chrome dev mode example was intentionally weird. It demonstrates the capability, not a typical deployment. Here's where operators actually benefit from Claude Code running scripts:
Database migration monitoring. You have a SQL migration script that pushes schema changes to production. Claude Code can execute that migration, monitor the output line by line, flag errors as they appear, and log the result. You stay in one window. You see everything as it happens.
Automated reporting scripts. You run a report every Monday morning across three client engagements. A script that pulls structured data from each project folder and outputs a formatted summary can be written once and run on demand. Claude Code can build it and run it for you.
File processing pipelines. Renaming, reformatting, or reorganizing large batches of files across client deliverables. A script handles the repetitive work. Claude writes it, you review it, it runs.
CLI tool orchestration. If your workflow involves calling multiple CLI tools in sequence (Git operations, content builds, deployment checks), Claude Code can write a script that chains them and execute it when you're ready.
The common thread: tasks that are repetitive, sequential, and well-defined are good candidates. Tasks that involve creative judgment or client-specific context are not.
Why sandboxed environments matter for this workflow
If you plan to use Claude Code's script execution capability regularly, you should know what a sandboxed or containerized environment is, even if you're not a developer.
A sandbox is a contained environment, typically a virtual machine or container, where Claude Code runs with limited access to your actual system. Scripts execute inside the sandbox. If something goes wrong (a script deletes the wrong files, opens unexpected connections, consumes resources), the damage stays contained. Your real machine is untouched.
Running scripts directly on your local machine means mistakes happen to your local machine. That's acceptable for low-stakes, well-understood scripts. It's a real risk for anything you haven't reviewed carefully.
The advanced workflow, covered in a later section, is to run Claude Code inside a cloud-based sandbox: the scripts execute there, the output comes back to you, and your local environment is never exposed.
For now, the practical guideline is this:
- Review every script before approving execution. Ask Claude to show you the file contents first.
- Run unfamiliar scripts in a test folder, not inside a live client project directory.
- Use the deny list for script execution permissions until you've established trust with a specific workflow.
> What good looks like. Claude writes a migration script. You ask it to display the file contents. You review the logic. You confirm it looks right. Then you approve execution and monitor the output. That two-minute review is the difference between a controlled workflow and a bad afternoon.
The real constraint is attention, not capability
Claude Code can write sophisticated scripts. It can chain commands, handle conditional logic, and produce executable files that would take a non-developer significant time to write manually.
The constraint is not what Claude Code can do. It's your ability to stay in the loop as it does it.
Running scripts in Claude Code is a force multiplier for operators who know what outcome they're looking for and can recognize when the script achieves it. It's a liability for operators who approve permission prompts without reviewing what they're approving.
The permission system exists precisely because this capability is powerful. Use the prompts. Read the scripts before you run them. Keep the allow list short.
When you deploy this workflow with those habits in place, you get something genuinely useful: the ability to automate the operational repetition in your client engagements without writing a single line of code yourself.
That's worth the extra 60 seconds of review.