Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Auto mode is now the default in Claude Code

claude.com

Post reply on HN
Print view View original

261–270 of 337 posts

Re: Auto mode is now the default in Claude Code

#261

Post by fluidcruft »

awkii wrote: post #52

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 sa…

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.

Re: Auto mode is now the default in Claude Code

#262

Post by ryanbrunner »

Retr0id wrote: post #250
wongarsu wrote: post #232

Earlier quoted context omitted.

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…

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…

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.

Re: Auto mode is now the default in Claude Code

#263

Post by stefan_ »

oefrha wrote: post #157

Ever since Opus 4.7, the model has been tuned to emit such complex commands that not only a human can’t reasonably review them in reasonable time, even a fairly sophisticated command approval framework I built over time that broke down shell commands/scripts into separately approvable/whitelistable units—with its own mini DSL—got completely lost; it worked great up to Opus 4.6. So not surprisingly, auto mode is the o…

It's really getting extremely obnoxious. There is no point to the whole "shell commands output" view anymore because the model aggressively redirects everything to some scratchpad file, so besides the output viewer being a broken mess, it doesn't show anything regardless.

My favorite is when it wraps commands in convoluted pgrep wait patterns that end up matching it's own bullshit, and thus never exit. It also feels like Opus 5 will now always write some adhoc Python script to MAKE UPDATES TO FILES, which seems extremely terrible.

The complicated shell commands also constantly trip up against quoting rules, requiring another iteration.

Re: Auto mode is now the default in Claude Code

#264

Post by fluidcruft »

Joeri wrote: post #251
krzyk wrote: post #61

Earlier quoted context omitted.

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.

Re: Auto mode is now the default in Claude Code

#265

Post by ben_w »

vehemenz wrote: post #259
ben_w wrote: post #212

Earlier quoted context omitted.

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.

Re: Auto mode is now the default in Claude Code

#266

Post by e1g »

shelled wrote: post #186
awkii wrote: post #52

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 sa…

What is an easy way to achieve this on a Mac? tl;dr : if I run claude/harness inside "code" at "~/ /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 "~/ /code" . Even if I want…

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

Re: Auto mode is now the default in Claude Code

#267

Post by TZubiri »

dgunay wrote: post #155

Besides the debate about whether this is "safer" than manual human review, I have a slightly different problem. Very often, when I'm running Claude in manual review mode, it will attempt to do things which are not "dangerous" but are misaligned with what I want it to do. Maybe I'm fighting the model here but for example, when orchestrating other agents to do work, Claude really badly wants to be overly prescriptive a…

Control is not only about security, you don't review the work of your employees just because you want to avoid them stealing from the register, you want to perform QA on their tasks and ensure they are aligned.

Re: Auto mode is now the default in Claude Code

#268

Post by TZubiri »

natpalmer1776 wrote: post #91
mcmcmc wrote: post #36

Earlier quoted context omitted.

> it's someone who's more "code-naive" and might get anxious about approving random bash script commands they don't recognize. Maybe they should trust their instinct and not mess with things they don’t care to understand

It’s a brave new world. I recall hearing similar sentiments from linux sysadmins regarding cloud infrastructure. In many respects they were and continue to be correct. In other respects, the world doesn’t care about the loss in understanding as long as things work “well enough” for the cogs of society to keep turning. For those who do care (and have the aptitude) to understand things deeper there is always work to be…

> In many respects they were and continue to be correct

Lots of space for on-prem, it's not a cloud only world. See Oxide, Europe sovereignity, military and state use cases..

Re: Auto mode is now the default in Claude Code

#269

Post by tremon »

fluidcruft wrote: post #264
Joeri wrote: post #251

Earlier quoted context omitted.

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.

Re: Auto mode is now the default in Claude Code

#270

Post by moralestapia »

awkii wrote: post #52

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 sa…

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

Post reply on HN