The short version
- Coding agents like Claude Code and Codex do their work by running commands in your terminal, so learn enough Bash to read a command before you approve it.
- rm -rf deletes a file or a whole folder for good. The terminal has no recycle bin, so check the exact path before you approve it.
- Slow down when an agent's command uses sudo or pipes curl into bash. Ask why when it reads or changes files outside your project folder.
- Start your coding agent from your project folder, because it treats the folder you launch it in as its workspace.
- Never run an agent with --dangerously-skip-permissions on your real machine. It doesn't know which of your files are private and won't ask before reading them.
The terminal is a window where you type commands instead of clicking around, and it's where coding agents like Claude Code and Codex do most of their work. If you build apps with AI, you need enough Bash to read the command your agent wants to run and decide whether to approve it.
This page covers the handful of commands that do most of the work, the red flags that should make you stop and look, how to check a command you don't understand, and why I never let an agent skip permissions. The video above covers the same thing.
Who this is for
This is for complete beginners and non-technical people who build with AI. If you already code and use a terminal every day, you won't find anything new here.
Why the terminal matters now
When you give a coding agent a task, it doesn't click buttons for you. It reads and writes files, and it runs commands in your terminal. Some of those commands are long, and if you can't read them, you have no idea whether one is a normal step or something that wrecks your machine.
A command doesn't have to delete anything to be a problem. It can read your .env file or some other file full of API keys, and then that data goes to the AI company's servers. Unless you know what a command does, you can't tell whether it's safe to run.
A terminal is the opposite of a GUI. In a GUI you point and click. In a terminal you type a command, press Enter and read what it prints. Every operating system has one: search for "terminal" in your start menu or Spotlight and it opens an empty window with a prompt.
Bash on Mac, Linux and Windows
The language you type commands in is called the shell, and the one I use is Bash. Linux uses Bash by default. Macs have used zsh by default since macOS Catalina (2019), but every command on this page works the same in zsh.
On Windows, install WSL (Windows Subsystem for Linux). It runs Linux inside Windows, so you get Bash. Open PowerShell as administrator and run:
wsl --install Restart when it asks, then open the Ubuntu app it installed. Microsoft's WSL install guide has the details.
The alternative on Windows is PowerShell, which is a different language with different commands. I'd ignore it. Unless you're building something specifically for Windows, you'll almost never need it, and the commands your agent runs and the answers you'll find online are mostly Bash.
The commands that do most of the work
A small set of commands covers about 80% of what you'll do in a terminal, and of what your agent will ask to run. Open a terminal and type these along with me.
Make a folder and move around
mkdir cli-demo cd cli-demo pwd mkdir makes a directory (a folder). cd stands for change directory, so cd cli-demo moves you into it. pwd prints the folder you're in right now, which is the first thing to check when something looks off.
cd .. cd ~ cd ~/cli-demo cd .. goes up one folder. cd ~ takes you to your home folder (~ is short for it). To get anywhere else, give cd the path, like cd ~/cli-demo (a new terminal opens in your home folder, so that's where cli-demo ended up). If the screen gets cluttered, type clear.
Create and list files
touch file1.txt file2.txt ls ls -la touch creates empty files. ls lists what's in the current folder. ls -la lists it with details: -l adds each file's size and date, and -a includes hidden files, the ones whose names start with a dot. Your .env file is one of those, so plain ls won't show it.
To put some text in a file, open it in a terminal text editor. I use Micro (micro file1.txt); nano comes with most systems. After I wrote "This is some random text." into file1.txt, ls -la showed it at 26 bytes and file2.txt at 0:
-rw-r--r-- 1 hassan hassan 26 Nov 11 16:40 file1.txt -rw-r--r-- 1 hassan hassan 0 Nov 11 16:40 file2.txt Copy and move files
cp file1.txt copy-of-file1.txt mkdir backups mv copy-of-file1.txt backups/ ls backups cp copies a file to a new name or into another folder. mv moves it, so after the mv the copy is gone from cli-demo and sits in backups. mv also renames: mv old.txt new.txt.
Delete files and folders
rm file2.txt rmdir backups rm -rf backups rm deletes a file. rmdir deletes a folder, but only an empty one, so here it fails with rmdir: failed to remove 'backups': Directory not empty. That's a safety check.
rm -rf skips it. -r (recursive) deletes the folder and everything inside it, and -f (force) never asks for confirmation and doesn't complain if the path doesn't exist.
There's no recycle bin in the terminal. A file you delete with rm is gone, and you won't get it back. Only use it on files you actually want gone, and be very careful when your agent asks to run it.
Read files
cat notes.txt head notes.txt head -n 3 notes.txt tail -n 3 notes.txt For these I made a notes.txt with twelve lines, "line one" to "line twelve". cat prints a whole file, exactly what you'd see if you opened it in an editor. head prints the first 10 lines, and -n 3 changes that to 3. tail does the same from the end of the file.
Search inside files and for files
grep "seven" notes.txt grep -n "line t" notes.txt find . -iname "*.tsx" grep searches a file for text and prints every line that contains it. -n adds the line numbers, which is how an agent finds where to edit:
2:line two 3:line three 10:line ten 12:line twelve find searches for files. The . means "start in the current folder", * is a wildcard that matches anything, and -iname matches the file name without caring about upper or lower case. In my test folder, -iname "*.tsx" found both App.tsx and Button.TSX, while -name "*.tsx" only found App.tsx.
Download from the internet
curl https://example.com curl sends an HTTP request to a URL and prints what comes back, here the HTML of the page. It's a command-line HTTP client, so it can send POST and PUT requests too. Your agent uses it to read web pages and download scripts, which is why it shows up again in the red flags below.
There are more commands worth knowing, like less, chmod, which and echo. I keep them in a command line cheat sheet with an example for each.
Start your agent in the right folder
When you launch a coding agent from the terminal, it treats the folder you're in as its workspace. Start it in your project folder:
cd ~/projects/my-app claude If you launch it from your home folder instead, it doesn't know which project you mean and treats your whole home folder as its working area, which is not what you want. Run pwd first if you're not sure where you are.
Red flags in an agent's command
Once the agent is working, it asks your permission before running commands. Most are harmless. These are the ones where your spidey sense should start tingling:
| Pattern | What it does | What to check |
|---|---|---|
rm -rf | Deletes files or whole folders for good | That the path is exactly what you expect, with no stray space or * |
sudo | Runs the command as administrator, with power to change or delete anything on the machine | Why it needs admin rights at all |
| `curl ... \ | bash` | Downloads a script and runs it straight away, without you reading it |
| A path outside your project | Reads or changes files the project doesn't own | Why it needs that file |
The last one is easy to miss. If I'm in my obs-scene-switcher folder and the agent wants to read something in ~/.ssh or another project, I want to know why it needs a file that isn't part of this project.
For curl | bash, the safer route is to save the script to a file with -o, read it, and only then run it:
curl -fsSL https://example.com/install.sh -o install.sh less install.sh bash install.sh Ask an LLM to explain the command
Once you've ruled out the obvious red flags, you still need to understand the command. My probably controversial take: copy the whole command, paste it into ChatGPT or Claude in a new conversation, and ask:
Explain what this command does, step by step, and tell me the worst thing that could happen if it's wrong: <paste the command here> That gives you a breakdown of each part and the worst case, and you decide whether it fits what you asked the agent to do.
This only works because you learned the basics first. If you don't know what rm -rf or a pipe does, even a perfect explanation won't help you make a good call. With the basics, you'll have your own read on the command before you paste it, and the explanation fills in the parts you didn't know.
Never skip permissions on your real machine
Claude Code has a --dangerously-skip-permissions flag, and Codex has --dangerously-bypass-approvals-and-sandbox (alias --yolo). Both let the agent run any command it wants without asking you first.
Don't use them on your real machine. You never know when a model is going to run something stupid, and it doesn't even have to destroy anything. Say Claude wants to read a file to understand your project better, and that file is a private document about your company that you don't want on Anthropic's servers. Claude doesn't know it's private. With permissions skipped, you never get the chance to say no.
These models don't run stupid commands all the time, although that's a real possibility. The bigger problem is that they don't have your context, so they don't know what's right and wrong for your business.
So learn the basic commands, watch for the red flags, ask an LLM about anything you don't recognize, and keep the permission prompts on. Then play around in the terminal and run your own commands. Do that and you'll be fine using a coding agent on your machine.
Originally published on hassandev.me.