[HN Gopher] Living Dangerously with Claude
       ___________________________________________________________________
        
       Living Dangerously with Claude
        
       Author : FromTheArchives
       Score  : 205 points
       Date   : 2025-10-22 12:36 UTC (2 days ago)
        
 (HTM) web link (simonwillison.net)
 (TXT) w3m dump (simonwillison.net)
        
       | igor47 wrote:
       | My approach is to ask Claude to plan anything beyond a trivial
       | change and I review the plan, then let it run unsupervised to
       | execute the plan. But I guess this does still leave me vulnerable
       | to prompt injection if part of the plan is accessing external
       | content
        
         | ares623 wrote:
         | Just don't think about it too much. You'll be fine.
        
         | abathologist wrote:
         | What guarantees do you have it will actually follow the stated
         | plan instead of doing something else entirely?
        
       | danielbln wrote:
       | Claude Code offers sandboxing now:
       | https://www.anthropic.com/engineering/claude-code-sandboxing
        
         | js2 wrote:
         | It's discussed in the linked post.
        
       | lacker wrote:
       | The sandbox idea seems nice, it's just a question of how annoying
       | it is in practice. For example the "Claude Code on the web"
       | sandbox appears to prevent you from loading
       | `https://api.github.com/repos/.../releases/latest`. Presumably
       | that's to prevent you from doing dangerous GitHub API operations
       | with escalated privileges, which is good, but it's currently
       | breaking some of my setup scripts....
        
         | simonw wrote:
         | Is that with their default environment?
         | 
         | I have been running a bunch of stuff in there with a custom
         | environment that allows "*"
        
           | lacker wrote:
           | I whitelisted github.com, api.github.com, *.github.com, and
           | it still doesn't seem to work. I suspect they did something
           | specifically for github to prevent the agent from doing
           | dangerous things with your credentials? But I could be wrong.
        
       | matthewdgreen wrote:
       | So let me get this straight. You're writing tens of thousands of
       | lines of code that will presumably go into a public GitHub
       | repository and/or be served from some location. Even if it only
       | runs locally on your own machine, at some point you'll presumably
       | give that code network access. And that code is being developed
       | (without much review) by an agent that, in our threat model, has
       | been fully subverted by prompt injection?
       | 
       | Sandboxing the agent hardly seems like a sufficient defense here.
        
         | simonw wrote:
         | What is your worst case scenario from this?
        
           | noitpmeder wrote:
           | Bank accounts drained, ransomware installed, ...
        
           | deadbabe wrote:
           | Silently setup a child pornographer exchange server and run
           | it on your machine for years without you ever noticing until
           | you are caught and imprisoned.
        
         | tptacek wrote:
         | Where did "without much review" come from? I don't see that in
         | the deck.
        
           | enraged_camel wrote:
           | Yeah. Personally I haven't found a workflow that relies
           | heavily on detailed design specs, red/green TDD followed by
           | code review. And that's fine because that's how I did my work
           | before AI anyway, both at the individual level and at the
           | team level. So really, this is no different than reviewing
           | someone else's PR, aside from the (greatly increased)
           | turnaround time and volume.
        
             | tyre wrote:
             | I've found it helpful to have a model write a detailed
             | architecture and implementation proposal, which I then
             | review and iterate on.
             | 
             | From there it splits out each phase into three parts:
             | implementation, code review, and iteration.
             | 
             | After each part, I do a code review and iteration.
             | 
             | If asked, the proposal is broken down into small, logical
             | chunks so code review is pretty quick. It can only stray so
             | far off track.
             | 
             | I treat it like a strong mid-level engineer who is learning
             | to ship iteratively.
        
               | theshrike79 wrote:
               | I play Claude and Codex against each other
               | 
               | Codex is pretty good at finding complex bugs in the code,
               | but Claude is better at getting stuff working
        
             | Leynos wrote:
             | That's pretty much how I use Codex.
        
           | matthewdgreen wrote:
           | He wrote 14,000 lines of code in several days. How much
           | review is going on there?
        
             | simonw wrote:
             | Oh hang on, I think I've spotted a point of confusion here.
             | 
             | All three of the projects I described in this talk have
             | effectively zero risk in terms of containing harmful
             | unreviewed code.
             | 
             | DeepSeek-OCR on the Spark? I ran that one in a Docker
             | container, saved some notes on the process and then
             | literally _threw away_ the container once it had finished.
             | 
             | The Pyodide in Node.js one I did actually review, because
             | its code I execute on a machine that isn't disposable. The
             | initial research ran in a disposable remote container
             | though (Claude Code for web).
             | 
             | The Perl in WebAssembly one? That runs in a browser
             | sandbox. There's effectively nothing bad that can happen
             | there, that's why I like WebAssembly so much.
             | 
             | I am a whole lot more cautious in reviewing code that has
             | real stakes attached to it.
        
               | matthewdgreen wrote:
               | Understood. I read the article as "here is how to do YOLO
               | coding safely", and part of the "safely" idea was to
               | sandbox the coding agent. I'm just pointing out that
               | this, by itself, seems insufficient to prevent ugly
               | exfiltration, it just makes exfiltration take an extra
               | step. I'm also not sure that human code review scales to
               | this much code, nor that it can contain that kind of
               | exfiltration if the instructions specify some kind of
               | obfuscation.
               | 
               | Obviously your recommendation to sandbox network access
               | is one of several you make (the most effective one being
               | "don't let the agent ever touch sensitive data"), so I'm
               | not saying the combined set of protections won't work
               | well. I'm also not saying that your projects specifically
               | have any risk, just that they illustrate how much code
               | you can end up with very quickly -- making human review a
               | fool's errand.
               | 
               | ETA: if you do think human review can prevent secret
               | exfiltration, I'd love to turn that into some kind of
               | competition. Think of it as the obfuscated C contest with
               | a scarier twist.
        
               | tptacek wrote:
               | Is it your claim that LLMs will produce subtly obfuscated
               | secret exfiltrations?
        
               | matthewdgreen wrote:
               | Yes. If by "subtly obfuscated" you mean anything from
               | 'tucked into a comment without encoding, where you're
               | unlikely to notice it', to 'encoded in invisible Unicode'
               | to 'encoded in a lovely fist of Morse using an invisible
               | pattern of spaces and tabs'.
               | 
               | I don't know what models are capable of doing these days,
               | but I find all of these things to be plausible. I just
               | asked ChatGPT to do this and it claimed it had; it even
               | wrote me a beautiful little Python decoder that then only
               | succeeded in decoding one word. That isn't necessarily
               | confirmation, but I'm going to take that as a moral
               | victory.
        
               | tptacek wrote:
               | I don't understand this concern. The models themselves
               | are completely inscrutable, of course. But the premise of
               | safely using them in real codebases is that you know what
               | safe code in that language looks like; it's no different
               | than merging a PR from an anonymous contributor on an
               | open source project (except that the anonymous
               | contributor very definitely could be trying to sabotage
               | you and the LLM is almost certainly not).
               | 
               | Either way: if you're not sure what the code does, you
               | don't merge it.
        
               | matthewdgreen wrote:
               | The premise of TFA as understood it was that we have
               | lethal trifecta risk: sensitive data getting exfiltrated
               | via coding agent. The two solutions were sandboxing to
               | limit access to sensitive data (or just running the agent
               | on somebody else's machine) and sandboxing to block
               | outbound network connections. My only point here is that
               | once you've accepted the risk that the model has been
               | rendered malicious by prompt injection, locking down the
               | network is totally insufficient. As long as you plan to
               | release the code publicly (or perhaps just run it on a
               | machine that has network access), it has an almost
               | disturbingly exciting number of ways it can do data
               | exfiltration _via the code_. And human code review is
               | unlikely to find many of them, because the number of
               | possibilities for obfuscation is so huge you've lost even
               | if you have an amazing code reviewer (and let's be
               | honest, at 7000 SloC /day nobody is a great code
               | reviewer.)
               | 
               | I think this is exciting and if I was teaching an intro
               | security and privacy course I'd be urging my students to
               | come up with the most exciting ideas for exfiltrating
               | data, and having others trying to detect it through
               | manual and AI review. I'm pretty sure the attackers would
               | all win, but it'd be exciting either way.
        
               | tptacek wrote:
               | Huh. I don't know if I'm being too jumpy about this or
               | not.
               | 
               | The notion that Claude in yolo-mode, given access to
               | secrets in its execution environment, might exfil them is
               | a real concern. Unsupervised agents will do wild things
               | in the process of trying to problem-solve. If that's the
               | concern: I get it.
               | 
               | The notion that _the code Claude produces_ through this
               | process might exfil _its users secrets_ when _they use
               | the code_ is not well-founded. At the end of whatever
               | wild-ass process Claude undertakes, you 're going to get
               | an artifact (probably a PR). It's your job to review the
               | PR.
               | 
               | The claim I understood you to be making is that reviewing
               | such a PR is an intractable problem. But no it isn't.
               | It's a problem developers solve all the time.
               | 
               | But I may have misunderstood your argument!
        
               | thadt wrote:
               | It's an interesting risk tradeoff to think about. Is 14k
               | lines of LLM generated code more likely to have an attack
               | in it than 14k lines of transitive library dependencies I
               | get when I add a package to my project?
               | 
               | In the library case, there is a network of people that
               | could (and sometimes do) deliberately inject attacks into
               | the supply chain. On the other hand, those libraries are
               | used and looked at by other people - odds of detection
               | are higher.
               | 
               | With LLM generated code, the initial developer is the
               | only one looking at it. Getting an attack through in the
               | first place seems harder, but detection probability is
               | lower.
        
         | daxfohl wrote:
         | That's kind of tangential though. The article is more about
         | using sandboxes to allow `--dangerously-skip-permissions` mode.
         | If you're not looking at the generated code, you're correct,
         | sandboxing doesn't help, but neither does permissioning, so
         | it's not directly relevant to the main point.
        
           | hypercube33 wrote:
           | I've noted a few tools seem to have this now if you dig into
           | their settings. vscode has yolo mode and cursor seemed to
           | have something as well. wild
        
           | matthewdgreen wrote:
           | My point is that if the threat model is "agent got sensitive
           | information and wants to exfiltrate it", looking at the code
           | isn't going to save you. You're already dead. This was the
           | threat outlined in TFA.
        
       | catigula wrote:
       | Telling Claude to solve a problem and walking away isn't a
       | problem you solved. You weren't in the loop. You didn't complete
       | any side quests or do anything of note, you merely watched an AGI
       | work.
        
         | simonw wrote:
         | Here's one I did even less work for:
         | https://tools.simonwillison.net/terminal-to-html - prompt and
         | video here: https://simonwillison.net/2025/Oct/23/claude-code-
         | for-web-vi...
        
         | _factor wrote:
         | Writing your Java code on an IDE, you just sat by while the
         | interpreter did all the work on the generated byte code and
         | corresponding assembly.
         | 
         | You merely watched the tools do the work.
        
           | bitpush wrote:
           | This exactly is the part that lots of folks are missing. As
           | programmers in a high level language (C, Rust, Python ..) we
           | were merely guiding the compiler to create code. You could
           | say the compiler/interpreter is more deterministic, but the
           | fact remains the code that is run is 100% not what you wrote,
           | and you're at the mercy of the tool .. which we trust.
           | 
           | Compiled output can change between versions, heck, can even
           | change during runtime (JIT compilation).
        
             | catigula wrote:
             | The hubris here, which is very short-sighted, is the idea
             | that a. You have very important contributions to make and
             | b. You cannot possibly be replaced.
             | 
             | If you're barely doing anything neither of these things can
             | possibly be true even with current technology.
        
           | catigula wrote:
           | This is a failure of analogy. Artificial intelligence isn't a
           | normal technology.
        
           | voidhorse wrote:
           | I don't think anyone would claim that writing a poem yourself
           | and hiring someone to write a poem for you are the same
           | thing.
           | 
           | In the same way, there is a distinct difference form having
           | and encoding the concepts behind a piece of software yourself
           | and having a rough idea of what you want and hiring a bunch
           | of people to work out that conceptualization for you.
           | Contrarily, a compiler or interpreter is just a strict
           | translation of one representation of that conceptualization
           | into another (modulo maybe alterations in one dimension,
           | namely efficiency). It's a completely different dynamic and
           | these snarky analogies are either disingenuous or show that
           | AI boosters understand and reflect on what it is they are
           | really doing far less than the critics.
        
         | wahnfrieden wrote:
         | Who cares? I don't see any issue. I write code to put software
         | into users hands, not because I like to write code.
        
           | catigula wrote:
           | You don't see any issue with the _I_ in this equation falling
           | out of relevance?
           | 
           | Not even a scrap of self-preservation?
        
             | wahnfrieden wrote:
             | Since I ended my career as a wage worker and just sell my
             | own software now, automation is great for me. Even before
             | GPT hype I saw the writing on the wall for relying on a
             | salary and got out so that I could own the value of my
             | labor.
             | 
             | I don't see my customers being able to one-shot their way
             | to the full package of what I provide them anytime soon
             | either. As they gain that capability, I also gain the
             | capability to accelerate what more value I provide them.
             | 
             | I don't think automation is the cause of your inability to
             | feed and house yourself if it reduces the labor needed by
             | capital. That's a social and political issue.
             | 
             | Edit: I have competitors already cloning them with CC
             | regularly, and they spend more than 24h dedicated to it too
             | 
             | If the capability does arrive, that's why I'm using what I
             | can today to get a bag before it's too late.
             | 
             | I can't stop development of automation. But I can help
             | workers organize, that's more practical.
        
               | catigula wrote:
               | >I don't see my customers being able to one-shot their
               | way to the full package of what I provide them anytime
               | soon either
               | 
               | What if they are, or worse? Are you prepared for that?
               | 
               | If you point me towards your products, someone can try to
               | replicate them in 24 hours. Sound good?
               | 
               | Edit: I found it, but your website is broken on mobile.
               | Needs work before it's ready to be put into the
               | replication machine. If you'd like I can do this for you
               | for a small fee at my consulting rate (wink emoji).
        
               | dist-epoch wrote:
               | > someone can try to replicate them in 24 hours.
               | 
               | All the more reason to not hand-code it in a week.
        
               | wahnfrieden wrote:
               | Idk what you found but it's an iOS/Mac app
               | 
               | I'm not sure what your point is. That I should give up
               | because everything can already be replicated? That I
               | shouldn't use LLMs to accelerate my work? That I should
               | feel bad for using them?
        
             | ares623 wrote:
             | I live for shareholder value.
        
               | wahnfrieden wrote:
               | It feels great to when I'm the only shareholder
        
             | dist-epoch wrote:
             | Do you think a programmer not using AI will stop it's march
             | forward?
        
               | catigula wrote:
               | If more people see the cows 4 beef analogy we gain more
               | votes against it.
        
               | Applejinx wrote:
               | ...over a road of bones? Is that your image?
               | 
               | I'm not scared for me, but I'm definitely worried for
               | some of you. You seem weirdly trusting. What if the thing
               | you're counting on is really not all you think it is? So
               | far I'm about as impressed as I am of the spam in my
               | inbox.
               | 
               | There sure is a lot of it, but the best it can do is fool
               | me into evaluating it like it's a real communication or
               | interaction, only to bounce off the basic hollowness of
               | what's offered. What I'm trying to do it doesn't _do_...
               | I've got stuff that does, for instance leaning into the
               | genetic algorithm, but even then dealing with optimizing
               | fitness functions is very much on me (and is going well,
               | thanks for asking).
               | 
               | Why should I care if AI is marching if it's marching in
               | circles, into a wall, or off a cliff? Maybe what you're
               | trying to do is simply not very good or interesting. It'd
               | be nice if my work could get away with such hollow, empty
               | results but then I wouldn't be interested in it either...
        
               | wahnfrieden wrote:
               | As your response is that for someone to find productivity
               | with this tool, the only way you can understand that to
               | be true is for their work to be hollow and the results
               | uninteresting and must be beneath you, I will simply say
               | about the rest of your message: Skill issue
        
         | bdangubic wrote:
         | exactly. the problem did get solved though which is the whole
         | point :)
        
       | stuaxo wrote:
       | I've been thinking about this a bit.
       | 
       | I reckon something lie Qubes could work fairly well.
       | 
       | Create a new Qube and have control over network connectivity, and
       | do everything there, at the end copy the work out and destroy it.
        
       | boredtofears wrote:
       | I like the best of both worlds approach of asking Claude to
       | refine a spec with me (specifically instructing it to ask me
       | questions) and then summarize an implementation or design plan
       | (this might be a two step process if the feature is big enough)
       | 
       | When I'm satisfied with the spec, I turn on "allow all edits"
       | mode and just come back later to review the diff at the end.
       | 
       | I find this works a lot better than hoping I can one shot my
       | original prompt or having to babysit the implementation the whole
       | way.
        
         | wahnfrieden wrote:
         | I recommend trying a more capable model that will read much
         | more context too when creating specs. You can load a lot of
         | full files into GPT 5 Pro and have it produce a great spec and
         | give more surgical direction to CC or Codex (which don't read
         | full files and often skip over important info in their haste).
         | If you have it provide the relevant context for the agent, the
         | agent doesn't waste tokens gathering it itself and will proceed
         | to its work.
        
           | boredtofears wrote:
           | Is there an easy way to get a whole codebase into GPT 5 Pro?
           | It's nice with claude to be able to say "examine the current
           | project in the working directory" although maybe that's
           | actually doing less than I think it is.
        
             | simonw wrote:
             | I wrote a tool for that: https://github.com/simonw/files-
             | to-prompt - and there are other similar tools like repomix.
             | 
             | These days I often use https://gitingest.com - it can grab
             | any full repo on GitHub has something you can copy and
             | paste, e.g. https://gitingest.com/simonw/llm
        
               | boredtofears wrote:
               | Of course you did - thanks, huge fan!
        
               | dist-epoch wrote:
               | I wrote a similiar tool myself, mostly because your tool
               | or repomix doesn't support "presets" (saved settings):
               | [client]         root = "~/repo/client"         include =
               | [             "src/**/*.ts",             "src/**/*.vue",
               | "package.json",             "tsconfig*.json",
               | "*.ts",         ]         exclude = [
               | "src/types/*",             "src/scss/*",         ]
               | output = "bundle-client.txt"              $ bundle -p
               | client
               | 
               | What do you do when you repeatedly need to bundle the
               | same thing? Bash history?
        
       | almosthere wrote:
       | Anyone from the Cursor world already YOLO's it by default.
       | 
       | A massive productivity boost I get is using to do server
       | maintenance.
       | 
       | Using gcloud compute ssh, log into all gh runners and run docker
       | system prune, in parellel for speed and give me a summary report
       | of the disk usage after.
       | 
       | This is an undocumented and underused feature of basic agentic
       | abilities. It doesn't have to JUST write code.
        
         | simonw wrote:
         | Does Cursor have a good sandboxing story?
        
           | tuhgdetzhh wrote:
           | I run multiple instances of cursor cli yolo in a 4 x 3 tmux
           | grid each in an isolated docker container. That is a pretty
           | effective setup.
        
           | dns_snek wrote:
           | There's no sandbox of any kind, at least on Linux, and the
           | permission system is self-defeating. The agent will ask to
           | run something like `bash -c "npm test"` and ask you to
           | whitelist "bash" for future use. I don't use it daily because
           | I don't find it useful to begin with, but when I take it for
           | a spin it's always inside a full VM.
        
         | normie3000 wrote:
         | Is this what ansible does? Or some other classic ops tool?
        
         | mandevil wrote:
         | There are a million different tools that are designed to do
         | this, e.g. this task (log into a bunch of machines and execute
         | a specific command without any additional tools running on each
         | node) is literally the design use case for Ansible. It would be
         | a simple playbook, why are you bringing AI into this at all?
        
           | giobox wrote:
           | Agreed, this is truly bizarre to me. Is OP not going to have
           | to do this work all over again in x days time once the nodes
           | fill with stale docker assets again?
           | 
           | AI can still be helpful here if new to scheduling a simple
           | shell command, but I'd be asking the AI how do I automate the
           | task away, not manually asking the AI to do the thing every
           | time, or using my runners in a fashion that means I don't
           | have to even concern myself with scheduled prune command
           | calls.
        
             | bdangubic wrote:
             | > but I'd be asking the AI how do I automate the task away
             | 
             | AI said "I got this" :)
        
             | almosthere wrote:
             | No, we have a team dedicated to fixing this long term, but
             | this allowed 20 engineers to get working right away. Long
             | term fix is now in.
        
               | giobox wrote:
               | If a team of 20 engineers got blocked because you/the
               | team didn't run docker prune, you arguably have even
               | bigger problems...
        
           | ericmcer wrote:
           | Yeah that sounds like a CI/CD task or scheduled job. I would
           | not want the AI to "rewrite" the scripts before running them.
           | I can't really think of why I would want it to?
        
           | almosthere wrote:
           | Because I didn't have to do anything other than write that
           | english statement and it worked. Saved me a long time.
        
             | mandevil wrote:
             | I'm glad this worked for you, but if it were me at most I
             | would have asked Claude Code to write me an Ansible
             | playbook for doing this, then run it myself. That gives me
             | more flexibility to run this in the future, to change the
             | commands, to try it, see that it fails, and do it again,
             | etc.
             | 
             | And I honestly am a little concerned about a private key
             | for a major cloud account where Claude can use it, just
             | because I'm more than a little paranoid about certs.
        
               | cowboy_henk wrote:
               | You're right to be concerned. OPs method is how you get
               | pwned through prompt injection.
        
         | wrs wrote:
         | Yesterday I was trying to move a backend system to a new AWS
         | account and it wasn't working. I asked Claude Code to figure it
         | out. About 15 minutes and 40 aws CLI commands later, it did!
         | Turned out the API Gateway's VPCLink needed a security group
         | added, because the old account's VPC had a default egress rule
         | and the new one's didn't.
         | 
         | I barely understand what I just said, and I'm sure it would
         | have taken me a whole day to track this down myself.
         | 
         | Obviously I did NOT turn on auto-approve for the aws command
         | during this process! But now I'm making a restricted role for
         | CC to use in this situation, because I feel like I'll certainly
         | be doing something like this again. It's like the AWS Q button,
         | except it actually works.
        
           | tecoholic wrote:
           | This kind of trial and error debugging is the main reason I
           | pay for Calude Code. Software development and writing code is
           | meh. I mean, it's okay. But I have a strong opinion on most
           | coding tasks. But debugging something I touch once in a blue
           | moon, trying out 10 commands before I find the failure point
           | - that's just something else.
        
           | gyomu wrote:
           | > I barely understand what I just said, and I'm sure it would
           | have taken me a whole day to track this down myself.
           | 
           | This is what the future of IT work looks like
        
             | BobbyTables2 wrote:
             | But it's scalable! (And has electrolytes)
        
               | blitzar wrote:
               | It's got what code craves.
        
             | dandanua wrote:
             | As long as $ millions will keep flowing to owners and CEOs
             | no one would see a slightest issue with that.
        
           | jtbaker wrote:
           | Better yet would be to have it codify the config using IAC
           | for reproducibility.
        
         | manmal wrote:
         | Relevant: https://steipete.me/posts/2025/claude-code-is-my-
         | computer
        
         | psyclobe wrote:
         | Yeah totally setting it lose on your home lab is quite an eye
         | opener. It'll tip up recovery scripts diagnose hung systems
         | figure out root causes of driver bugs; Linux has never been so
         | user friendly!
         | 
         | Bonus points I finally have permissions sorted out on my samba
         | share haha ...
         | 
         | (For years I was befuddled by samba config)
        
         | adamcharnock wrote:
         | I don't quite go this far, but I do use Claude/Codex to write
         | Ansible playbooks/roles/collections that then do this kind of
         | thing.
         | 
         | It is very easy to see what actions are being taken from the
         | code produced, and then one gets a tool that can be used over
         | and over again.
         | 
         | You can then also put these into mise tasks, because mise is
         | great too.
        
       | mike_hearn wrote:
       | sandbox-exec isn't really deprecated. It's just a tiny wrapper
       | around some semi-private undocumented APIs, it says that because
       | it's not intended for public use. If it were actually deprecated
       | Apple would have deleted it at some point, or using it would
       | trigger a GUI warning, or it'd require a restricted entitlement.
       | 
       | The reason they don't do that is because some popular and
       | necessary apps use it. Like Chrome.
       | 
       | However, I tried this approach too and it's the wrong way to go
       | IMHO, quite beyond the use of undocumented APIs. What you
       | actually want to do is virtualize, not sandbox.
        
         | krackers wrote:
         | Fun fact: the sandboxing rules are defined using scheme!
        
       | jampa wrote:
       | I don't understand why people advocate so strongly for
       | `--dangerously-skip-permissions`.
       | 
       | Setting up "permissions.allow" in `.claude/settings.local.json`
       | takes minimal time. Claude even lets you configure this while
       | approving code, and you can use wildcards like "Bash(timeout:*)".
       | This is far safer than risking disasters like dropping a staging
       | database or deleting all unstaged code, which Claude would do
       | last week, if I were running it in the YOLO mode.
       | 
       | The worst part is seeing READMEs in popular GitHub repos telling
       | people to run YOLO mode without explaining the tradeoffs. They
       | just say, "Run with these parameters, and you're all good, bruh,"
       | without any warning about the risks.
       | 
       | I wish they could change the parameter to signify how scary it
       | can be, just like React did with
       | React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED
       | (https://github.com/reactjs/react.dev/issues/3896)
        
         | dist-epoch wrote:
         | I tried this path. The issue is that agents are very creating
         | in coming up with new variations. "uv run pytest", "python3 -m
         | pytest", "bash -c pytest"
         | 
         | It's a never ending game of whitelisting.
        
           | Jianghong94 wrote:
           | this seem solvable if the whitelisting just allows regex
        
         | bdangubic wrote:
         | changing the parameter name to something scary will only
         | increase its usage
        
       | ZeroConcerns wrote:
       | So, yeah, only tangentially related, but if anyone at Anthropic
       | would see it fit to let Claude loose on their DNS, _maybe_ they
       | can create an MX record for  'email.claude.com'?
       | 
       | That would mean that their, undoubtedly extremely interesting,
       | emails actually get met with more than a "450 4.1.8 Unable to
       | find valid MX record for sender domain" rejection.
       | 
       | I'm sure this is just an oversight being caused by obsolete
       | carbon lifeforms still being in charge of parts of their
       | infrastructure, but still...
        
         | tryauuum wrote:
         | a not really related fact. I remember reading some RFC, and the
         | sender should try sending to the server specified in A record
         | if there are no MX records present
        
           | rstupek wrote:
           | You are correct that is the expected order of operations
        
           | vidarh wrote:
           | This sounds like it's an _inbound_ check, as part of spam
           | prevention, by seeing if the sending domain looks legitimate.
           | There are a whole lot of those that are common that are not
           | covered in RFCs.
        
       | zxilly wrote:
       | I should like to know how much this would cost? Even Claude's
       | largest subscription appears insufficient for such token
       | requirements.
        
         | simonw wrote:
         | I ran a cost estimate on the project I describe in
         | https://simonwillison.net/2025/Oct/23/claude-code-for-web-vi...
         | - which was covered by my Claude Max account, but I dug through
         | the JSONL log files for that session to try and estimate the
         | cost if I had been using the API.
         | 
         | The cost estimate came out to 63 cents - details here:
         | https://gistpreview.github.io/?27215c3c02f414db0e415d3dbf978...
        
           | jh3 wrote:
           | What are you doing to keep a JSONL per session? Or is this
           | something built in? I'm interested in estimating token costs
           | in this way.
        
             | simonw wrote:
             | It's built in - the ~/.claude/projects folder stores the
             | JSONL for 30 days or you can extend the retention time like
             | this: https://simonwillison.net/2025/Oct/22/claude-code-
             | logs/
        
       | pdntspa wrote:
       | I guess it's great if you don't give a shit about code quality,
       | particularly in a larger project.
       | 
       | What I see are three tiny little projects that do one thing.
       | 
       | That is boring. We already know the LLMs are good at that.
       | 
       | Let's see it YOLO into a larger codebase with protocols and a
       | growing feature set without making a complete mess of things.
       | 
       | So far CC has been great for letting me punch above my weight but
       | the few times I let it run unattended it has gone against
       | conventions clearly established in AGENTS.md and I wasn't there
       | to keep it on the straight and narrow. So a bunch more time had
       | to be spent untangling the mess it created.
        
         | Zarathruster wrote:
         | Yeah I don't know if this is a skill issue on my part, the
         | nature of my projects, the limits of Sonnet vs. Opus, or a
         | combination of all of the above, but my experiences track with
         | all of yours.
         | 
         | From the article:
         | 
         | > The default mode requires you to pay constant attention to
         | it, tracking everything it does and actively approving changes
         | and actions every few steps.
         | 
         | I've never seen a YOLO run that _doesn 't_ require me to pay
         | constant attention to it. Within a few minutes, Claude will
         | have written bizarre abstractions, dangerous delegations of
         | responsibility, and overall the smelliest code you'll see
         | outside of a coding bootcamp. And god help you if you have both
         | client and server code within the same repo. In general Claude
         | seems to think that it's fine to wreak havoc in existing code,
         | for the purpose of solving whatever problem is immediately at
         | hand.
         | 
         | Claude has been very helpful to me, but only with constant
         | guidance. Believe me, I would very much like to YOLO my
         | problems away without any form of supervision. But so far, the
         | only useful info I've received is to 1) only use it for side
         | projects/one-off tools, and 2) make sure to run it in a
         | sandbox. It would be far more useful to get an explanation for
         | how to craft a CLAUDE.md (or, more generally, get the right
         | prompt) that results in successful YOLO runs.
        
       | burgerquizz wrote:
       | claude condom gives you protection on claude YOLO mode
       | 
       | https://github.com/nikvdp/cco
        
       | corv wrote:
       | We've been exploring libseccomp/BPF filters on top of bubblewrap
       | namespaces for LLM sandboxing - the BPF layer lets you go beyond
       | read-only mounts to syscall restrictions. Open to collaboration
       | on pushing this further: https://github.com/corv89/shannot
        
       ___________________________________________________________________
       (page generated 2025-10-24 23:02 UTC)