HN Reader

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.

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...

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.

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.

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.

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.

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....

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.

Claude Code offers sandboxing now: https://www.anthropic.com/engineering/claude-code-sandboxing

I should like to know how much this would cost? Even Claude's largest subscription appears insufficient for such token requirements.

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

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.

claude condom gives you protection on claude YOLO mode

https://github.com/nikvdp/cco

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

> That way the worst that can happen is someone else’s computer getting owned.

That way the worst thing that can happen is that you later (accidentally) trust the result of that work.

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)