Learn
Claude Code in a terminal workflow
If you already have it installed and are using it like a chat window, the gap is the workflow around it: the repository it sits in, a branch per task, and how you check the result.
Short answer
Claude Code works inside a directory of a git repository, and that setting is most of what makes it useful. The habits that turn it from a chat window into a workflow are small: a branch per task, a project instruction file it reads every session, enough isolation that you are not approving every command, and reading the diff instead of the summary.
It runs inside your repository
When you start it, the working directory becomes the project. It can follow an import into the module that defines a function, read the tests covering the area, and check the git history for how a similar change was made. Pasting a function into a chat box gives a model the function; running it in the repository gives it the function, the places that call it, and the conventions the code already follows.
So start it at the root of the project, not in a scratch directory. If the docs or a shared library live somewhere else, tell it where, or it will guess.
A branch per task
This is the single habit that changes the most. Start from a clean working tree and create a branch. A branch per task makes unrelated changes easier to spot during review.
Pair it with committing as you go and an attempt becomes cheap to abandon, because every checked change is a known point to return to. The commits matter: uncommitted edits and untracked files follow you back to main, and git status before switching shows anything still loose. That is what lets you have it try the approach you are unsure about.
The project instruction file
Claude Code reads CLAUDE.md at the repository root at the start of every session, and the file is checked in alongside the code. The rule that keeps it useful: the second time you correct the same thing, the answer goes in the file. Which command runs the tests. That migrations are generated, not edited by hand.
Keep it short and specific: a long file of general advice is followed less closely than a dozen concrete lines.
Permissions, sandboxes and containers
By default it asks before running a command you have not approved. That is right with your real machine underneath, but the interruptions push people back into using it like a chat window. More isolation buys fewer prompts, and each option protects something different.
A container Mount the repository and little else, so a wrong command mostly reaches things you can throw away. The mount itself is your real project, though: a file deleted through it stays deleted when you rebuild the container. Running Claude Code in a container has worked examples.
A sandboxed shell or virtual machine Restricting the filesystem and network around the session gives a similar boundary with less to maintain, and Claude Code has a built-in sandbox for the commands it runs. The network half matters most, since it limits what a command can reach. Judge it by the rules actually configured.
Whichever you pick, ask what the worst command that could run here would be. Isolation does nothing for a credential you hand in: a container holding a production database URL can still use it.
Read the diff, not the summary
At the end of a task it tells you what it did. That summary is what it meant to do. Usually the two match, and the cases where they do not are the ones that cost you an afternoon. So read the change itself: git diff shows unstaged edits, git diff --cached what is staged, and your editor’s branch comparison what has been committed. git status catches the new files neither diff shows.
Look for files touched that you did not expect, a test loosened instead of a bug fixed, a stub standing in for the hard part, and any change to configuration or secrets. On a small branch this takes a minute.
For anything bigger, push the branch and open a pull request in GitHub or whatever your team uses. The review view there is a comfortable place to read a whole change: file by file, with room to comment on a line and a record you can come back to. The agent can open the pull request for you with the gh command.
The loop: run, check, correct
The rhythm is short on purpose: a long session with one review at the end is hard to correct, several short passes are not.
Run
Describe the task in a sentence or two, including the constraint that actually matters. If you know where the change belongs, say so.
Check
Check means three things, in order: the diff reads correctly, the tests pass, and the behaviour is right when you exercise it yourself. The third gets skipped most, and tests written in the same session as the code can encode the same misunderstanding.
Correct
Give it the specific thing that is wrong while the context is still there. If a second correction does not land, commit anything worth keeping, clear out the rest and restate the task on a fresh branch.
See it work somewhere real
Push the branch and try the change somewhere closer to production than your laptop. On AppHaven a pushed branch is built and served at its own preview URL with its own database, described in From Claude Code to production.
Common questions
Does it work on Windows, or only on macOS and Linux?
It is a terminal program, so it works on the usual platforms: macOS, Linux distributions including Debian, and Windows through PowerShell or WSL. The current install steps per platform are in the official Claude Code documentation.
Do I need a container to use it safely?
No. Permission prompts before commands run are the default, and keeping production credentials out of the session covers much of the risk. A container or configured sandbox is worth the setup once the prompts interrupt you often enough that you are tempted to approve everything without reading.
Run it on AppHaven.
Run your business app with a managed database, private access and production backups.