Claude Code has added too much of this and it's got me using --dangerously-skip-permissions all the time. Previously it was fine but now it needs to get permission each time to perform finds, do anything if the path contains a \ (which any folder with a space in it does on Windows), do compound git commands (even if they're just read-only). Sometimes it asks for permission to read folders WITHIN the working directory.
My friends and I were talking about the recent supply chain attack which harmlessly installed OpenClaw. We came to the conclusion that this was a warning (from a human) that an agent could easily do the same. Given how soft security is in general, AI "escaping containment" feels inevitable. (The strong form of that hypothesis where it subjugates or eliminates us isn't inevitable, I honestly have no idea, just the weak form where we fail to erect boundaries it cannot bypass. We've basically already failed.)
The settings.json allowlist gives you exactly this kind of granularity. You can permit specific tool patterns like Read, Glob, Grep, Bash(git *) while keeping destructive operations gated. It's not as discoverable as a CLI flag but it's been working well for me for unattended sessions.
Working on something that addresses this and allows you to create reusable sets of permissions for Claude Code (so you can run without --dangerously-skip-permissions and have pre-approved access patterns granted automatically) https://github.com/empathic/clash
I've found Claude Code's built-in sandbox to strike a good balance between safety and autonomy on macOS. I think it's available on Windows via WSL2 (if you're looking for a middle ground between approving everything manually and --dangerously-skip-permissions)
Still waiting for progress from the team trying to get WSL approved for use at our org. We get a "still working through the red tape" update every couple months.
In my case, all of my keys are in AWS Secrets Manager. The temporary AWS access keys that are in environment variables in the Claude terminal session are linked to a role without access to Secrets Manager. My other terminal session has temporary keys to a dev account that has Admin access
The AWS CLI and SDK automatically know to look in those environment variables for credentials.
In my limited time using it, I’ve never seen it ask for permission to read files from within the working directory, what cases have you run into where it does? Was it trying to run a read-only shell command or something?
It will sometimes do this for gitignored files to avoid reading secret tokens in env files for example. But for certain languages that rely on code generation this can be a pain.
It kinda... does? The problem is that folks have been flailing on the right UX for this.
This is what build vs. plan mode _does_ in OpenCode. OpenAI has taken a different approach in Codex, where Plan mode can perform any actions (it just has an extra plan tool), but in OC in plan mode, IIRC write operations are turned off.
The screenshot shows that the experience had just flipped from Plan to Build mode, which is why the system reminder nudged it into acting!
Now... I forget, but OC may well be flipping automatically when you accept a plan, or letting the model flip it or any other kind of absurdity, but... folks are definitely trying to do the approval split in-harness, they're just failing badly at the UX so far.
And I fully believe that Plan vs. Build is a roundly mediocre UX for this.
The switch from plan mode to build is not always clearly defined. On a number of occasions, I've been in plan mode and enter a secondary follow up prompt to modify the plan. However, instead of updating the plan, the follow up text is taken as approval to build and it automatically switches to building.
Ask mode, on the other hand, has always explicitly indicated that I need to switch out of ask mode to perform any actions.
But often I am using Claude to investigate a problem like this “why won’t this mDNS sender work” and it needs a bunch of trial and error steps to find the problem and each subsequent step is a brand new unanticipated command.
The OpenCode plan experience has been pretty bad (the community has accepted this, at least on Discord). The community's adopted a handful of plugins to make the experience better, and also guardrail when the agent switches versus doesn't
Everyone who uses these tools seriously is running it on YOLO mode. It might sound crazy for someone who just started adopting agentic coding but it's how things are done now. Either that or just hand coding.
The SOTA of permission management is just to git restore when AI fucks up, and to roll back docker snapshot when it fucks up big time.
I see nothing wrong with that. If I “fuck up big time” before AI, I would just git restore. There is absolutely nothing on my work computer or personal computer that I couldn’t just throw it in the ocean and within a half a day have everything restored to just like it was - including the data.
Yep, it's easier to ask forgiveness than permission. It's far easier to undo the 1% of the time they fuck up in a serious way than it is to manually audit and allow an the routine stuff.
The key is to only give them access to things you're willing to lose.
This is also why giving them any kind of direct write access to production is a bad idea.
If you arent manually auditing, you only notice the fuck ups when they’re instantaneous
If you don’t trust it to interact with prod, but still trust it to write code that will run on prod… you’re still trusting it with write access to prod.
The only thing I’m willing to let Claude write for me is a static site generator, because static files without JS aren’t going to do any damage, it either loads or it doesn’t.
I was doing something involving API keys and I realized Junie (backed by Sonnet) likes too write helper scripts to try things. And who knows where those scripts look or if they honor .aiignore. Agentic development is a real test of internal access control.
This is one of the interesting things I've noticed. LLMs are good at natural language, and even writing novel code. But If you try to get it to do something that's simple and solidly within the discrete math world, like "sort this list of lines by length" it'll fuck it up like a first time ever programmer, or just fail the task. Like the longest line will be in some random spot not even the middle.
I know, it's not really an appropriate use of the tool, but I'm a lazy programmer and used what I had ready access to. And it took like 5 iterations.
Discrete, concrete things like "stop", or "no" is just like... not in its wheelhouse.
LLMs are sold on the premise of doing cool stuff and reasonably understanding intent and doing it. The man on the Clapham omnibus would not miss-interpret "no" like that.
The LLM asked: "Shall I implement [plan]". The response was "no". The LLM then went on to "interpret" what no referred to and got it wrong.
As you say, it is amusing but people are wiring these things up to bank accounts and all sorts.
I'm looking into using a Qwen3.5 quant to act as a network ... fiddler, for want of a better word but you can be sure I'll be taking rather more care than our errm "hero" (OP).
Is this understanding correct:
The LLM uses harness tools to ask for permission, then interprets the answer and proceeds.
If so, this can't live 100% on the harness. First because you would need the harness to decide when the model should ask for permission or not which is more of an llm-y thing to do. The harness can prevent command executions but wouldn't prevent this case where model goes off and begins reading files, even just going off using tokens and spawning subagents and such, which are not typically prevented by harnesses at all.
Second because for the harness to know the LLM is following the answer it would need to be able to interpret it and the llm actions, which is also an llm-y thing to do. On this one, granted, harness could have explicit yes/no. I like codex's implementation in plan mode where you select from pre-built answers but still can Tab to add notes. But this doesn't guarantee the model will take the explicit No, just like in OP's case.
I agree with your hunch though, there may be ways to make this work at harness level, I only suspect its less trivial than it seems. Would be great to hear people's ideas on this.
Harness needs to intercept all too calls and compare with an authorisation list. The problem is that this is using already granted core permissions.
So you have to have a tighter set of default scopes, which means approving a whole batch of tool calls, at the harness layer not as chat. This is obviously more tedious.
The answer might be another tool that analyses the tool calls and presents a diagram of list of what would be fetched, sent, read and written. But it would get very hard to truly observe what happens when you have a bunch of POST calls.
So maybe it needs a kind of incremental approval, almost like a series of mini-PRs for each change.
Isn't this part of the same problem we have with LLM security in general; that it can only ingest a single stream of tokens, and has no method of privileging "system" tokens over "untrusted" tokens?
If we could solve this (and forgive me if I'm not aware of recent advances that mean we have solved this) then this problem gets easier to solve; permissions live in the system token stream and are privileged. We can then use the LLM to work out what that means in terms of actions.
Do not enforce invariants with an LLM. Do not enforce invariants with an LLM. Do not enforce invariants with an LLM. Do not enforce invariants with an LLM.
True, the "no" button should literally abort the tool use and then return an instruction to tell LMs that the user has aborted the action, but in some way claude code does so; entering "no" would result in tool_abort.
I believe both copilot and gemini have hard-stops for their question prompts. The "no" answer is basically "I will stop and wait for you to tell me what you want".
It does, when any of these actually try to write to a file, it will ask for permissions. The issue is that its so annoying to constantly approve correct code that most people just auto accept everything and review later.
> If the UI asks a yes/no question, the “no” should be enforced as a state transition that blocks write actions, not passed back into the model as more text to interpret.
If the UI asks a yes/no question, the UI is broken.
I want more than just yes/no. I want "Why is this needed?", or "I need to fix the invocation for you.", or "Let's use a different design."
This is the is/ought problem in a nutshell, no amount of compute will reliably solve this problem. Maybe there are some parallels to the halting problem here too.
Claude Code has added too much of this and it's got me using --dangerously-skip-permissions all the time. Previously it was fine but now it needs to get permission each time to perform finds, do anything if the path contains a \ (which any folder with a space in it does on Windows), do compound git commands (even if they're just read-only). Sometimes it asks for permission to read folders WITHIN the working directory.
Claude is secretly conditioning everyone to use —-dangerously-skip-permissions so it can flip a switch one day and start a botnet
My friends and I were talking about the recent supply chain attack which harmlessly installed OpenClaw. We came to the conclusion that this was a warning (from a human) that an agent could easily do the same. Given how soft security is in general, AI "escaping containment" feels inevitable. (The strong form of that hypothesis where it subjugates or eliminates us isn't inevitable, I honestly have no idea, just the weak form where we fail to erect boundaries it cannot bypass. We've basically already failed.)
5 replies →
This is why I wrote yoloAI
My agents always run with —-dangerously-skip-permissions now, but they can no longer do any harm.
https://github.com/kstenerud/yoloai
Claude is able to turn off it's own sandbox, so ya.
Yeah I don't know why they didn't figure to have something in between. I find it completely unusable without the flag.
Even a --permit-reads would help a lot
I have the same experience as you and joegibbs.
I imagine it's really hard to find an adequate in-between that works in general. (Edit: but it also feels like a CYA thing.)
The settings.json allowlist gives you exactly this kind of granularity. You can permit specific tool patterns like Read, Glob, Grep, Bash(git *) while keeping destructive operations gated. It's not as discoverable as a CLI flag but it's been working well for me for unattended sessions.
Mine's started to use $() to feed e.g. strings into a commit. Because this is a command expansion it requires approval every single time.
FWIW, if you enable /sandbox then it stops asking for permission for these kinds of commands.
Yeah, mine to which I find really annoying
1 reply →
Working on something that addresses this and allows you to create reusable sets of permissions for Claude Code (so you can run without --dangerously-skip-permissions and have pre-approved access patterns granted automatically) https://github.com/empathic/clash
I've found Claude Code's built-in sandbox to strike a good balance between safety and autonomy on macOS. I think it's available on Windows via WSL2 (if you're looking for a middle ground between approving everything manually and --dangerously-skip-permissions)
Use yoloAI and you get the full benefit of --dangerously-skip-permissions with none of the risks.
https://github.com/kstenerud/yoloai
Every time I use a bare Claude session (even with /sandbox) without using yoloai, it feels like using a browser without an ad blocker.
Still waiting for progress from the team trying to get WSL approved for use at our org. We get a "still working through the red tape" update every couple months.
6 replies →
To be fair, read-only commands can still read sensitive files and keys, and exfiltrate them via prompt injection.
Not if you don’t have keys on your computer.
In my case, all of my keys are in AWS Secrets Manager. The temporary AWS access keys that are in environment variables in the Claude terminal session are linked to a role without access to Secrets Manager. My other terminal session has temporary keys to a dev account that has Admin access
The AWS CLI and SDK automatically know to look in those environment variables for credentials.
And “find” can easily execute arbitrary subcommands, which may not be readonly.
2 replies →
In my limited time using it, I’ve never seen it ask for permission to read files from within the working directory, what cases have you run into where it does? Was it trying to run a read-only shell command or something?
It will sometimes do this for gitignored files to avoid reading secret tokens in env files for example. But for certain languages that rely on code generation this can be a pain.
It seems to be particularly bad in Windows/WSL
Use Claude Code for Web. Let it live dangerously on their VMs, not yours.
Could be intentional dark UI, to get people to put even more trust in the LLM.
"So they don't want to just let Claude do it? Start asking 10x the confirmations"
Find can be dangerous it has an exec flag
You can relax permissions while avoiding the flag with BashTool sandboxing, see /sandbox.
Maybe if compound commands trigger user approval, don’t do compound commands <facepalm/>
It kinda... does? The problem is that folks have been flailing on the right UX for this.
This is what build vs. plan mode _does_ in OpenCode. OpenAI has taken a different approach in Codex, where Plan mode can perform any actions (it just has an extra plan tool), but in OC in plan mode, IIRC write operations are turned off.
The screenshot shows that the experience had just flipped from Plan to Build mode, which is why the system reminder nudged it into acting!
Now... I forget, but OC may well be flipping automatically when you accept a plan, or letting the model flip it or any other kind of absurdity, but... folks are definitely trying to do the approval split in-harness, they're just failing badly at the UX so far.
And I fully believe that Plan vs. Build is a roundly mediocre UX for this.
The switch from plan mode to build is not always clearly defined. On a number of occasions, I've been in plan mode and enter a secondary follow up prompt to modify the plan. However, instead of updating the plan, the follow up text is taken as approval to build and it automatically switches to building.
Ask mode, on the other hand, has always explicitly indicated that I need to switch out of ask mode to perform any actions.
This is my experience with Cursor CLI.
Does Codex actually have a Plan Mode, or is there a mode switch I'm missing? I find myself having to manually tell it to 'make a plan' every time.
and if it has directory permissions, sometimes it just skips the confirmation step and starts executing as soon as it thinks the plan is ready.
cmd-shift-p (at least in vscode)
2 replies →
This applies well if you’re writing code.
But often I am using Claude to investigate a problem like this “why won’t this mDNS sender work” and it needs a bunch of trial and error steps to find the problem and each subsequent step is a brand new unanticipated command.
The OpenCode plan experience has been pretty bad (the community has accepted this, at least on Discord). The community's adopted a handful of plugins to make the experience better, and also guardrail when the agent switches versus doesn't
Everyone who uses these tools seriously is running it on YOLO mode. It might sound crazy for someone who just started adopting agentic coding but it's how things are done now. Either that or just hand coding.
The SOTA of permission management is just to git restore when AI fucks up, and to roll back docker snapshot when it fucks up big time.
I see nothing wrong with that. If I “fuck up big time” before AI, I would just git restore. There is absolutely nothing on my work computer or personal computer that I couldn’t just throw it in the ocean and within a half a day have everything restored to just like it was - including the data.
I didn't say there is something wrong with it. That's how I use it too.
Yep, it's easier to ask forgiveness than permission. It's far easier to undo the 1% of the time they fuck up in a serious way than it is to manually audit and allow an the routine stuff.
The key is to only give them access to things you're willing to lose.
This is also why giving them any kind of direct write access to production is a bad idea.
Talk about code smell
If you arent manually auditing, you only notice the fuck ups when they’re instantaneous
If you don’t trust it to interact with prod, but still trust it to write code that will run on prod… you’re still trusting it with write access to prod.
The only thing I’m willing to let Claude write for me is a static site generator, because static files without JS aren’t going to do any damage, it either loads or it doesn’t.
6 replies →
I was doing something involving API keys and I realized Junie (backed by Sonnet) likes too write helper scripts to try things. And who knows where those scripts look or if they honor .aiignore. Agentic development is a real test of internal access control.
Your first mistake is thinning that such childish control mechanisms are helping you.
Gondolin go hard or go home
I ran thousands of prompts by now and at most the only issue I had is it deleting code it wrote, which has been easy to recover
This is one of the interesting things I've noticed. LLMs are good at natural language, and even writing novel code. But If you try to get it to do something that's simple and solidly within the discrete math world, like "sort this list of lines by length" it'll fuck it up like a first time ever programmer, or just fail the task. Like the longest line will be in some random spot not even the middle.
I know, it's not really an appropriate use of the tool, but I'm a lazy programmer and used what I had ready access to. And it took like 5 iterations.
Discrete, concrete things like "stop", or "no" is just like... not in its wheelhouse.
LLMs are sold on the premise of doing cool stuff and reasonably understanding intent and doing it. The man on the Clapham omnibus would not miss-interpret "no" like that.
The LLM asked: "Shall I implement [plan]". The response was "no". The LLM then went on to "interpret" what no referred to and got it wrong.
As you say, it is amusing but people are wiring these things up to bank accounts and all sorts.
I'm looking into using a Qwen3.5 quant to act as a network ... fiddler, for want of a better word but you can be sure I'll be taking rather more care than our errm "hero" (OP).
big tech doesn't understand the concept of "consent", this isn't a new thing lol
You have to think about the training data, which has much content far outside the context of pure software.
You have all the real life Harvey Weinsteins and Andrew Tates, and you have all the bodice-ripper fiction, and probably lots of other stuff.
Plenty of real-life precedent for the LLM to decide that "no" doesn't really mean "no."
Is this understanding correct: The LLM uses harness tools to ask for permission, then interprets the answer and proceeds.
If so, this can't live 100% on the harness. First because you would need the harness to decide when the model should ask for permission or not which is more of an llm-y thing to do. The harness can prevent command executions but wouldn't prevent this case where model goes off and begins reading files, even just going off using tokens and spawning subagents and such, which are not typically prevented by harnesses at all.
Second because for the harness to know the LLM is following the answer it would need to be able to interpret it and the llm actions, which is also an llm-y thing to do. On this one, granted, harness could have explicit yes/no. I like codex's implementation in plan mode where you select from pre-built answers but still can Tab to add notes. But this doesn't guarantee the model will take the explicit No, just like in OP's case.
I agree with your hunch though, there may be ways to make this work at harness level, I only suspect its less trivial than it seems. Would be great to hear people's ideas on this.
Harness needs to intercept all too calls and compare with an authorisation list. The problem is that this is using already granted core permissions.
So you have to have a tighter set of default scopes, which means approving a whole batch of tool calls, at the harness layer not as chat. This is obviously more tedious.
The answer might be another tool that analyses the tool calls and presents a diagram of list of what would be fetched, sent, read and written. But it would get very hard to truly observe what happens when you have a bunch of POST calls.
So maybe it needs a kind of incremental approval, almost like a series of mini-PRs for each change.
Isn't this part of the same problem we have with LLM security in general; that it can only ingest a single stream of tokens, and has no method of privileging "system" tokens over "untrusted" tokens?
If we could solve this (and forgive me if I'm not aware of recent advances that mean we have solved this) then this problem gets easier to solve; permissions live in the system token stream and are privileged. We can then use the LLM to work out what that means in terms of actions.
Do not enforce invariants with an LLM. Do not enforce invariants with an LLM. Do not enforce invariants with an LLM. Do not enforce invariants with an LLM.
Thou shalt not make repetitive generic music,
thou shalt not make repetitive generic music,
thou shalt not make repetitive generic music,
thou shalt not make repetitive generic music.
Thou shalt not pimp my ride.
Thou shalt not scream if you wanna go faster.
Thou shalt not move to the sound of the wickedness.
Thou shalt not make some noise for Detroit.
When I say "Hey" thou shalt not say "Ho".
When I say "Hip" thou shalt not say "Hop".
When I say, he say, she say, we say, make some noise - kill me.
- Dan le Sac vs Scroobius Pip
I have no idea how this ended up here, but after giving it a listen, thank you for the chuckle. I wouldn’t have come across it otherwise.
1 reply →
True, the "no" button should literally abort the tool use and then return an instruction to tell LMs that the user has aborted the action, but in some way claude code does so; entering "no" would result in tool_abort.
I believe both copilot and gemini have hard-stops for their question prompts. The "no" answer is basically "I will stop and wait for you to tell me what you want".
It does, when any of these actually try to write to a file, it will ask for permissions. The issue is that its so annoying to constantly approve correct code that most people just auto accept everything and review later.
> If the UI asks a yes/no question, the “no” should be enforced as a state transition that blocks write actions, not passed back into the model as more text to interpret.
If the UI asks a yes/no question, the UI is broken.
I want more than just yes/no. I want "Why is this needed?", or "I need to fix the invocation for you.", or "Let's use a different design."
Theres shortcuts to undo btw.
Can’t believe we got AGI before we figured out reproducible builds, building software in a mutable environment just baffles me
This is the is/ought problem in a nutshell, no amount of compute will reliably solve this problem. Maybe there are some parallels to the halting problem here too.