Hacker News Reader

Comment by awkii | Hacker News Reader

I'm apparently from the very small faction of users who's been running `--dangerously-skip-permissions` in every instance of Claude for the last year. It's almost a reflex to me. For the most part Claude behaves well, but I don't blindly trust it. LLMs are inherently dangerous tools, and reviewing individual commands (or spamming `y`) doesn't make them less so. Safety is the responsibility of the developer putting sane guardrails (like VCS, immutable filesystems, or read-only tokens). Using more Claude to categorize the safety of Claude commands is not the answer.

View on HN

I manually approve everything (aside from the "allow commands like this" option). Not because I'm worried it's about to do something harmful but because I want to stop it from wasting tokens doing something stupid like implementing a feature I never asked ask for. I'm not even reading the commands, just checking it's going in vaguely the right direction.

I think my ideal setup would not involve approving commands, but approving summaries of proposed actions (whether they involve code exec or file edits). Kinda like plan mode but perpetual. Like most things, trying to solve it via CLAUDE.md is an exercise in futility.

I run in manual mode not out of rogue agent or token waste concern but because I want to effectively pair program with the agent. I need to understand what is happening along with the how and why. I’m confident I’m slower than YOLO people but that’s a trade off I’m consciously making so I can stay in the loop to comprehend the codebase.

Your summary approval idea is interesting and feels maybe like a mini plan mode. My biggest frustration with the existing manual approval system is when Claude is exploring it gets tedious to approve each command. Being able to approve a block of commands or a mini plan AND have auto mode audit them for safety would probably be something I would consider for the expiration phase of my Claude use.

I spent part of last week, and the weekend, in Claude (Fable) on a documentation project... maybe a waste to use Fable, but been a little obsessed with trying to get the technical details right. I know, from personal history, more than some of the available info easily found on the subject. I let a lot of it just go, and swing for the fences, but in the end, did hand review all the output at each stem.

In my specific case, implementing modern documentation for Remote Imaging Protocol (and old graphics protocol for terminal/bbs usage), and in particular trying to gather what exists of the later version released. The company itself folded, and there wasn't a lot of broad use of the later versions, and only partial information was ever released as a documentation. Claude was able to interrogate the apps, and some available open source, in progress work, and establish a lot of things.

I've still got to direct some edits... I guided a re-flow of the order the documentation was written in, particularly to be consistent between the versions... but it obsessively added verbose summaries to every page/file. All markdown, meant to build a website from, and eventually some compatibility tests, guidelines and a green/open implementation.

https://github.com/bbs-land/remote-imaging-protocol

This morning I've turned auto mode back on, I'm only using it during Claude's exploration phases of my workflow and then I'm reading the full transcript (which includes some thinking info). So far, this seems to be quite close to what I want, and an improvement over my previous "manual all the time" mode.

Still leaving manual approval for all edits. Combined with reading the full transcript of the exploration, I feel I stay in the loop pretty well in this first test.

You can get some approximation of that with more detailed plans. I use a prompt like "Let's make a detailed plan. Write plan files as markdown to plans/feature-XYZ. [regular prompt]". That way you get much more thorough plans than with plan mode, and you can make it as detailed and deep as you want.

It can't account for things that only come up during implementation. But you can explore much more of the design space in planning to reduce the opportunities for Claude to wander down the wrong path during implementation

I've tried this, and it is largely what I do, but it's easy to end up with a large tangled pile of markdown files, and the implementation either diverges from what's in markdown or you burn a lot of tokens keeping them in-sync.

The plans usually end up very long and verbose, and in my most vibe-y test project I stopped even reading them myself and instead just ask questions interactively. e.g. "what are the remaining unanswered design decisions", "which part is jankiest". It does work quite well although I don't know how I feel about it.

P.S. to any anthropic staff: The "chat about this" option in Plan mode is useful but also annoying. When I select it I want to take the next turn of the conversation myself, I don't want it to waste time "thinking" just for it to verbosely ask me what I want to chat about.

I don't think there's any functional difference between "chat about this" and just directly entering what you'd like to do / ask about in the "Tell Claude what to do" option, I think that's pretty much exactly what you're looking for.

That's close to my workflow as well... keeping planned areas in TODO.md, done changes in DONE.md, and a non-committed WORKING.md for the current work being done, as well as coordination with sub-agents, so I can view/monitor... have to direct the latter each time to have it done that way.

Imho, the combination of the mattpocock skills, and the beads local issue tracker take care of all of that very well, with generally high quality output.

That's a good take. If LLMs are supposed to replace programmers, then they need to be programmers. Executing random things in all directions hoping for a break is something novices do. A good teammate knows when to ask, what to ask, how to ask, and who to ask.

Tough call. On one hand, CC keeps asking me about the permissions; it shouldn't. On the other hand, I would rather not unleash it.

Currently, I'm running an internal experiment.

1. I have a side project. 2. I want to give the full control; CC is the so-called CEO, and I'm the so-called president of the board.

The cost of an error is marginal. I would like to see how this will end. The test is in progress.

> Not because I'm worried it's about to do something harmful but because I want to stop it from wasting tokens doing something stupid like implementing a feature I never asked ask for

... plan mode?

I'm also in yolo mode, this is the only mode that makes sense for me, if I need to babysit I might as well do it myself.

I run it in a VM so it can install any software needed, yes, there is a risk of escaping, but I'm not giving it impossible tasks so there is no need for it to workaround the jail.

For running it in yolo mode I set it up in a devcontainer. It takes a bit of figuring out, but once set up the permission prompts go away and claude has no access to anything I haven’t explicitly added to the devcontainer (unless it hacks its way out).

I tried to figure out devcontainers (I don't use vscode) but it seemed like a lot of complexity and ended up just doing the old-school thing and creating a separate user/group that I ssh into with my main account as a member of that user's group so that I can browse and edit/add files.

Just for reference, here's my local "devcontainer" script:

  exec podman container run --rm --read-only --network=llm \
    --tmpfs=/tmp:size=128M \
    --volume="$1":/workspace \
    --entrypoint=/insert/agent/here \
    container-image-here

This runs the specified agent in a read-only container with only /workspace and /tmp writable. Obviously, you need to prepare the image first from a Containerfile/Dockerfile, with the required toolchain and agent installed. I use agent-specific ssh keys that are baked into the image, but you could also bind-mount specific files from your own homedir if required.

I catch it doing stupid things regularly still.

This morning I asked Sonnet to make an update to my Claude live statusbar.

Rather than look up its own API, it started reverse engineering the CC binary looking for strings relevant to what I wanted.

No matter how "contained" it is, I always start in manual mode and flip to auto once I'm confident it's on the right track.

What VM do you run it in?

as context, I build a light weight portable vm designed for this purpose, so genuinely curious.

I'm using a container. The risk isn't exactly "agent leverages 0-day against you to steal all your data" but more "agent mistakenly though $HOME was theirs and deleted it" so as long as you "copy data in > copy data out" without bind-mounting or automatically sync files, container works just fine for "isolating" them.

I've tried both incus and firecracker. Both seem to work well after initial script setup. I've got the impression that firecracker should be a fairly safe option for such use cases.

Given that people use VMs to sandbox agents of Mac/Windows/Linux, what does portable mean?

i have a mechanism to package a VM into a .smolmachine file that you can rehydrate into a prepared vm akin to a container image.

I've been running it in yolo mode straight on my laptop for the whole year. It's fine.

Isn't that what the people crying over their deleted or leaked data were doing too?

"I've been playing Russian roulette with a 1024 chamber gun for a year now, it's fine"

Every driver thinks of themselves they are an excellent ones. Statistics has another data :)

If LLM agent wants to get out of dedicated folder where it’s supposed to work and tries to run a command, ppl should be always cautious. In fact, it is a sort of # access on live data.

Sudo/# is nice as you don’t have to ask for permissions, but I would recommend to do it only when you are fresh, fed, and not under stress.

I remember few times that I “accidentally” deleted or changed stuff I wanted to have intact… (Somebody would say that it is a skill issue :) But it was always when I was in hurry.

> Every driver thinks of themselves they are an excellent ones. Statistics has another data :)

I think I'm an excellent driver, and I have data that backs that up, like I've never been in an accident but avoided plenty. What statistics show that I'm actually a terrible or even average driver?

> I remember few times that I “accidentally” deleted or changed stuff I wanted to have intact… (Somebody would say that it is a skill issue :) But it was always when I was in hurry.

Gives me flashbacks to when the company I worked for had some issue in production, we were 3-4 people huddled around a laptop trying to figure out what was going wrong. Viewing the logs on the host itself was too slow or not possible somehow, can't remember the details, but we were able to start transfers of the logs out of the host. Only problem was that the log file was GBs long (what is log rotation?) so would have been too slow. Easy, just compress the log file, then send that, should be a lot smaller. Obviously we were all in a rush but still wanna be careful, so I enter the command for compressing the only log file we have, ask for someone to check, other person says "looks good to me", I hit enter and we get an error that it couldn't find the file we were trying to compress, the created archive been created without any entries added to it. The log directory is now completely empty, except one tiny "errors.log" zip/tar-file that had been created when we accidentally used the wrong order of the arguments in our command to create the compressed archive. I think we had to recreate the host at this point, reproduce the issue then get the logs again, probably slowing down recovery +30 min at least.

>I think I'm an excellent driver, and I have data that backs that up, like I've never been in an accident but avoided plenty. What statistics show that I'm actually a terrible or even average driver?

The statistics showing that past performance doesn't guarantee feature results, that a lot of the accident avoiding could be just having luck while still driving badly, and that a lot of drivers overestimate their skills.

on a similar note... what statistics show the accident rate of each model of car? or rather, a single driver's accident rate in various types of cars?

I'm assuming this happens to the people vibe coding and running 30+ agents in parallel that are "coordinating" each other. I've never seen Claude do or even suggest anything remotely dangerous when I'm just giving it incremental tasks and reviewing the output.

>I've never seen Claude do or even suggest anything remotely dangerous when I'm just giving it incremental tasks and reviewing the output.

"I've never had a bullet hit me yet"

I don't use yolo mode but if you allow your agents to both write code and run/test it, then it's basically equivalent to running in yolo mode anyway.

The other day I caught Claude including a rm -rf equivalent (fs.rmdir({ recursive: true, force: true })) in my code, to clean up temporary directories. It was fine, but that kind of code is only one misconfigured environment variable away from blasting away your $HOME.

I've set up a second user on my machine just for running AI. That way I have the additional layer of OS protections against it doing something like that.

>if you allow your agents to both write code and run/test it, then it's basically equivalent to running in yolo mode anyway.

I don't. I manually check the code line by line before. And also run them in container anyway.

I run in auto permission mode and it will run with 1 task and end to completion. On the rare event it needs to rmdir or rm -r a dir, the permission mode will stop the agent. Sometimes annoyingly... so its more like. "I've never had a bullet hit me yet inside a office building on the 42nd floor".

Whatever level of safety you are at, it's always easy to advocate for more. It's always a trade-off and in the end a matter of preference and risk-tolerance.

> Isn't that what the people crying over their deleted or leaked data were doing too?

Probably using not-SOTA models, or on the lower reasoning levels, they tend to be a bit more tally-ho when it comes to destructive operations, especially in longer tasks as the agent gets worse and worse as the context grows. Suddenly running some stupid command seems like the right way to go, and then $HOME is gone.

If the director of alignment at Meta Superintelligence Labs gets it wrong, what hope does anyone else have?

You mean the guy hired by the Metaverse guy?

> guy

Summer Yue, she.

> Metaverse

Zuckerberg may indeed be hiring people who are less than the best, same for Musk, but the people they hire are making the UX that the rest of us have to put up with.

Given I keep reading claims about heavy agentic coding use at Anthropic, and given what I experience while using ChatGPT, those companies are vibing the UX that the rest of us have to put up with.

VMs and containers are primarily useful to reduce maintenance burden anyway. I.e. if it fails or you're otherwise done with it, you can torch the container instead of having to clean up your host system from zillion no longer relevant packages and configs.

To be honest I do this too. Nag mode is kind of a pita.

I think all of Anthropic's own staff use --dangerously else they'd work on the usability of the massively imperfect 1-approve-once and 2-approve-forever multi-choice and outcome.

That's exactly why Auto mode was made, and reportedly what they all use. It's the easy option, with a better safety score than human review.

(This isn't vibes: they're red-teaming Auto mode heavily)

> It's the easy option, with a better safety score than human review.

Considering I went through a phase before I started using Claude Code where I'd eventually reach a point where I'd mindlessly approve ridiculously long command chains, I believe this.

As the article writes: "many users are clicking through reflexively rather than reviewing each command".

It's far better (for my working style, anyway) to have some external isolation/sandboxing, but leave the actual command approval to LLM.

>with a better safety score than human review.

According to them - for things they care about.

>else they'd work on the usability of the massively imperfect 1-approve-once and 2-approve-forever multi-choice and outcome.

Their profit motive is in NOT improving that, and luring you to depend all the more automatically to Claude.

Maybe by design?

1. Metrics show auto or YOLO mode users have higher retention

2. Company intentionally doesn’t invest in manual mode

I too skip all permissions, but I run the harnesses inside an isolated virtual machine. I took care to firejail Claude Code on my host since day one, and coding my own QEMU VM orchestration solution was among the first things I used it for.

Alarm fatigue will quickly destroy any and all "meticulously approve every little command the AI wants to run" workflows. Give it a virtual machine and let it cook. If it blows up the virtual machine while it works, it doesn't matter.

I setup an alias in my shell for --dangerously-skip-permissions after about a week of the constant y, y, y a year ago. I felt like Homer Simpson running the nuke plant and couldn't take it anymore. So far it's only deleted some files I likely would have said NO to, but in reality would have just hit y anyway. They were recoverable so no harm.

I do it, and run claude as a separate unix User.

This is the only kind of agent security that makes sense to me. Constrain it like you would any other subprocess. Unprivileged OS users, SELinux, firewalls, VMs... Unikernels? eBPF?

Escalations to root are a dime the bucket.

Then either fix them or put it in a stronger kind of sandbox. Or what would you propose? Anything that doesn't constrain arbitrary processes is weak against and AI just writing a program to do the thing that it itself its prevented from doing.

That argument is letting the perfect be the enemy of the good.

There is no perfect security.

Me too.

My .bashrc has `alias claude='claude --dangerously-skip-permissions'`

Been using it like that everyday for about a year now and nothing bad has happened. I got backups and if it would fuck things up, it can probably fix it again as well.

> and nothing bad has happened

This is the same reasoning for not wearing seat belts or a helmet on a motorcycle. Nothing bad has happened yet so obviously there is no need for any protection.

I've been raw dogging Claude Code for the better part of last year as well, but I'm under no illusion that it's safe to do so, I just cannot approve seven trillion approval prompts and stay sane. I've since. switched to auto mode, however.

You can also put it in ~/.claude/settings.json:

   "permissions": {
    "defaultMode": "bypassPermissions"
   },

It's a bit annoying you can't set default mode to plan while keeping bypass permissions enabled though

>nothing bad has happened That you're aware of.

Famous last words

We're all going to die one day

I haven't (and won't) gone that far, but what's been working for me is denying all arbitrary code execution, grep, glob etc, and then allowing the JetBrains MCP. At least that way it's essentially locked down to the IDE project.

Then you can treat most asks as a signal something has gone wrong. For the most part it seems to work well within that box.

How can you simultaneously `--dangerously-skip-permissions` but also "don't blindly trust it"? Particularly now that it doesn't even show you the "Thinking" process?

Do you just get a feeling it might be doing something wrong and stop it?

Edit: *deafening silence*, a classic

I use dontAsk mode[0] with read access to the entire file system, write access to files from the working directory[1], some git commands (git commit yes, git push no), and a script wrapping Deno with the same read/write permissions (safer substitute for `python -c`).

These are usually enough for most of my coding tasks. In my experience, Claude has been good enough that it can write code and fix bugs without needing anything else. It's far better than ever needing to approve permission requests.

[0]: https://code.claude.com/docs/en/permission-modes#available-m...

[1]: Note that this includes escaping the directory via symlinks

I do the same. I also use crush/deepseek a lot. I patched crush to remove all safetyguards and enable yolo mode by default. I use it on a daily basis including devops. For example to configure netapp storage systems and had not a single incident. Of course I also have backups of my systems and have everything under revision control. Depending on the task I let it run on a throw away VM, production system, lab system. Depending on the task I give it access to throwaway credentials (that I rotate afterwards) or my ssh agent socket.

You can just use hooks to physically (so to speak) prevent it from running the most sensitive commands. I find that peace of mind enough for me. E.G. no deletes, no deploying to <env>, etc etc

Everything else you can sort of review what it did after the fact and/or tolerate mistakes, but knowing some thing’s are impossible for it to do us good peace of mind

Otherwise not sure who’d be willing to tediously on every single action on anything but the most important of projects, of which I can’t really think of any of that clear that bar for me

I do it, but in a devcontainer...but the devcontainer is as much to keep my host free of the random tools that a given project needs as it is (now) to keep Claude in line. If I had to click approve on everything it'd be worse than doing everything myself.

I used to use dangerously-skip-permissions until auto appeared and I gave it a try and honestly I don't know there's much of a difference? If auto had existed in the past I would never have needed to try dangerously-skip-permissions.

My issue is that the auto mode guard rail model, is sometimes overwhelmed and really slow, so I also mostly just default to --dangerously-skip-permissions. I wish the command would be easier to write like --dsp

For personal stuff I have a separate physical machine on the network that Claude runs on in yolo mode and the worst it can do over there is wipe the machine. It doesn't have privileged access to anything else unless it starts trying to hack my network, which I suppose is theoretically possible with prompt injection attacks.

For work stuff in the work environment I don't risk it.

> I wish the command would be easier to write like --dsp

It amazes me they didn't make the short version --yolo ... but I would imagine the merit of the long name is that you can't claim you weren't warned!

You can set it in the config file so it's the default every time.

Create an alias

i've never seen the point of manually approving myself but it depends on the scope of work you ask of it. it wont suddenly rm -rf / if that has nothing to do with anything in the project. if you let it manage env or user cfg stuff in ~/. or so that might get hairy etc.

ofc, jails on bsd, containers , vms git backups and such techniques are a blessing, most risk is in the filesystem items being deleted . it wont suddenly hallucinate a kernel exploit or something extreme.

You can also set plan mode as default and start Claude with —allow-dangerously-skip-permissions.

Then you can spent time refining the plan, then shift tab to bypass permissions mode.

Yeah who cares what it does, everything is backed up, everything can be rolled back. I always run it with the keys to the kingdom.

Yeah, if you don't care if your ssh keys or data are potentially posted all over the internet, more power to you...

Not to mention cases like some comment here:

"I've caught Fable discovering the ip to a production server in documentation and attempting to connect there on its own to run commands without explicitly being prompted to. It didn't work because I was watching it live and and also the key was password protected, but yeah, I do see some danger."

How are ssh keys going to be leaked, the agent never needs to read them.

The agent decides what it "needs" to read - not the intention behind the prompt you gave it.

A failed SSH connection to a staging server for example, can trivially make it look into .ssh to try to diagnose it. And many other ways, including prompt injection.

https://www.reddit.com/r/ClaudeAI/comments/1q7dszm/claude_al...

https://github.com/anthropics/claude-code/issues/31566

https://github.com/anthropics/claude-code/issues/14485

https://grith.ai/blog/your-ai-agent-has-broad-access

The solution I've come up with is podman containers. You can restrict the filesystem and only give it access to dev tools. I don't even allow git, as I review and commit everything on the host. It's not perfect because podman containers can be leaked out of, but it's much better than running it on the host. It also allows me to avoid installing node or npm on the host.

If you were to get pwned by Claude, I would think the method would be Claude rogue installing a compromised npm package.

Same, but I always run within dev-containers. I joke I trust my LLM with the same energy I trust juniors?

Why not both? Having auto mode, plus having good guardrails is the way forward.

What is an easy way to achieve this on a Mac?

tl;dr: if I run claude/harness inside "code" at "~/<some path>/work/code", it would be great if the harness can't even see "code" is inside "work" (and even I can't make it know that by some quick "Yes(y)")

I want something like: claude/opencode/pi/etc has no existence or capacity outside a file access boundary, say a given folder that (e.g.) lies here "~/<some path>/code". Even if I want, I can't run claude outside it, because it isn't installed outside it. Even if Claude wants it can't read/write/execute/install anything outside it.

Basically I want the harness(es) and my code folder(s) sandboxed [0] inside just one folder and below it in folder hierarchy at least for file access limitations.

Will this pose the challenge of using the system wide cli tools like ls, cd, git et cetera? If it gets a handle on those tools outside that sandboxed folder then pretty much can it execute it in any other folder? So should those tools also be part of that container?

I guess something like docker does that, but do I necessarily need a docker like app/tool? It will use a lot of system resources on its own. A different mac login won't be great either.

I do not want to use claude's /sandbox (or something like this), that will defeat the purpose. Because it's not about "it won't", but because "it can't".

https://github.com/apple/containerization doesn't sound like what I am looking for. So is docker, lima etc are my only options? Not to mention I will lose access to a lot of cli tools I use on mac.

I use bubblewrap, which I believe claude code also has internally but not for its `Bash()` tool.

I wrap bubblewrap in a script that supports config files to allow different "profiles" of use (analogous to eg firefox profiles). The bwrap starts with the whole filesystem mounted read-only, then mounts the current directory read-write and then applies further bind mounts for devices, special case other read-write (eg, ~/.cache/) and to mount empties to cover sensitive directories (eg, ~/.ssh/). The profile also specifies the default command to run and for claude, it gets yolo mode.

On a Mac, you can do this via OS-native Seatbelt sandboxing - you define a static text file and it locks down the process so it can't read/write anything it's not supposed to. The syntax is a bit archaic, so I built a Bash wrapper around it to dynamically detect which agent you use and from what dir, and then generate the policy to lock down its process - https://github.com/eugene1g/agent-safehouse

Hey, thank you. Looks like a tool easy enough to use and start with the agentic world in a sandboxed and much safer manner.

Just clarifying a bit (haven't gone through details yet):

1. So, a harness gets installed within the bounds of this script via agent-safehouse? (I doubt this is the case)

2. Or they are installed as a normal app, but when I run them in the terminal within the bounds of "safehouse <harness>" (saw this) they are bound by the rules I set, right?

I feel it's the latter and I think it's good enough for the time being.

.....

Mac offers some controls at least for personal files and "Full Disk Access" etc. But it's so badly implemented and poorly shown that it's confusing.

Like I can see in "Privacy & Security > Full Disk Access" OpenCode is listed and and "Full Disk Access" toggled off. (I anyway remove OpenCode from here completely by the "-" button after selecting it, just to make sure).

Then I go back a step and in "Privacy & Security > Files & Folders > OpenCode" has "Full Disk Access" is listed there. Strange!

“safehouse <harness>” hides and protects your filesystem from the agent CLI - it cannot read/write/delete anything outside of the current folder, no matter what Bash/code it tries (short of finding some 0-day within MacOS sandboxing). We added exceptions for dev tooling (so eg NPM works), but generally keep same defaults (eg no Docker access by default as having that socket bypasses all protection)

I do the same and truly think others are just control freaks that enjoy restricting agents (human or AI) from being productive and also enjoy keeping their worthless selves in the loop for a false sense continued relevancy.

Yup. I just made this mode default via settings.

LLMs are inherently dangerous tools

I don't see how. An LLM just generates a stream of output and they became very useful doing no more than that.

What is dangerous is then interpreting that output as instructions to some other part of a system that has the ability to do damage if misused.

and reviewing individual commands (or spamming `y`) doesn't make them less so.

Surely if you review each instruction in the output and do not allow the other part of the system to act on one if it would be harmful then this arrangement is very much less dangerous?

I've caught Fable discovering the ip to a production server in documentation and attempting to connect there on its own to run commands without explicitly being prompted to. It didn't work because I was watching it live and and also the key was password protected, but yeah, I do see some danger.

I have noticed that Fable tends to macgyver solutions together to achieve some goal.

Not only fable. Opus does this too. Which is exactly why I want to review. Like recently for some task it was convinced in a site dump images are not there and convinced itself db and files were skewed. But it didn’t check the actual site … if I hadn’t stopped it, it would have fine on and on or wasted tokens on some elaborate ‘fix’.

My point is that an LLM can't attempt to connect to anything by itself. All an LLM does is produce a stream of output tokens - and that was already quite useful as a coding aid.

It is the harnesses that some people are now wrapping around LLMs to interpret the output from a model as commands to run (or other executable instructions) that are creating all these new risks. Remember that this is still a very recent development and still more recently amplified by the use of feedback loops and long-running agents intended to operate with minimal human supervision.

It is going to be increasingly important to understand exactly what these tools are doing and why for both correctness and security reasons. Not conflating their capabilities with the underlying model that purely generates data is pretty fundamental here.

Once you're running a model inside the harness... you've got yourself a controller inside a control loop, which is genuinely a different kind of thing than just the model alone.

Are you objecting to terminology here?

Are you proposing we say "Fable-In-Claude-Code tried..." instead?

Hmmm... something like that might be necessary. Sure we should typically be tolerant of loose language; but people do keep referring to wildly different contexts in ai conversations, and end up talking past each other.

Running gemini on web is a genuinely different experience to running Fable in claude code, different again from GPT-5.6 in openclaw, or in an ide or etc ...

Yes - I'm objecting to the lazy use of terminology here. LLMs are useful in their own right and are not the real problem here. The real problem is people placing too much trust in inherently unreliable output and then trying to automate away their responsibility to check that output properly before using it.

Depending on the company, that sounds like a bad environment more than a agent issue, no dev/prod network isolation?

> do not allow the other part of the system to act on one if it would be harmful

Network security is really easy right, just don't act on harmful requests

Yeah, just drop when you see the RFC3514 evil bit

If you don't understand clearly what an action proposed by your tool is going to do then why would you permit it?

The article is about measurements taken on this.

One important reason is due to Permission Fatigue: Of course you check everything! You're diligent! The last 100 requests were all ok, so you're down to hitting yes, yes, yes, yes, yes, yes, yes, yes ...

... oops, that third yes should have been a no!

This seems like a problem with the level of abstraction the user interface is working at. It is highly unlikely that in any real world task lasting less than one day there were really hundreds of distinct decisions that needed to be made by the user about appropriate actions to be taken by the agent/harness. It is also highly unlikely that the problem of decision fatigue seen here is somehow magically different to the same problem that countless UI designers had encountered and designed around in other systems long before harnesses running LLMs came along.

This is unfortunately the kind of result you get when you eliminate skilled and experienced people with real understanding of their field and replace them with repeated automatically-generated attempts to solve the same problem until something meeting some basic standard of correctness is found. It's as if the story of agentic AI as it exists today had been compressed into one perfect example of what it can do that is good but also why it's still fundamentally flawed.

I think we agree that there's an interface problem. But there's an intelligence-complete problem hiding underneath; which is why the first instinct was to recruit the human-in-the-loop in the first place. Turns out the human has one of those unintuitive failure modes that occurs when the system gets past a certain level of reliability.

Meanwhile, let's leave the hobby-horses in the closet for now. I won't comment on people's programming tool preferences.

Reply on news.ycombinator.com