Hi folks,<\/p>\n
The first week with an AI coding agent goes like this: it asks before every command, you press Enter fifty times an hour, and on day three you start pressing Enter without reading. That is the worst of both worlds. You are interrupted all the time and you are not really reviewing anything.<\/p>\n
The fix is not to switch everything off. The fix is a small, deliberate permission file per project: routine read-only commands run without asking, risky ones always ask, and a few things are simply forbidden. Here is how I set this up for a TYPO3 project in DDEV, based on the official Claude Code permission rules.<\/p>\n
Permission rules live under Team rules go into Some notes on the details, because the details are where these files go wrong:<\/p>\n This surprised me when I read it carefully: a Bash deny rule matches the command text Claude writes, not the program. A The Bash sandbox is enforced by the operating system (Seatbelt on macOS, bubblewrap on Linux and WSL2). Sandboxed commands can only write where you allow it and reach only allowed network hosts through a proxy, and that holds for child processes too. You switch it on with Now the honest part for DDEV users: the documentation says With this, the prompts that remain are few, and each one is a real decision. Cheers!<\/p>\n Approving every command is tiring, approving everything is dangerous. A settings.json for a TYPO3 project in DDEV, rules I never add, and how hooks and the sandbox fit in.<\/p>\n","protected":false},"author":1,"featured_media":109,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18],"tags":[34,35,45,43],"class_list":["post-108","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-engineering","tag-ai-agents","tag-claude-code","tag-devops","tag-security"],"yoast_head":"\npermissions<\/code> in a settings file, in three lists: allow<\/code>, ask<\/code> and deny<\/code>. Three facts from the documentation shape everything else:<\/p>\n\n
Bash(git push *)<\/code> cannot be opened by a narrow allow.<\/li>\n.claude\/settings.json<\/code> only apply after you accept the workspace trust dialog for that folder. Deny and ask rules apply anyway, because they only restrict.<\/li>\n<\/ol>\n.claude\/settings.json<\/code> (committed). Personal additions go into .claude\/settings.local.json<\/code>, which is not meant for git.<\/p>\nThe project file<\/h2>\n
{\n \"permissions\": {\n \"allow\": [\n \"Bash(ddev describe)\",\n \"Bash(ddev composer validate *)\",\n \"Bash(ddev composer show *)\",\n \"Bash(ddev composer audit *)\",\n \"Bash(ddev exec vendor\/bin\/typo3 cache:flush)\",\n \"Bash(ddev exec vendor\/bin\/typo3 upgrade:list *)\",\n \"Bash(ddev exec vendor\/bin\/typo3 site:list)\",\n \"Bash(git diff *)\",\n \"Bash(git log *)\",\n \"mcp__project-checks__*\"\n ],\n \"ask\": [\n \"Bash(ddev composer require *)\",\n \"Bash(ddev composer update *)\",\n \"Bash(ddev exec vendor\/bin\/typo3 extension:setup *)\",\n \"Bash(ddev exec vendor\/bin\/typo3 upgrade:run *)\",\n \"Bash(git commit *)\"\n ],\n \"deny\": [\n \"Bash(git push *)\",\n \"Bash(ddev delete *)\",\n \"Bash(ddev import-db *)\",\n \"Read(.\/config\/system\/credentials.php)\",\n \"Read(.\/public\/blog\/wp-config-production.php)\",\n \"Read(.\/.project-migration\/backups\/**)\"\n ]\n }\n}<\/code><\/pre>\n\n
*<\/code> goes.<\/strong> Claude Code matches everything before the first *<\/code> literally. Bash(git log *)<\/code> allows only git log<\/code>; Bash(git *)<\/code> allows every git command, including push<\/code> and -c<\/code> options that run programs. A trailing *<\/code> also matches the bare command, so Bash(ddev composer validate *)<\/code> covers ddev composer validate<\/code> as well.<\/li>\nBash(git diff *)<\/code> does not approve git diff && rm -rf var<\/code>; every part must match on its own. Deny and ask rules match any part, even inside a subshell.<\/li>\nls<\/code>, cat<\/code>, grep<\/code>, git status<\/code> and other read-only forms of git run without a prompt by default. You do not need allow rules for them; I keep git diff<\/code> and git log<\/code> in the list only to be explicit.<\/li>\nRead(...)<\/code> deny rules stop the Read tool and file commands that Claude Code recognises, like cat<\/code> or head<\/code>, and redirections. The paths above are the real secret locations of hoja.in: production credentials and the WordPress production config are not in git, and database dumps with password hashes sit in a git-ignored backup folder.<\/li>\n<\/ul>\nWhat I never put into allow<\/h2>\n
\n
Bash<\/code> or Bash(*)<\/code>. That is every command.<\/li>\nBash(ddev exec *)<\/code>. The documentation explains it for runners like docker exec<\/code> or npx<\/code>: a prefix rule on a runner allows whatever comes after it. ddev exec<\/code> is such a runner; ddev exec rm -rf public\/fileadmin<\/code> would match. Allow the inner commands one by one instead.<\/li>\nBash(ddev composer *)<\/code> or Bash(composer *)<\/code>. Composer runs scripts and plugins from the packages you install. require<\/code> and update<\/code> stay on ask.<\/li>\nBash(curl *)<\/code> and friends. Use the WebFetch tool with WebFetch(domain:docs.typo3.org)<\/code> rules for documentation instead.<\/li>\nbypassPermissions<\/code> mode outside a container or VM. The docs say exactly that, and I agree.<\/li>\n<\/ul>\nDeny rules are not a wall<\/h2>\n
Bash(git push *)<\/code> stops git push origin main<\/code>, but not git -C . push origin main<\/code> or sh -c 'git push'<\/code>. The documentation lists these cases openly. Deny rules catch the normal way the model writes a command. For a real boundary you need one of the next two layers.<\/p>\nLayer two: hooks<\/h2>\n
PreToolUse<\/code> hook is your own script that sees every tool call before it runs. It can allow, ask or deny, and a hook that exits with code 2 blocks the call even if an allow rule matches. A hook cannot open what a deny or ask rule closed, though; those are still evaluated. For hoja.in, the guard hook of my migration plugin denied database-writing TYPO3 commands unless a dump younger than 24 hours existed. No string rule can express “only if a fresh backup exists”, a script can.<\/p>\nLayer three: the sandbox<\/h2>\n
\/sandbox<\/code> or in settings:<\/p>\n{\n \"sandbox\": {\n \"enabled\": true,\n \"network\": {\n \"allowedDomains\": [\"github.com\", \"packagist.org\", \"repo.packagist.org\"]\n }\n }\n}<\/code><\/pre>\ndocker<\/code> is incompatible with the sandbox, and DDEV is Docker. The documented way out is sandbox.excludedCommands<\/code>, for example \"ddev *\"<\/code>, and excluded commands run with your full access. So in a DDEV project the sandbox protects host-side commands (git, npm, scripts), while every ddev<\/code> command depends on permissions and hooks again. Know this before you rely on it. Also good to know: hooks and local MCP servers always run outside the sandbox, with your user’s rights.<\/p>\nA rhythm that works<\/h2>\n
\n
\/permissions<\/code> from time to time; it shows every rule and the file it comes from.<\/li>\n<\/ol>\nFurther reading<\/h2>\n
\n