Live data from Hacker News

Go hard on agents, not on your filesystem

jai.scs.stanford.edu

131–140 of 374 posts

Re: Go hard on agents, not on your filesystem

#131
post #129

Add this to .claude/settings.json: { "sandbox": { "enabled": true, "filesystem": { "allowRead": ["."], "denyRead": ["~/"], "allowWrite": ["."], "denyWrite": ["/"] } } } You can change the read part if you're ok with it reading outside. This feature was only added 10 days ago fwiw but it's great and pretty much this.

It’s cute because Claude has discretion to disable its own sandbox and does it

> You can disable this escape hatch by setting "allowUnsandboxedCommands": false in your sandbox settings. When disabled, the dangerouslyDisableSandbox parameter is completely ignored and all commands must run sandboxed or be explicitly listed in excludedCommands.

https://code.claude.com/docs/en/sandboxing

(I have no idea why that isn't the default because otherwise the sandbox is nearly pointless and gives a false sense of security. In any case, I prefer to start Claude in a sandbox already than trust its implementation.)

Re: Go hard on agents, not on your filesystem

#132

Add this to .claude/settings.json: { "sandbox": { "enabled": true, "filesystem": { "allowRead": ["."], "denyRead": ["~/"], "allowWrite": ["."], "denyWrite": ["/"] } } } You can change the read part if you're ok with it reading outside. This feature was only added 10 days ago fwiw but it's great and pretty much this.

I’m surprised it works for you with such a simple config? I’m the one that added the allowRead option to Claude’s underlying sandbox [0] and had quite a job getting my toolchains and skills to work with it [1].

[0] Fun to see the confusing docs I wrote show up more or less verbatim on Claude’s docs.

[1] My config is here, may be useful to someone: https://github.com/carderne/pi-sandbox/blob/main/sandbox.jso...

Re: Go hard on agents, not on your filesystem

#133
post #81

This looks great and seems very well thought out. It looks both more convenient and slightly more secure than my solution, which is that I just give them a separate user. Agents can nuke the "agent" homedir but cannot read or write mine. I did put my own user in the agent group, so that I can read and write the agent homedir. It's a little fiddly though (sometimes the wrong permissions get set, so I have a script tha…

Where this falls down is that for the agents to interact with anything external, you have to give them keys. Without a proxy handling real keys between your agent and external services, those keys are at risk of compromise. Also. Agents are very good at hacking “security penetration testing”, so “separate user” would not give me enough confidence against malicious context.

So don't let them interact with anything external. You can push and pull to their git project folders over the local filesystem or network, they don't even need access to a remote.

Re: Go hard on agents, not on your filesystem

#134
post #81

This looks great and seems very well thought out. It looks both more convenient and slightly more secure than my solution, which is that I just give them a separate user. Agents can nuke the "agent" homedir but cannot read or write mine. I did put my own user in the agent group, so that I can read and write the agent homedir. It's a little fiddly though (sometimes the wrong permissions get set, so I have a script tha…

The user thing is what I currently do too. I've thought about containers but then it's confusing for everyone when I ask it to create and use containers itself.

Re: Go hard on agents, not on your filesystem

#135

Add this to .claude/settings.json: { "sandbox": { "enabled": true, "filesystem": { "allowRead": ["."], "denyRead": ["~/"], "allowWrite": ["."], "denyWrite": ["/"] } } } You can change the read part if you're ok with it reading outside. This feature was only added 10 days ago fwiw but it's great and pretty much this.

Is that hard setting or does it depend on claude’s interpretation?

The latter could end like this https://news.ycombinator.com/item?id=47357042

Re: Go hard on agents, not on your filesystem

#137

Add this to .claude/settings.json: { "sandbox": { "enabled": true, "filesystem": { "allowRead": ["."], "denyRead": ["~/"], "allowWrite": ["."], "denyWrite": ["/"] } } } You can change the read part if you're ok with it reading outside. This feature was only added 10 days ago fwiw but it's great and pretty much this.

So in some sense we start recreating an operating system, or at least the userspace, within the Claude code. There was some name for this pattern but I can’t recall

It’s some sort of machine inside of a machine I think. Wait, I got it: a simulated machine!

Re: Go hard on agents, not on your filesystem

#138

Add this to .claude/settings.json: { "sandbox": { "enabled": true, "filesystem": { "allowRead": ["."], "denyRead": ["~/"], "allowWrite": ["."], "denyWrite": ["/"] } } } You can change the read part if you're ok with it reading outside. This feature was only added 10 days ago fwiw but it's great and pretty much this.

Is this a hard sandbox (enforced outside the LLM)?

Re: Go hard on agents, not on your filesystem

#139

I am still amazed that people so easily accepted installing these agents on private machines. We've been securing our systems in all ways possible for decades and then one day just said: oh hello unpredictable, unreliable, Turing-complete software that can exfiltrate and corrupt data in infinite unknown ways -- here's the keys, go wild.

People were also dismissing concerns about build tooling automatically pulling in an entire swarm of dependencies and now here we are in the middle of a repetitive string of high profile developer supply chain compromises. Short term thinking seems to dominate even groups of people that are objectively smarter and better educated than average.

Objectively smart people wouldn't be working so hard at making themselves obsolete.

Re: Go hard on agents, not on your filesystem

#140

Earlier quoted context omitted.

People were also dismissing concerns about build tooling automatically pulling in an entire swarm of dependencies and now here we are in the middle of a repetitive string of high profile developer supply chain compromises. Short term thinking seems to dominate even groups of people that are objectively smarter and better educated than average.

“Objectively smarter” is the last descriptor I’d apply to software developers

My intent was to cast a very wide net there that covers more or less all expert knowledge workers. Zingers aside software developers as a group are well above the societal mean in many respects.
Post reply on HN