Running Claude in the terminal lets you change how the AI runs, not just what you ask it. Here is what that actually looks like in my setup, and the part where I crashed my computer a few times.
Most people meet AI through a chat box. You type, it answers, it waits. That is a conversation, and conversations are one turn at a time.
When you run Claude in the terminal instead, something changes. You get to reach in and decide what happens automatically before it acts, after it acts, and even whether it is allowed to stop. You are no longer just choosing the words. You are choosing the reflexes.
Put them together and a simple chat turns into something that supervises itself, refuses to cut corners, and emails you when it needs a decision. The catch, and it is a real one, is that the moment it can spawn its own helpers and run unattended, it can also cheerfully spawn seventy of them at once and take the whole computer down. We will get there.
There are a handful of moments a hook can grab onto: when a session opens, right after you hit enter but before the AI reads your message, right before it uses a tool, right after, and the important one, when it is about to go idle and stop. My setup wires up dozens of these. Here are the ones worth meeting.
One hook watches every attempt to edit a code file. If there is no test for that file yet, the edit is blocked before it happens. The AI is forced to write the test first. A second hook fires when the AI thinks it is finished: it runs the whole test suite and refuses to let the session stop if anything fails.
Why it matters: AI coding assistants have a famous bad habit of quietly deleting a safety check just to make a test pass, then announcing "done." These two hooks make that structurally hard. Tests have to exist before the code, and pass before the work can rest. It is the difference between an assistant that says it did the work and one that had to prove it.
Whenever the AI tries to send me an email, a hook checks one thing: did I already write to this person and not hear back yet? If so, it blocks the second message and tells the AI which threads are still open.
Once you let an assistant send email on its own, the nightmare is inbox flooding: five messages before you have replied to the first. This encodes a social rule, not a technical one. One open question per person, wait for the human. A genuine emergency marked urgent still sails straight through, so a real alert never gets trapped behind politeness.
Before the AI even sees my message, a hook looks at what I am asking and which project I am in, then quietly pulls in the relevant notes, past lessons, and house rules from my memory files and hands them over. A small local model picks which few notes are worth loading so it stays cheap.
This is what makes it feel like it knows me. I do not re-explain my infrastructure or my preferences or the thing we learned last Tuesday. A generic chat forgets. A hook-wired terminal briefs itself before it opens its mouth.
A cluster of small hooks act as bumpers: block any command that would wipe a database, refuse to read password and secret files so they never end up in a transcript, honor a "this client's repo is read-only" agreement so autonomy never crosses a line someone agreed to, and cut off a helper that runs a command which never exits.
Guardrails are the price of autonomy. The more you let the AI act on its own, the more you want automatic reflexes for the handful of actions you can never take back.
The whole trick behind turning a chat into a worker is this: it no longer needs you present to take the next step. It can set an alarm, wake up, look at what needs doing, do it, and set another alarm. Here are the three flavors I actually run.
A per-project loop wakes every thirty minutes and checks my inboxes for replies to threads the AI itself started. When a reply lands, it spins up a helper to act on it. So the assistant can email me a question, go dormant, and pick the conversation back up the moment I answer, even hours later. A pen pal that never forgets to check the mailbox.
Lock a session to one north-star goal and let it drive itself to done. It pins the goal to a file, builds a checklist, and wakes itself on a timer. The clever part: on every wake it asks a separate evaluator AI a blunt question, "am I still driving at the goal, or am I polishing something that does not matter?" The evaluator names the single most valuable next action and the loop does it. It is an assistant with a built-in manager tapping it on the shoulder each cycle.
The go-AFK, keep-working mode. Point it at the to-do list and it picks the highest-value item, does it properly (tests first, an independent skeptic AI checks the work, a real end-to-end verification), ships it if it passes, and moves on. It only interrupts me when it hits something a human genuinely must decide: a password it cannot hold, a message it cannot un-send, a real judgment call. Everything reversible, it just does.
Underneath, several of these run as always-on background sessions, one per project, kept warm so they react to an email reply or a scheduled tick instead of starting cold. That is what makes it feel like a standing assistant rather than a tool you launch. There is a version of it quietly resident, waiting, for each project.
The failure mode is not the AI going rogue. It is the AI being too eager to work in parallel with nothing capping it. Give it the ability to spawn seventy workers and it will, gladly, at 2am, all at once.
Within a single 24-hour stretch the same root cause surfaced four separate ways: a build process that ballooned to 27GB, a monitoring loop that ran 7.5 hours with no time limit, the 100-build pile-up above, and a local model that quietly climbed from 12GB to 23GB overnight until it ran the machine out of memory.
The fix was boring and correct: put a hard ceiling on the whole family of processes so every session and helper inherits it, then hunt down the holes (anything a scheduled job launched escaped the fence and had to be wrapped on its own). Now every new long-running thing gets a memory cap, a time limit, and a CPU cap. Always.
That is the real trade. Hooks and loops let you hand the AI real autonomy and real horsepower. The moment you do, you become the one responsible for the seatbelts. Worth it. Just cap everything first.
| Kind | What it is | Fires | Why it is worth it |
|---|---|---|---|
| Hook | Test-first enforcer | before an edit, and at stop | Can't touch untested code, can't finish on broken code. |
| Hook | Bounded email | before a send | No second message before you reply to the first. Manners. |
| Hook | Context inject | before it reads you | Auto-loads the right memory. It already knows your world. |
| Hook | Seatbelts | before a command | Blocks data-wipes, secret reads, runaway commands. |
| Loop | Email loop | every 30 min | Checks the inbox, resumes the moment you reply. |
| Loop | Goal loop | self-paced | Drives one goal, a manager AI checks it stays on target. |
| Loop | Backlog loop | self-paced, AFK | Grinds the to-do list, escalates only when truly stuck. |
| Rule | Cap everything | always | Memory, time, and CPU limits on every long-running thing. |
None of this requires being a programmer to understand. It is the same move over and over: take a moment in how the AI runs, and decide what should happen automatically. Do that a few dozen times and the chat quietly becomes a colleague.