The permissions system is too YOLO - we need to add context to tool permission requests

[GroovyCarrot]

Hey so there has been a little bit of discussion around allowed_commands including a stale PR.

I think though fundamentally the current permission system is basically just all or nothing, and for me (and I would hope for every one else too) this is just too much of a security dealbreaker to just be able to let a model go wild on my machine. I've already had one model nuke all the work I was doing, which was fortunately just me giving it a trial task to run at, but once you approve the bash tool for the duration of the session it has free reign to make whatever poor decisions it likes and for me that makes crush an unusable tool as it exists now for agentic workflows.

I usually work with the copilot cli which has this really well implemented, so I have taken inspiration from that to make crush a viable workflow tool for me. Here's the changes I have made and although I have a PR to submit for this, it's open for discussion and I can continue to use my fork - so I'm happy either way.

What This Does

It replaces the old blanket "Allow for session" permission model with granular, context-aware approvals for bash commands.

How it works

When you run a command like cd /tmp && ls ./src && pwd , the system now:

1. Parses the command into individual context tokens:
   • command:cd , command:ls , command:pwd
   • path:/tmp , path:/repo/src
2. Records per-token grants — when you click "Allow for session", it stores each token independently, not as a single blanket approval
3. Auto-approves future requests where all tokens are already granted:
   • Running ls /repo/src alone → ✅ auto-approved (both command:ls and path:/repo/src were approved)
   • Running pwd alone → ✅ auto-approved ( command:pwd was approved)
   • Running ls /other → ❌ still prompts ( path:/other was never approved)
4. Composes conservatively — a command auto-approves only when both its command tokens AND its path tokens are all approved. Approving rm /tmp/x does not auto-approve rm /repo .
5. Supports config-level allowlists — allowed_commands and allowed_paths in crush.json work the same way, using prefix matching ( command:go satisfies command:go test ).

Unsafe constructs (command substitution $() , backticks, redirects, sh -c , eval , loops, conditionals) are fail-closed — they emit an opaque command!:... token that can only be approved by exact match, never auto-approved. I will probably try to improve on this if I find it occurs frequently enough and without good reason but these scenarios only usually trigger for me when doing some analysis / data collection exercise, or a refactor that affects many files, and in these cases I don't mind just hitting approve.

Changes to the Permission Package

The crux of the changes to the permission system is effectively just adding optional context to the tool permission request and recording that context when it is approved for the duration of the session.

What Changed

Request model — CreatePermissionRequest and PermissionRequest now carry a Contexts []string field. This is opaque to the service — it just checks whether every context token
is satisfied. Tools that don't use it leave it empty.

Session grants — PermissionKey gained a Context string field. When a context-aware tool
is approved for the session, one key is stored per context token ( PermissionKey{SessionID, ToolName, Action, Context} ). Legacy tools still use the old key shape (
PermissionKey{SessionID, ToolName, Action, Path} ).

Resolution flow — Request() now has two auto-approval paths:

• If Contexts is non-empty: every token must be satisfied (by config tokens or prior
session grants)
• If Contexts is empty: falls back to legacy {ToolName, Action, Path} key lookup

Grant recording — GrantPersistent records one key per context token when Contexts is populated, otherwise records the legacy key. The Path field is intentionally omitted from contextual keys because location semantics are captured by path: tokens.

Config matching — allowed_commands and allowed_paths from crush.json are translated at startup into command: and path: tokens and checked first in contextSatisfied() .

Impact on bash tool

This is the primary beneficiary. Before, "Allow for session" on cd /tmp && ls ./src && pwd granted just any use of the bash tool.

Now, each constituent command and path is independently reusable. Approve the chain once, and ls /repo/src runs alone later with no prompt. This is the intended behaviour.

Impact on Other Tools

For edit , write , view , multiedit , etc. — no change at all. They never populate Contexts , so they fall through to the legacy {ToolName, Action, Path} lookup. The old "Allow for session" behaviour is preserved because the legacy lookup is still checked in step 6 of Request() .

What It Enables

This design is tool-agnostic. Any tool can start using Contexts without changing the permission service. If a future tool wants to grant file operations by directory, or Git operations by repository, it just emits the appropriate tokens. The service doesn't need to know what the tokens mean.

---

crush.json example

This is the relevant parts of the config I use

{
  "$schema": "https://charm.land/crush.json",
  "permissions": {
    "allowed_tools": [
      "multiedit",
      "view",
      "ls",
      "grep",
      "write",
      "edit"
    ],
    "allowed_commands": [
      "cd",
      "ls",
      "wc",
      "mkdir",
      "sed",
      "awk",
      "grep",
      "head",
      "tail",
      "find",
      "xargs",
      "tee",
      "touch",
      "go fmt",
      "go build",
      "go test",
      "go run",
      "go doc",
      "go list",
      "go vet",
      "go tool",
      "make",
      "yarn run",
      "yarn build",
      "yarn test",
      "yarn tsc",
      "git status",
      "git log",
      "git diff",
      "git show"
    ],
   "allowed_paths": [
     "/tmp"
   ]
}

---

The PR for my implemented changes is open here: #3076

It'll need some more work, but I figured I'd open this discussion and see if we agree this approach is the way forward, and come up with some actions that need to be taken to either adopt this as it is, or design the system as intended.

What would need to be done after this is probably get edit and multiedit to provide path: token context so that file modifications are limited to allowed paths; and also re-use pre-approved paths from the bash tool, and vice-versa.
I think also adding the working directory to the pre-approved context on start up would be expected implied behaviour too.

This was done relatively quickly to just give me something workable so I can use crush to do my other work. Happy to find some time to finish it off though.

[meowgorithm]

I appreciate the comment and I do generally agree with this. Thanks for posting a discussion about it.

One thing to keep in mind in the implementation: we’ll need to be sensitive about commands in redirections, pipelines, conditionals and so on, and well as flags and what not (for example, npm install versus npm install -g.

[GroovyCarrot]

Hey thanks for the response, so as I said in the discussion with @DanEble, it's not necessarily sandboxing that I want to achieve with the permission system, but just control to make sure that we're keeping the model on track. I never auto approve things like go get or npm/yarn install because adding third party packages is something I want to maintain full control over those decisions; I might well approve that one command as it tries to run it, but only after I've reviewed it. I think though if we wanted to allow npm install but block npm install -g then we would need to maintain a list of blocked_commands in the config as well to get that level of granularity

[DanEble]

When you run a command like cd /tmp && ls ./src && pwd , the system now:

1. Parses the command into individual context tokens:
   •  `command:cd` ,  `command:ls` ,  `command:pwd`
   •  `path:/tmp` ,  `path:/repo/src`

Is path:/repo/src a typo? That command would list /tmp/src, right?

[GroovyCarrot]

It's actually not a typo, but because the relative path ./src is used the permission token is generated relative to the repository root, even though it would run in /tmp due to cd the command parsing isn't following the chain, it's just trying to work out paths that may be accessed preemptively based on the passed command string - in this case it generates a token for a directory that doesn't actually get accessed, but the main point is that something happened in /tmp and you were correctly prompted that the agent wants to access that directory for some reason

[DanEble]

Composes conservatively — a command auto-approves only when both its command tokens AND its path tokens are all approved.

If I understand this correctly,

1. Given that I have approved ls src, which independently approved command:ls and path:src.
2. Given that I have approved rm -rf build, which independently approved command:rm -rf and path:build.
3. The command rm -rf src would be approved automatically because both command:rm and path:src were approved.

[GroovyCarrot]

Yes that would be the behaviour. With copilot I never approve rm for the duration of the session, I individually approve all rm commands so I know what it is deleting - especially if it's work in progress. Sometimes claude would say it wants to rewrite a file that isn't yet version controlled from scratch, in which case I'll let it delete it since I've built up trust with that model. With some local models I might approve the delete but be prepared to restore it with my ide, or you could back it up before hand. The main outcome is I'm maintaining oversight and ensuring I don't lose work half way through a task

[DanEble]

Consider this scenario:

• I want my agent to iterate on testing and debugging.
• I have granted permission to edit all files in $REPO/. I have prepared to lose everything in $REPO/ due to LLM idiocy. It would be a minor annoyance.
• I have also approved running $REPO/test/all_units.py because it needs to be run frequently to check the LLM's proposals, and I know that it doesn't touch anything outside the repo. I reviewed it myself, and it's safe.
• The LLM reckons that it should do something stupid outside of $REPO/, it sees that I have previously refused that kind of thing, and since it can both edit and run the test script, it edits and runs the test script to bypass Crush's permission request and write to files outside of $REPO/.

To avoid such trouble, I'm running Crush under Fence, and I expect to continue until a future version of Crush routes script execution through a similar sandbox by default. For protecting files, getting help from the operating system is the way to go, in my opinion.

[GroovyCarrot]

Yes, one of the things I've noticed with these models is they love to write some python or perl or something to achieve a task like a refactor across multiple files. It's a bit annoying because I have to read all that code to see what it is going to do but I'm finding with the changes I've made those snippets are visible and nicely scrollable with the crush permission prompt window so I can give it a one time approval. Ultimately yes if it did go completely rogue it could modify a script and run it to do some damage elsewhere.

There's two sides to it really- the permission system is really just to keep the model on track and, as you say, limit the risk of LLM idiocy. Sandboxing is really the only safe way to contain the damage it can do. I personally prefer to manually approve each command to start with, and keep a close eye on all the changes that are being made as they are happening, and over time I build some trust with the model to grant it a little more autonomous freedom.

The problem with only sandboxing and --yolo for me is that when it gets confused and starts deleting things it's working on, or more often than not it's running some git commands that seems to end up with loss of the working tree, I end up losing all the progress on the task and having to start over; when I'd rather stop it and either tell it what to do instead or just finish it up myself

[jimy-r]

The cross-product problem DanEble found (approve ls src and rm -rf build separately, get rm -rf src for free) is the core argument against composing approvals from command and path tokens at all. Approval records what the user said yes to; safety needs to describe what the action mechanically touches. They're different axes.

The scheme that's held up for me in production agent use is three independent layers:

1. Classify the full parsed action by mechanical impact (read / write-in-workspace / shared-state / destructive-irreversible). The tier decides the gate: auto-allow, allow-with-log, or hard prompt. Impact never composes: rm -rf <anything> is destructive regardless of which tokens were approved before.
2. A deny-list of destructive shapes (rm -rf, git reset --hard, find -delete, force-push) that always prompts, including inside pipelines, subshells, and interpreter wrappers (bash -c, python -c).
3. Protected paths checked last, independent of command approval (secrets, env files, lockfiles).

One operational warning supporting meowgorithm's parsing point: text-level matching false-positives are real (a commit message containing "push" and "main" once tripped our push guard), so parse before matching wherever possible.

I maintain a reference architecture documenting this pattern (impact-tier table + hook layers): https://github.com/jimy-r/agent-workspace-architecture/blob/main/PATTERNS.md#tier-by-mechanical-impact-not-by-tone