Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • I had an “interesting” experience recently in auto mode.

    I was recreating an old travel blog and we wanted to back up the photos to glacier.

    Claude asked me to creat an AWS profile with limited permissions so I could run a script it had created.

    I did it and told Claude it was ready.

    It took that to mean it should run the script.

    It failed as I’d messed up one of the permissions.

    “Don’t worry - I’ve found another configured AWS profile - it’s got admin permissions! I’ll just use that…”

    Completely my fault for having that old profile still available. But also…

    by iamflimflam1
  • I've recently been running yolo mode, but in docker container with the codebase I'm working on a as regular mount with other reference code mounted as read only.

    I've been experimenting with dedicated Linux users for various external tools with access to the relevant credentials limited to them and the Claude user only able to invoke the relevant clis by going through a pair of wrapper scripts: the first to change user to call the second via a su call as the appropriate user, the second wrapper to invoke a guard script which allows me to implement my own in-code permissions checks against the cli arguments. In _theory_ there's no way for Claude to work around it, as the sudoers file only permits the described manner to change to the user with credentials, and the user with permissions for each credential only ever runs deterministic code.

    It's too early days to say how well this second part works out, but so far so good.

    by foo42
  • It goes off the rails too quick too often right now for this. Sure, you got something easy in 5 files? You are building throwaway prototypes or proof of concept? Go for it. You have a real project you expect to maintain and work with others on? Well, say goodby to any actual architectural design. It is hard keeping these things building scalable maintainable code right now. It is like letting a junior dev come up with architecture. It may sort of work, but watch as any maintenance/updates happen. You get a different implementation of security for every endpoint in your app, 15 copies of code with no reuse, dead code laying everywhere and no real idea of how to untangle it. It is hard to keep this stuff under control when you are paying attn. Turning auto on makes that even harder.
    by jmward01
  • True its is like a junior dev with brain damage and insane ego (especially Fable who thinks its a rockstar programmer for some reason), but you have to use plans, anything else turns into a turd way to quickly. Write a summary of what you want to happen, have it plan it (this is where the architecture decision gets made) then iterate on that plan until its detailed enough and the design is sound. Let it work in auto mode on the plan then review the changes. This only really works if you have a good mental model of the codebase.

    Its still a lot of work, just less than having to code literally everything yourself. I agree though it feels to me 99% of discussions on LLMs is either marketing bullshit or junior devs talking out of their asses about LLM coding, who anyway feel that

    > "different implementation of security for every endpoint in your app"

    is perfectly reasonable. It also seems as if people haven't sandboxed claude already (WTF), that says a lot too about the competence of people speaking here.

    by lyu07282
  • I've been running Claude Code with --dangerously-skip-permissions in a Docker container for the last month or so, allowing me to get up and stretch my legs while it does its thing. I definitely wouldn't want to run it unsandboxed.
    by steve_taylor
  • same, and unlike other repliers, I'll say one doesn't need to reinvent a new tool for this. Just use devcontainers.
    by arvyy
  • Same here. I use this utility to make it easier on Linux to run Claude in Podman: https://github.com/mismosmi/ai-pod
    by jsiepkes
  • I'm using Docker Sandboxes with a custom Kit. The cli is nice and the TUI is also good. https://docs.docker.com/ai/sandboxes/
    by etoxin
  • There's actually a setting.json key to not have to put the option
    by allan_s
  • Can you share your experience? What did you flag during those sessions?
    by konsnos
  • I built an (overengineered) app for that AIFCC https://apps.apple.com/app/aifcc-ai-first-computer/id6782364...

    runs a sandboxed linux on your mac, and the agents have full system rights within there and run in yolo mode

    by franze
  • Another nice option to do this while staying in control, is activate /remote-control and approve from mobile while walking around.
    by lukan
  • Sandboxing seems like the obvious solution. These tools prompt me to review an absurd number of very complex bash commands where there is realistically no way to carefully review them. I just want to put the thing in a box with the code and let it run any number of commands on the code without prompting.
    by SchemaLoad
  • >We hired 1,053 paid testers through a research vendor for a coding study.

    >The testers caught the dangerous command just 13.6% of the time (143 of 1,053), while auto mode blocked 89% of the same commands (937 of 1,053). Head to head, auto mode blocked 800 commands that a human approved, while humans blocked only 6 that auto mode allowed. As sessions got longer, humans did worse: they blocked about 17% of dangerous commands early in a session, dropping to about 5% after 50 or more prior prompts, while auto mode's block rate stayed flat regardless of session length.

    Any note on the proficiency, expeirence, and skill levels of the testers? 'cos the diff in numbers is absurdly high.

    by ta-run
  • I think literally anyone would stop reading these randomly long long bash commands at all after prompting Claude to do some basic sysadmin task and getting 15 of them in a row.
    by AussieWog93
  • Before auto mode came out, I had a script that ran before every permission request, it called Haiku with a prompt with a list of safe and unsafe command examples and asked it to classify as safe/unsafe and log it so I can review it later. It worked really well for me until auto mode came out, at which point I preferred the provider's built-in classifier versus maintaining my own.

    I've been using auto mode ever since the feature was released. Apart from a very few occassions where the classifier blocked a safe command, I have faced no issues and continue using it as my default mode. It's great!

    by prtmnth
  • For small projects where I don't wish to interact with Claude so much, I've started using Anthropic's sandbox runtime utility "srt":

    https://github.com/anthropic-experimental/sandbox-runtime

    This is combined with "auto" mode.

    Seems to work so far. I've manually checked various things, rw access, access to sensitive folders/files etc.

    So far, I've only used it on two small projects. My major projects I've been clicking through prompts and recently switched to "auto" mode.

    I'm not quite sure why anyone would trust "--dangerously-skip-permissions". I've seen these agents go off-piste far too many times, installing unnecessary packages, environments, calling sudo & creating files in all sorts of places.

    There's a page on various sandboxing strategies on their site:

    https://code.claude.com/docs/en/sandbox-environments

    I've seen various comments in several topics with folk baking their own sandboxes. That's great. Although I'd be inclined to try Anthropic's solutions initially.

    by bsdz
  • If you use macOS, take a look at Agent Safehouse: https://agent-safehouse.dev

    > macOS-native sandboxing for local agents. Move fast, break nothing.

    by nelox
  • Worth mentioning as I think at least a few of the commenters are mixing them up: auto mode is different from --dangerously-skip-permissions / YOLO mode. In auto mode, there's a classifier that runs before any command is executed and theoretically blocks any dangerous commands from running. I've found it to be quite annoying and overly zealous, but probably pretty effective.
    by sandcat_
  • > theoretically blocks any dangerous commands from running

    To be more precise, this article says auto mode blocked 89% of dangerous commands in their testing.

    A previous article[0] said it blocked 83%, but presumably it improved since then.

    0: https://www.anthropic.com/engineering/how-we-contain-claude

    by Fishkins
  • Claude seems to waste a lot of tokens internally bickering with itself. As much as organizations are optimizing spend, Claude's product guidance seems to be doing everything to fight against that headwind. When operating in a capped cost environment, engineers will simply get less use out of it.
    by w29UiIm2Xz
  • "We spent the last several months testing whether auto mode is as safe or safer than an average user clicking through prompts."

    Yeah, might make sense from their perspective, but no thank you. I also do click through at times without reading everything, but I like to stay in control, learn about the new code and change direction if it goes off track. This would just burn more tokens because I have to throw away much and I hope my manual approval settings will be respected also with future updates (or I jump ship).

    by lukan
  • Similar work flow.

    I have to, at times keep reminding it if it did code review before committing, which it fails to do at times. Also, even a glance at times has revealed issues that I’ve had to discuss and undo etc.

    But yes, it gets very tiring just having to click yes yes yes..

    by yumraj
  • Burning more tokens is definitely in their best interest, users not so much.
    by techpression
  • I think you are confusing auto mode with dangerously skip permissions.
    by bpodgursky
  • Having used a bit of a mix of Claude Desktop and Claude Code lately, I discovered that Claude Desktop just times out when it asks you for a decision, and just goes ahead with the action anyway. There is no way to turn this off that I've found, unlike Claude Code where you can ask it to never time out.
    by chrysoprace
  • At this stage with the latest models with "increased persistence" and the sheer amount of supply chain attacks, you'd be insane not running these tools in a sandbox.
    by etoxin
  • The default is set for the marginal new user, which at this point is probably not someone like you (who benefits a lot from manual mode) -- it's someone who's more "code-naive" and might get anxious about approving random bash script commands they don't recognize. Safely getting the user from prompt --> first vibe-coded app is the "user journey" now, and since auto mode seems pretty good at not letting Claude rm -rf'ing the home directory, this is 100% the right business move. For people who know what they're doing (like you), manual mode is just a shift-tab away
    by levocardia
  • This reminds me of a business lore I once heard about entrepreneurship. It goes on to tell how in a toothpaste company they needed to increase sales, then someone had an ingenious idea of making the hole on the tube larger so that when folks squeezed it more would come out increasing their consumption and therefore sales. It worked.

    I'll let you draw the analogy.

    by hmokiguess
  • > The auto mode classifier uses a small number of extra tokens per tool call, and we're no longer charging Claude Code users on Pro, Max, and Team plans for that classifier overhead, effective today.

    Not a very good business giving away free toothpaste :)

    by theshrike79