Live data from Hacker News

Running Claude Code dangerously (safely)

blog.emilburzo.com

21–30 of 265 posts

Re: Running Claude Code dangerously (safely)

#21
What is the consensus on Claude Code's built-in sandboxing?

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

> Claude Code includes an intentional escape hatch mechanism that allows commands to run outside the sandbox when necessary. When a command fails due to sandbox restrictions (such as network connectivity issues or incompatible tools), Claude is prompted to analyze the failure and may retry the command with the dangerouslyDisableSandbox parameter.

The ability for the agent itself to decide to disable the sandbox seems like a flaw. But do I understand correctly that this would cause a pause to ask for the user's approval?

Re: Running Claude Code dangerously (safely)

#23
I noticed something in Claude across all product surfaces

There's a bug in that it can't output smart quotes “like this”

Sonnet, Opus et al think they output it but something in the pipeline is rewriting it

https://github.com/firasd/vibesbench/blob/main/docs/2026/A/t...

Try it in Claude Code and you'll see what I mean! Very weird

Re: Running Claude Code dangerously (safely)

#24
Here is what I do: run a container in a folder that has my entire dev environment installed. No VMs needed.

The only access the container has are the folders that are bind mounted from the host’s filesystem. The container gets network access from a transparent proxy.

https://github.com/dogestreet/dev-container

Much more usable than setting up a VM and you can share the same desktop environment as the host.

Re: Running Claude Code dangerously (safely)

#25
post #17

I have been running two or three Claude’s bare metal with dangerously skip permissions all day every day for two months now. It’s absolutely liberating.

Until it decides to delete your home directory:https://old.reddit.com/r/ClaudeAI/comments/1pgxckk/claude_cl...

Re: Running Claude Code dangerously (safely)

#28

Shellbox.dev and sprites.dev were discussed recently on hacker news, they give you a sandbox machine where it’s likely safe to run coding agents in dangerous mode. Filesystem checkpoint and restore make it easy to recover from even catastrophic mistakes.

What about API calls? What about GitHub trusted CI deploys?

One frustrating thing about these solutions is that they’re great to prevent Claude from breaking a machine, but there’s no pervasive sandbox for third party services

Re: Running Claude Code dangerously (safely)

#29
post #2

Keeping in mind with Vagrant: if you are using a synced_folder in your host as a source folder in the VM, those files in the synced_folder will be modified on the host.

If the folder is versioned and commited regularly there is no problem. It also allows you to open the files in your IDE, do some other tasks or fixes for claude. It prevents claude from accessing any other folder, which is the idea of the post.

I’ve seen Claude rm .git in rare occasions to “fix rebase hiccups”

Version control ain’t a match for a good backup

Post reply on HN