Terminal Basics for Founders: 12 Commands You Need

Photo by Jake Walker on Unsplash

The terminal basics a non-technical founder actually needs come down to about twelve commands: four for figuring out where you are and what is around you, four for running and stopping things, and four for reading what happened. That is the whole working set for someone shipping a SaaS with an AI coding assistant. The terminal is not a programming language — it is a text-based file browser with a run button. The reason it feels intimidating is that it gives you no visual cues and no undo, and the reason it is worth learning anyway is that every AI coding tool you will use lives inside it.

TL;DR

• Four navigation commands (pwd, ls -la, cd, clear) cover most of what you'll do day to day.
• Ctrl+C stops whatever is running. It is the most important key combination in the terminal and the one nobody tells you about.
• Read the last line first. Error output scrolls; the actual cause is usually at the bottom, not the top.
• Never paste a command you did not write and do not understand. Microsoft and Proofpoint have both documented active malware campaigns built entirely on getting people to paste one line into a terminal.
• Tab completion and the up arrow eliminate most typos, which eliminates most of the fear.

What the terminal actually is

Open Finder on a Mac or File Explorer on Windows. You see folders, you double-click one, you go inside it, you see more folders. The terminal is that exact same thing, with the pictures removed and a place to type instead.

Two ideas explain almost everything:

You are always standing somewhere. At any moment, the terminal has one "current directory" — one folder you are inside. Every command you type runs relative to that folder. When a command fails with something like "no such file or directory," the cause is usually that you are standing in the wrong place, not that the file is missing.

Commands are programs, and arguments are the instructions you hand them. When you type ls -la, you are running a program called ls and passing it a flag -la. That is the entire grammar. There is no hidden syntax to memorize.

Here is the mental model as a picture:

flowchart TD
    A["You open Terminal"] --> B["You are standing in your home folder<br/>(~ or /Users/yourname)"]
    B --> C{"Where do you want to work?"}
    C -->|"cd projects/my-saas"| D["Now standing in the project"]
    D --> E["pwd — confirm where you are"]
    D --> F["ls -la — see what's here"]
    D --> G["pnpm dev — run something"]
    G --> H["Ctrl+C — stop it"]

On macOS, the built-in app is called Terminal and Apple has a full Terminal User Guide covering the window itself, tabs, and preferences. On Windows, the equivalent is Windows Terminal running PowerShell. Most of the commands below are the same on both; where they differ, I have noted it.

One thing worth internalizing early: there is no confirmation dialog and no trash can. When a command deletes something, it is gone. That sounds terrifying and it is genuinely the reason to be careful, but in practice you will spend 95% of your terminal time on commands that only look at things. The dangerous ones are a short, memorizable list, and they are at the end of this post.

The 12 commands

These twelve cover essentially everything I do in a terminal while building with an AI assistant. Two of them are not technically commands, but they matter more than most of the ones that are.

| # | Command | What it does | When you use it | | --- | --- | --- | --- | | 1 | pwd | Prints the folder you're currently in | Any time you're lost, or before running anything destructive | | 2 | ls -la | Lists everything here, including hidden files, with sizes and dates | Checking whether a file exists or was actually created | | 3 | cd foldername | Moves into a folder. cd .. goes up one. cd ~ goes home | Getting to your project before running anything | | 4 | clear | Wipes the screen (doesn't delete anything) | When the scrollback is too noisy to read | | 5 | cat filename | Prints a file's contents to the screen | Quickly reading a config or log file without opening an editor | | 6 | open . (macOS) / explorer . (Windows) | Opens the current folder in Finder/File Explorer | Bridging back to the visual world | | 7 | node -v | Prints a tool's version — same pattern for git --version, pnpm -v | Confirming something is installed before you debug why it isn't | | 8 | pnpm install | Downloads the project's dependencies | First time in a project, or after pulling changes | | 9 | pnpm dev | Starts your local development server | Every working session | | 10 | Ctrl+C | Stops whatever is currently running | Constantly. This is the escape hatch | | 11 | git status | Shows what files you've changed | Before committing, and any time you're unsure what the AI touched | | 12 | history | Lists the commands you've run recently | Reconstructing what you did an hour ago |

Some notes on the ones that trip people up.

cd is where most confusion lives. cd my-folder moves down into a folder that exists right here. cd .. moves up one level. cd ~ goes to your home folder from anywhere. If cd fails, run ls to see what folders actually exist at your current spot — nine times out of ten the folder name has a different capitalization or a hyphen you forgot.

Ctrl+C is not copy. In a terminal, Ctrl+C sends a stop signal to whatever is running. When your dev server is running, the terminal looks frozen — that is normal, the server is holding the window. Ctrl+C gives it back. This is the single most useful thing on the list and the thing that most often goes unexplained. (To actually copy text, use Cmd+C on macOS or Ctrl+Shift+C on Windows.)

Two shortcuts that are worth more than any command. Press Tab while typing a file or folder name and the terminal completes it for you — this eliminates typos, which eliminates most beginner frustration. Press the up arrow to cycle back through commands you already ran, so you never retype a long one. Learn these two before anything else on the list.

git status is your safety net when working with AI. After an AI coding session, git status tells you exactly which files changed. If the list contains files you did not expect, that is a signal to look before you commit. The basics of that workflow are in git basics for non-developers.

How to read what comes back

The terminal's output is where non-technical founders get stuck, and the fix is a handful of reading habits rather than any technical knowledge.

Read from the bottom up. When something fails, the terminal often prints dozens of lines. The instinct is to start at the top and panic. The actual cause is nearly always in the last five lines. Start there, and only scroll up if the bottom does not explain it.

Silence means success. Many commands print nothing when they work. If you run a command and get a fresh prompt with no output, that is usually the good outcome, not a failure. This is genuinely counterintuitive and takes a while to trust.

Learn to spot the four common failure shapes.

• command not found — the program isn't installed, or isn't on your PATH. Run the version check (node -v, pnpm -v) to confirm.
• no such file or directory — you're standing in the wrong folder, or the filename is wrong. Run pwd, then ls.
• permission denied — you're trying to touch something your user account doesn't own. Do not reflexively fix this with sudo. Figure out why first.
• EADDRINUSE or "port already in use" — a previous dev server is still running. Find that terminal window and Ctrl+C it.

Copy the whole error into your AI assistant, not a summary of it. This is the most valuable habit on the list. When you paste "it says something about a module not found," you get a generic answer. When you paste the full 40 lines including file paths and line numbers, you usually get the actual fix. The pattern is covered in more depth in debugging with Claude Code as a non-technical founder, and reading AI output as a non-coder covers the reverse direction — evaluating what comes back.

Two environment-specific gotchas worth knowing, because they produce failures that look like bugs and are not.

Running a production build while your development server is running will corrupt both. Both processes write to the same build directory, and the symptom is a page that renders with broken styling — which looks exactly like a CSS bug and is not one. If you have a dev server running in another window, stop it first.

And do not load environment variables by sourcing your .env.local file directly into your shell. Empty placeholder values get exported into the shell environment and then silently override the real file for every process you start afterward, producing failures that make no sense. Use a tool that scopes them to one command instead. The broader version of this is in environment variables and secrets management.

The commands you should never paste

This is the section that actually matters for safety, and it is not about typos. It is about a live, extremely effective category of attack that specifically targets people who have just learned that pasting things into a terminal is normal.

The technique is called ClickFix. A web page — a fake CAPTCHA, a fake software update, a fake "your download failed, run this to fix it" screen — instructs you to copy a command and paste it into your terminal. The command is usually obfuscated, often encoded, and it downloads and runs whatever the attacker wants. Microsoft's threat intelligence team documented the technique in detail and describes it as a social-engineering flow where the "fix" instructions are the attack.

It works because it routes around the operating system's normal defenses. As Microsoft explained in a follow-up on macOS campaigns: because execution starts from a user-run Terminal command rather than a downloaded app, the flow can bypass parts of the normal application trust path, including quarantine handling, code-signing evaluation, and notarization checks. Your Mac's usual "are you sure you want to open this?" prompt never appears, because from the system's perspective you typed the command yourself.

The scale is not small. In that same investigation, Microsoft confirmed more than 250 front-end domains serving these lures during a single tracking window, delivering infostealers that harvest browser credentials, keychain items, SSH keys, and cryptocurrency wallet data. Some of the infrastructure now fingerprints your browser first and shows the lure only to visitors who look like real Mac users, specifically so that security scanners see a blank page.

Apple has shipped a mitigation. Per Microsoft's write-up, macOS 26.4 and later now display a warning when you paste a potentially malicious command into Terminal, reading in part: "Possible malware, Paste blocked. Your Mac has not been harmed. Scammers often encourage pasting text into Terminal to try and harm your Mac or compromise your privacy." If you ever see that dialog, the answer is always no.

Here is the rule I use, which requires no security knowledge:

flowchart TD
    A["A command you're about to run"] --> B{"Did you write it,<br/>or did your own AI assistant<br/>produce it in your project?"}
    B -->|Yes| C{"Do you understand<br/>roughly what it does?"}
    B -->|"No — it came from a<br/>web page, chat, email,<br/>or support agent"| D["Do not run it"]
    C -->|Yes| E["Run it"]
    C -->|No| F["Ask your AI assistant<br/>to explain it line by line first"]
    F --> C

Concrete red flags that should stop you cold:

• Any command a web page asks you to paste to "verify," "fix," or "complete" something. No legitimate download, CAPTCHA, or update requires this. Microsoft's own guidance to organizations leads with exactly that point.
• Anything that pipes a download straight into a shell, in the shape of curl ... | bash or /bin/bash -c "$(curl ...)". The script executes before you ever see it.
• Base64 or otherwise encoded blobs. If you cannot read the command, you cannot consent to it.
• A support agent, DM, or "IT" contact sending you a one-liner. Microsoft has documented campaigns built on impersonating IT support for precisely this.
• sudo on anything you did not write. sudo runs a command as the machine's administrator. It is the difference between a bad command breaking a project and a bad command breaking your laptop.

And a short list of genuinely destructive commands to recognize on sight, because they are the ones with no undo: rm -rf (deletes a folder and everything inside, permanently), chmod -R 777 (strips file protections across a whole tree), > filename used alone (empties a file instantly), and git reset --hard (throws away your uncommitted work). None of these are forbidden — I use rm -rf on build folders regularly — but each one deserves a pwd first to confirm you are standing where you think you are.

Building the habits that keep you safe

A few practices that took me from anxious to comfortable, in the order they helped most.

Run pwd before anything consequential. It takes half a second and it prevents the single most common category of terminal accident, which is running the right command in the wrong folder.

Keep one terminal window per job. One for the dev server, one for running commands, one for your AI assistant. Trying to do all three in one window is where "the terminal is frozen" confusion comes from.

Use Tab completion for every path. If Tab does not complete it, the path is wrong — that is free validation before you press enter.

Ask your AI assistant to explain, not just to generate. "What does this command do, line by line, and what would it change on my machine?" is a question worth asking every single time you get a command you do not recognize, even from a tool you trust. Working with an assistant this way is the whole subject of Claude Code for non-developers.

Commit before you experiment. If your work is committed, a bad command costs you minutes instead of days. This is the real reason version control matters for non-technical founders, and it has nothing to do with collaboration.

Never paste a secret into a web form or a chat window. API keys, database URLs, and signing secrets belong in your local environment file and nowhere else. If a tool asks you to paste one into a browser to "verify" it, that is the same attack pattern in a different costume.

Frequently asked questions

Do I actually need the terminal if I'm not a developer?

Yes, if you are building with AI coding tools. Claude Code, most package managers, and every deployment workflow run there. The good news is that the surface area you need is genuinely about a dozen commands, not a career's worth of knowledge.

What's the difference between Terminal, shell, bash, and zsh?

Terminal is the app — the window. The shell is the program running inside it that interprets what you type. bash and zsh are two different shells; macOS uses zsh by default now, and most Linux systems use bash. For the twelve commands above, the difference does not matter.

How do I stop something that's running?

Ctrl+C. If that does not work, close the terminal window entirely. Neither will damage your project — worst case, a dev server needs restarting.

Is it safe to run commands my AI assistant gives me?

Much safer than commands from a web page, but not automatically safe. An assistant working inside your project has context and no incentive to harm you, but it can still be wrong about paths or scope. Read the command, ask for an explanation if anything is unfamiliar, and be especially careful with anything containing rm, sudo, or --force.

What should I do if I already pasted something suspicious?

Disconnect from the network, change the passwords for anything stored in your browser, rotate any API keys on your machine, and run a reputable malware scan. The infostealers used in these campaigns target browser credentials, keychains, and SSH keys specifically, so assume those are exposed and rotate them.

Are these commands the same on Windows?

Mostly. pwd, ls, cd, cat, and clear all work in PowerShell, though some are aliases for differently named underlying commands. The main difference is open . becomes explorer .. Everything about reading output and refusing pasted commands applies identically.

The terminal stops being scary once it's small

Terminal basics for founders are not a curriculum. They are twelve commands, two keyboard shortcuts, one reading habit, and one hard rule about what you refuse to paste. Everything else you can look up, or ask an assistant about, at the moment you need it.

The mindset shift that mattered for me was realizing that the terminal is not testing me. It is a tool that reports exactly what happened, in plain text, with no interpretation layer. Once I stopped treating unfamiliar output as a verdict on my competence and started treating it as information to paste into a conversation, the whole thing got much smaller.

If you're building a SaaS with AI coding tools and want a codebase where the commands are already scripted and documented, Coding Capybaras is the free boilerplate I built for non-technical founders working this way.