An AI coding assistant such as Claude Code does not just suggest code. It reads your files, edits them and runs commands on your machine, with your permissions. That is what makes it useful, and it is also why it needs limits. Anything you can do from a command prompt, it can do too.
The article on stopping AI training on your data covers what the assistant sees and where that data goes. This one is about what it is allowed to do. Below is the list of jobs I keep for myself, and the settings that back the list up.
Settings were checked against the Claude Code documentation in October 2026. Other assistants have similar controls under different names.
The rule behind the whole list: the assistant may do anything that is easy to undo, and must ask before anything that is not. Editing a file under git is easy to undo. Dropping a table, pushing to a shared branch, uploading to the live server or emailing a client is not.
Mistakes are not the only risk. An assistant follows instructions it finds in what it reads - a comment in a downloaded library, a web page, an issue description, a log file. Text written to look like an instruction can steer it. The fewer irreversible actions it can take on its own, the less such text can achieve.
The assistant never connects to a live database with a user that can change it. When it needs to look at real data, it gets a MySQL account that can only read:
CREATE USER 'ai_read'@'localhost' IDENTIFIED BY '...';
GRANT SELECT ON shop.* TO 'ai_read'@'localhost';No INSERT, UPDATE, DELETE, DROP or
ALTER, and no access to other schemas. Scripts that change data are written by
the assistant, read by me, and run by me. If you want to see exactly what it queried, turn on
the MySQL general query log while it works.
A read-only account is a real lock: the server enforces it, whatever the assistant types. That makes it worth more than any rule in the assistant's own settings.
The assistant never uploads to a live server. It does not get FTP or SSH credentials for production, and the folder that mirrors the live site is outside its reach. Changes go live when I have read the diff and copied them across myself.
A deployment is the point where a mistake stops being private. Keeping that step manual costs a minute and guarantees that every change reaching users has been looked at by a person.
reset --hard, no rebase of
published commits, no git clean. These destroy work that is not saved
anywhere else.Git is also the safety net for everything else on this list. Commit before a session, and
every file the assistant changed can be compared and reverted. Claude Code has its own
checkpoints (/rewind), but they only cover edits made through its file tools -
not files changed, moved or deleted by commands it ran. Git covers both.
Deleting folders, emptying tables, killing processes, changing system settings: anything that cannot be reversed from git needs my approval each time. In practice the assistant rarely needs these, and when it does, reading the exact command before it runs takes seconds.
Work for clients is kept in its own folders and its own sessions, never mixed with personal projects in one conversation. That keeps one client's code from appearing in another's context, and makes it easy to answer the question "which tools have seen this code?". What a confidentiality agreement may say about AI tools at all, and which plans keep your data out of training, is covered in the training article.
Emails, support replies, forum posts, pull request descriptions, comments on a client's issue tracker: the assistant can draft them, but I send them. A wrong sentence in a message to a client does more damage than a wrong line of code, and it cannot be reverted.
Ask for a change and an assistant will make it, in whatever way it thinks best. Left alone it adds layers, renames things to its own taste and fixes problems that were not asked about. For anything beyond a small change, I ask for a plan first and decide the approach before any code is written. Claude Code's plan mode is made for this: it reads and proposes, and edits nothing until the plan is approved.
Claude Code reads permission rules from settings.json. Rules in
~/.claude/settings.json apply to every project; rules in
.claude/settings.json inside a project apply to that project and can be
committed with it. There are three lists:
Deny is checked first, then ask, then allow, and a deny anywhere wins - a deny in your user settings cannot be overridden by a project's allow. A starting point:
{
"permissions": {
"deny": [
"Bash(git push *)",
"Bash(git reset --hard *)",
"Bash(git clean *)",
"Bash(git rebase *)",
"Bash(rm -rf *)",
"Bash(mysql *)",
"Bash(ftp *)",
"Bash(scp *)",
"Bash(curl *)",
"Read(**/.env)",
"Read(**/*.pem)",
"Edit(//d/live-site/**)"
],
"ask": [
"Bash(git commit *)"
]
}
}Bash(git push *) matches git push on its own and with any
arguments.Read and Edit rules use the same patterns as
.gitignore. **/.env matches a .env file in any
folder.//d/live-site/** is everything under D:\live-site.curl stops the assistant sending data to an address it found in
something it read. Web pages it genuinely needs can be allowed per site with rules such as
WebFetch(domain:docwiki.embarcadero.com).Deny rules match the command as it is written. Bash(curl *) does not match
C:\Tools\curl.exe ..., a command wrapped in sh -c, or a script that
calls curl. The rules stop the assistant doing these things casually and make it ask; they
do not stop a determined attempt. On macOS, Linux and WSL 2, Claude Code can also run
commands in an operating-system sandbox that limits files and network access; on native
Windows it cannot.
That is why the most important controls on this list are outside the assistant: a database account that can only read, deployment credentials the assistant's machine does not hold, and a git remote it is not allowed to push to. Those hold whatever command is run.
Claude Code can also skip permission prompts altogether
(bypassPermissions). That is meant for a throwaway container or virtual machine,
not a development PC with client code, saved passwords and a mapped drive to the live server.
The normal mode, which asks before running commands, is the right one for a working
machine.