[HN Gopher] Slightly safer vibecoding by adopting old hacker habits
___________________________________________________________________
Slightly safer vibecoding by adopting old hacker habits
Author : transpute
Score : 167 points
Date : 2026-04-03 01:53 UTC (5 days ago)
(HTM) web link (addxorrol.blogspot.com)
(TXT) w3m dump (addxorrol.blogspot.com)
| thwarted wrote:
| Generally a good idea, but I'm not sure why you should even want
| to _fork_ a git repo when a local clone should be sufficient. But
| this is probably a terminology mixup from the way github presents
| forks and clones.
| ozozozd wrote:
| They mention that as a mechanism for protecting the SSH keys
| for the repo.
|
| Essentially using a repo that doesn't matter with the coding
| agent and then creating a cross-repo PR to the real repo.
| dddddaviddddd wrote:
| I believe the author's idea is to do dev work from a Github
| account that only has access to the fork, but not to the main
| repo. Then, as a contributor, you'd open PRs from your fork to
| the main repo. I think this would only work if your Github
| account doesn't have write access to the main repo, though. I
| know you can use 'deployment keys' to give read-access to a
| single repo using an SSH key, but not sure if you can otherwise
| restrict access to a single repo with write access.
| Essentially, though, you'd want to find a way to give the
| remote host the most limited possible privileges to your Github
| account.
| thwarted wrote:
| Oh, a separate GitHub account that has its own forks of the
| repos the agent is working on. Yeah, that's probably the most
| secure, isolated, and safest. The merge to the canonical repo
| then needs to go through a human, or at least separately
| controlled, process via a GitHub pull request.
| throwaway173738 wrote:
| You could also just set the development machine up as a
| remote on the repo on your local host and then pull, diff,
| and merge locally. Then the llm agent doesn't have access to
| any github account at all.
| kstenerud wrote:
| I use an overlay copy of my workdir, then the sandboxed LLM
| doesn't get any of my secrets, can do its own commits, and
| I pull the ones back that I want.
| dolmen wrote:
| On a GitHub project, agents must just be considered untrusted
| external contributors.
| dezgeg wrote:
| Maybe this is doable with scoped API keys instead of SSH
| keys?
| dfedbeef wrote:
| the old hacker trick of using ssh
| number6 wrote:
| Ten more years and our tricks become the ancient practices and
| rituals of the olden hack0rs; stuff like apt update and apt
| upgrade on a fresh server. Some of the most ancient even use
| apt-get, while the really old ones will scold you for using
| Ubuntu
| mech422 wrote:
| Hey! I resemble that comment :-P (I still tend to use apt-get
| out of habit...)
| kstenerud wrote:
| This is what yoloAI does. Automatically. #
| Create a new sandbox copying . as workdir (default container, but
| you can choose vm) yoloai new mybugfix . --isolation vm
| # attach to it (it has tmux already) yoloai attach
| mybugfix # Chat with the bot inside...
| # Happy with its work? Diff it to be sure yoloai diff
| mybugfix # Happy with the changes? Apply them to
| your workdir yoloai apply mybugfix # All
| done? Destroy the sandbox yoloai destroy mybugfix
|
| The agent stays isolated at all times. No access to your secrets
| (except what you want), no access to your workdir until you
| apply. You can also easily restrict network access.
|
| https://github.com/kstenerud/yoloai
| ori_b wrote:
| Spammy ai-generated self promotion.
| kstenerud wrote:
| In what way?
|
| This does the same thing as in the blog post, except that
| there are a LOT of gotchas and minutiae and some yak shaving
| involved if you want to keep doing it manually.
|
| I've gone through the whole path the author has, and finally
| had to admit that it's too much fiddling around to do it
| manually. Easier to just have a cmdline tool that does it for
| you. That's why I built it in the first place.
| creata wrote:
| The part that worries me here is the diff. Does it happen in
| the host or in the guest? What code gets run when you run
| `yoloai diff`?
| kstenerud wrote:
| It actually runs git (with hooks disabled) to generate the
| diff. It happens on the host when using copy mode, and inside
| the sandbox when using overlay mode.
|
| The above example doesn't specify workdir mounting mode, so
| it would be copy, not overlay.
| creata wrote:
| If it runs inside the sandbox and the guest is compromised,
| can't the guest just lie?
| kstenerud wrote:
| Absolutely. That's why overlay is not the default.
| creata wrote:
| That's... uh, an interesting approach to security.
| kstenerud wrote:
| What is? Defaulting to the most secure method?
| trinsic2 wrote:
| IM new to Claude code but doesnt auth require a gui browser to
| authenticate the Claude session first time login?? Do you have to
| setup a desktop environment just for that?
| nwatson wrote:
| If the Claude (or similar) can't open a browser on a headless
| server, they typically print a URL you can copy to your browser
| on your local system-with-GUI. From there you authenticate and
| get back some kind of token, which you copy and paste back into
| your remote SSH session.
| kstenerud wrote:
| You can copy your claude credentials into the VM and run off
| that. Just beware that the subscription credentials file
| expires every half hour and then the agent tries to refresh
| which is annoying (especially if you have multiple sandboxed
| agents), so the better way is to get a long-running
| subscription API key (no extra cost for that) and just pass it
| in.
| michaelt wrote:
| You can run all the major CLI tools without a browser.
|
| When they try to open a browser, they also print the URL to the
| console. Open that in your browser and go through an
| authentication flow; it'll end forwarding you to a localhost
| URL like http://127.0.0.1:8080/authorization-
| code/callback?code=XXXX&... which will fail.
|
| Copy that callback URL, connect to your VM/docker container,
| and curl it.
|
| The curl stage requires the agent make a call to auth.whatever-
| vendor.com so if it fails at this stage, check your
| VM/container network settings. And make sure you quoted the
| curl right so the & wasn't misinterpreted.
|
| It'll then save a file at ~/.codex/auth.json or ~/.claude.json
| or similar, so you won't need to log in again. The secret in
| this file will periodically rotate, so you need to mount it
| read-write not read-only.
| mike-cardwell wrote:
| https://gitlab.com/grepular/claude-sandbox runs claude in a
| podman container. The way it deals with this is:
|
| claude-cli executes whatever is in the BROWSER env variable to
| open your browser at a current URL, so I pointed it at a simple
| shell script that writes the URL to a named pipe which is
| mounted into the container. The sandbox tool outside of the
| container is reading from that named pipe. When it receives a
| URL to open, it pops up a confirmation dialog with info about
| the URL. If you accept, it opens it in your host browser.
|
| The second step is, the callback URL after you sign in on the
| claude website wants to connect back to a port on localhost to
| complete the sign in. If the sandbox is being run with host
| networking mode, this just works fine as claude cli has already
| opened that port so it's listening on the host network. However
| if it is not running in host networking mode, the sandbox tool
| figures out what port it need to listen on from looking at the
| URL, listens to it, and when it is hit, it just podman exec's
| curl inside the container to complete the callback.
| codemog wrote:
| I would guess OpenAI Codex and Claude Code are well into the
| millions subscriber range at this point. I would venture to guess
| the majority of them run in yolo mode. I have only seen a few
| horror stories on reddit. The same way any time you drive a car
| you can crash and die (many times through no fault of your own).
|
| All that said, no way in hell I'm giving either access to
| production databases or environments.
| calpaterson wrote:
| I have heard of more than a few horror stories including
| filesystems lost and force pushes done.
|
| These tools have only been in use for a short time and the
| current harnesses/system prompts are quite limited. Claude code
| is mostly limited to your codebase where you have version
| control. Excel is different.
|
| I foresee that once people hand over more power to full agents
| there will be some nasty surprises. Im sure there will
| eventually be demand for some kind of limits
| andai wrote:
| Yeah, I was thinking about simonw's lethal trifecta[0] and how
| to solve it and my conclusion was "you cannot", i.e. you just
| accept a certain level of risks for the rewards it offers.
|
| The "agent never sees keys" approach prevents key exfiltration,
| but it doesn't prevent agent from nuking what it has access to,
| nor prevent data exfiltration.
|
| The best advice I heard to protect against prompt injection was
| "just use Opus" ( ... which was great advice before they
| lobotomized it ;)
|
| But even without injection, most of the horror stories are from
| random error, or the AI trying to be helpful (e.g. stealing
| your keys or working around security restrictions, because they
| trained or to _really_ want to complete a task.[1])
|
| tl;dr yolo
|
| [0] https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
|
| [1]
| https://www.reddit.com/r/ClaudeAI/comments/1r186gl/my_agent_...
| unsupp0rted wrote:
| Codex 5.4 medium couldn't figure out how to run tests in my
| staging Cloudflare so it went ahead and ran those tests against
| prod. Mission accomplished.
|
| Yes, agents.md yells not to mess with prod.
| Orygin wrote:
| > Yes, agents.md yells not to mess with prod.
|
| Probably what nudged it to run on prod in the first place
| jillesvangurp wrote:
| It's a variation of sandboxing which is a great idea. Even just
| using a separate user account on your laptop provides some useful
| level of isolation (as long as you don't give it sudo
| privileges). AI tools of course do some sandboxing of their own.
| It's just that the constant nagging for permissions causes people
| to negate most of that by giving very broad access outside the
| sandbox.
|
| The downside for me and the main reason I do use vms less than I
| did a few months ago is that I need my agentic coding tools to
| use development tools a lot. And those tools need a lot of
| resources. And I have those resources on my laptop. Which is a
| nice mac book pro with plenty of RAM and 16 CPUs. I can run vms
| on this thing without issues of course. But tools just run a lot
| faster when I run them outside those VMs. And agentic coding
| tools run builds all the time. We're talking some really non
| trivial time savings here. Watching qemu build a thing for 10
| minutes that I know should build in 45 seconds is painful.
| Especially if it happens over and over again.
|
| The trick is doing sandboxing without performance impact. And
| very soon you'll also want to be able to run local models. I've
| been toying with the latest qwen and gemma models on my laptop. I
| haven't gotten around to doing coding with those just yet. But
| apparently they aren't completely horrible at it. That won't work
| on most cloud based vms. Unless you get a really big and
| expensive one. You could actually make that work if you only use
| them for a few minutes.
| kstenerud wrote:
| You can run inside of a tart vm which gives you a virtual mac.
| It's pretty speedy once it's up and running.
| lukebyear wrote:
| agent-safehouse (https://agent-safehouse.dev) was my answer to
| this.
|
| I was using Docker containers for sandboxing but it was
| annoying at times, not so much for the performance hit (which
| wasn't noticeable running in OrbStack) but various little
| papercuts like no shared clipboard, node_modules pulling in
| Linux binaries or macOS binaries depending on whether I ran npm
| install from inside the sandbox or my own shell, etc.
|
| With agent-safehouse, I get the isolation I want (more
| customizable than with Docker) without needing a VM or
| container.
| monksy wrote:
| I've been successful with getting incus running with this for
| sandboxing the opencode session. I plan on writing a blog post on
| it.
| indigodaddy wrote:
| This might interest you (disclaimer my project. Well mostly
| Opus')
|
| https://github.com/jgbrwn/vibebin
| VerifiedReports wrote:
| "Vibecoding?"
|
| Gotta love how someone downvoted this.
| nzoschke wrote:
| I'm building a claw / vibe coding platform that's business safe
| at https://housecat.com and am also finding all the old Unix
| tricks working as well as ever...
|
| - user and home directory for data
|
| - crontab for scheduled jobs
|
| - cgi for serving user space apps
|
| - rsync for backups
|
| We even rediscovered email patches but with agent to agent help
| making and applying them.
|
| It's simpler for us to operate and the agent to figure out.
| tietjens wrote:
| This is what dev.exe is great for, and it comes with Pi and its
| own coding agent Shelley preloaded. Also it's incredibly fast and
| you can easily access the VMs from your phone.
| robbomacrae wrote:
| OrcaBot does this with the VM but whereas the author mentions the
| risk of GitHub keys being leaked, OrcaBot uses a key broker to
| ensure the LLM doesn't have access to any keys. It even works on
| the API keys to the LLMs themselves.
| https://orcabot.com/blog#breaking-the-lethal-trifecta
| mirekrusin wrote:
| ...and proxy your llm traffic with your own per session tokens -
| if it leaks, it doesn't matter, not a real token.
| andai wrote:
| My other Mac mini is the cloud ;)
| saidnooneever wrote:
| bsd is super easy for this kind of setup tbh. Sylve or Bastille
| is amazing for it. 1 liner jails setups etc. its real quick and
| efficient. depending on flavor u can also use pledge/unveil or
| capsicum or whatever to lock things down even more.
| ArchieScrivener wrote:
| The fact that Claude can and does access files outside the PWD
| while asking for sudo to do things constantly seems to be a
| recipe for Anthropic scanning your system without your knowledge
| and saving that for 5 years if you decided to 'help improve
| Claude'.
|
| No, 'safety oriented' lab has a clause like that which can't be
| revoked historically. Anthropic, like the majority of 'don't be
| evil' firms is apart of the great masquerade.
| teekert wrote:
| Some weeks ago I opened Zeditor, it asks me if I want AI, I say
| yes, a sidebar opens I ask said LLM: What can you see? It does
| some `ls`'s, it sees my .ssh folder and priv keys. I turned it
| off. Now I run Claude code in a container with just pwd mounted
| to it.
|
| The whole experience was a bit jarring. When it knows I use
| nix, the the thing can easily `nix-shell -p nmap` its way into
| learning a lot more about my entire network than I am
| comfortable with. I think I'll edit the Containerfile further
| to also make Claude Code a user that can't install anything.
|
| It's really like some "agent" (yeah I know, but I mean really
| an external person) takes control of your computer, with the
| same privileges as you. Idk why I had to see this happen in
| front of my eyes to fully realize this.
|
| Of course every computer program has these rights, and you have
| to trust any of these devs...
| anthk wrote:
| That's what happens with propietary software. No sane person
| -for work if your dumb $BOSS makes in mandatory- should be
| using that outside of a Guix/Nix env with really constrained
| settings.
|
| At home I have no propietary software at all modulo some
| original GBC ROMs I dumped to play with emulators, but that
| is not my 'daily computing' usage but an act of nostalgia.
| PunchyHamster wrote:
| > The whole experience was a bit jarring. When it knows I use
| nix, the the thing can easily `nix-shell -p nmap` its way
| into learning a lot more about my entire network than I am
| comfortable with. I think I'll edit the Containerfile further
| to also make Claude Code a user that can't install anything.
|
| Note that putting it in container changes jack shit, if it
| still has network access, it can scan your network anyway,
| and it needs access to install language deps and such to "do
| its work"
|
| It's a security nightmare.
| arcanemachiner wrote:
| Every goddamn time with this type of dogshit advice.
|
| Perfect is the enemy of good.
|
| Don't just rawdog a coding agent because a perfectly viable
| solution (containers) takes an hour or two of work to set
| up.
|
| There's a world of difference between "it can scan your
| network" and "I just uploaded my private SSH keys to the
| cloud".
| simoncion wrote:
| > Don't just rawdog a coding agent because a perfectly
| viable solution (containers) takes an hour or two of work
| to set up.
|
| Setting up a separate unprivileged Linux user account
| takes all of like a minute. Assuming that the $HOME for
| your daily-driver account isn't world-readable, [0] that
| gets you the majority of the isolation that
| containerization provides and doesn't expose you to any
| bugs in the containerization management daemon (or the
| containerization code, itself) that may still be present
| even after all these years.
|
| These things are usually TUIs or CLIs, so you don't need
| to bother with giving them xauth access or whatever the
| Wayland equivalents for that are.
|
| [0] If it is, you might consider fixing that
| _immediately_.
| arcanemachiner wrote:
| See, I like this. "Create a new user account" is much
| better advice than "don't use a container".
|
| My problem with the latter advice is that I know for a
| fact that people will read it, then continue to use
| absolutely no protection whasoever.
|
| I have also wanted to use a simple file permission
| system, but I started with a container and I can't be
| troubled to switch yet.
| simoncion wrote:
| > Note that putting it in container changes jack shit, if
| it still has network access, it can scan your network
| anyway...
|
| That's why VLANs are nice, as is requiring your container
| system (or VM or whatever) to attach its vNICs to a VLAN-
| tagged bridge on the host rather than the untagged
| interface that your trusted software uses. If the only
| thing that the container can hit on your LAN is your
| router, and your router refuses to forward traffic from
| that untrusted VLAN to anywhere other than the internet,
| then that cuts off another avenue for intelligence
| gathering.
|
| That all assumes that you can't exploit the container
| daemon to get root, of course.
| kwar13 wrote:
| Exactly my worry, so I've bubblewrapped it on my computer.
| https://kaveh.page/blog/claude-code-sandbox
| zenoprax wrote:
| Great balance of simplicity and functionality. I'll be
| adapting this for VSCode+Cline. Thanks for sharing.
| hk1337 wrote:
| It does but AFAIK it always asks me if I want to allow it
| unless it has it saved that permission was already given.
| Borealid wrote:
| I don't understand why I keep seeing posts like this, but nobody
| appears to know that DevContainers exist.
|
| In a Jetbrains IDE, for example, you check a devcontainer.json
| file into your repository. This file describes how to build a
| Docker image (or points to a Dockerfile you already have). When
| you open up a project, the IDE builds the Docker image,
| automatically installs a language-server backend into it, and
| launches a remote frontend connected to that container (which may
| run on the same or a different machine from where the frontend
| runs).
|
| If you do anything with an AI agent, that thing happens inside
| the remote container where the project code files are. If you
| compile anything, or run anything, that happens in the container
| too. The project directory itself is synced back to your local
| system but your home directory (and all its credentials) are off-
| limits to things inside the container.
|
| It's actually easier to do this than to not, since it provides
| reusable developer tooling that can be shared among all team
| members, and gives you consistent dependency versions used for
| local compilation/profiling/debugging/whatever.
|
| DevContainers are supported by a number of IDEs including VSCode.
|
| You should be using them for non-vibe projects. You should
| DEFINITELY be using them for vibe projects.
| AlexCoventry wrote:
| Yeah, it's easy to vibecode and review a docker sandbox, too.
| If you run containers with --runtime=runsc
| --cap-drop=ALL --security-opt no-new-privileges:true
|
| it's pretty tight. That's how I use coding agents, FWIW.
| arcanemachiner wrote:
| The main Claude Code GitHub repo even has a Devcontainer
| config:
|
| https://github.com/anthropics/claude-code
|
| It's a great starting point, and can be customized as needed.
| With the devcontainer CLI, you can even use it from a terminal,
| no GUI/IDE required.
| xnorswap wrote:
| Is there a guide on getting it working with a devcontainer on
| the command line?
| arcanemachiner wrote:
| Yes, I summarized the process in another comment recently:
|
| https://news.ycombinator.com/item?id=47546014
|
| That should be enough to get you going. It can be
| customized to your heart's content.
| mr_mitm wrote:
| Has anyone figured out a good way to use (neo)vim with
| devcontainers?
| Oxodao wrote:
| haven't tried it but amitds1997/remote-nvim.nvim
|
| I need something like that though that's one of the thing
| that pains me the most while trying to use vim/nvim for dev
| datsci_est_2015 wrote:
| I personally just use Vim directly in a dedicated development
| VM that I SSH into. I can always spin up a new one if
| something goes astray
| mr_mitm wrote:
| I'd prefer containers, because they are more light weight
| and I'm not too concerned about kernel exploits or other
| sandbox escapes. Configuring a container per project brings
| me right back to something like devcontainer. But I haven't
| figured out a good way to incorporate that into my vim/tmux
| workflow.
| datsci_est_2015 wrote:
| Hmm, maybe I misunderstood the point of the original
| comment. I thought the OP was suggesting using containers
| to isolate resources for development vs personal
| computing, for which I use a VM. But VMs don't play
| nicely with IDEs (hence devcontainers).
| Izkata wrote:
| I use vim with docker compose all the time: Set up the
| compose file to bind-mount the repo inside the container, so
| you can edit files freely outside it, and add a convenience
| "make shell" that gets you inside the container for running
| commands (basically just "docker compose exec foo bash").
|
| It sounds like if you make devcontainers point at an existing
| Dockerfile it should be easy to make these work together, so
| you and teammates both use the same configuration. I haven't
| used devcontainers though.
| hk1337 wrote:
| I love JetBrains and they've gotten better with using
| devcontainers but they're still kind of flaky at times. I love
| using devcontainer too, just wanted to note that.
|
| I found cloning the repo when creating the devcontainer works
| best in JetBrains for some reason and I hard code the workspace
| directory so it's consistent between JetBrains and vscode
| faangguyindia wrote:
| I used to use sealtbelts for sandbox, i found it consumes way
| more tokens when sandboxed.
|
| Now, i run YOLO and haven't had any issue and my subscription
| lasts much longer with less token consumption!
| semanticc wrote:
| How/why did it consume more tokens?
| faangguyindia wrote:
| Well, thing is I ask it doesn't things where sandbox fails.
|
| And then it has to bypass sandbox to run those command with
| elevated permission.
|
| This double tripe boosts token usage.
|
| I don't think average developer workflow can be really
| limited to a workspace. You'll need commands which touch
| your system or require more privilege
| amluto wrote:
| Keep in mind that VSCode's own security story is beyond poor.
| Even if the container runtime perfectly contains the container,
| VSCode itself is a hole you could drive a truck through.
| VadimPR wrote:
| I've been doing something similar by letting Claude run in a
| Virtualbox VM. It's easy to use, no issues with observability,
| and the attack & damage surface is far less of an issue.
| nickdothutton wrote:
| I use a separate user account per project on my local machine
| (not in sudoers), which I ssh to, and also runs tmux. If I need
| claude code in windows, then I run a VM. The performance and
| (in)convenience cost of this to me is minimal. I started working
| this way in order to limit the "blast radius" when claude went on
| a dependency binge within a project.
| flux3125 wrote:
| I remember someone on HN once saying they treat LLM agents like
| human coworkers, security-wise, and that stuck with me.
|
| You don't give your GH keys, email credentials and ssh keys to a
| coworker. They have their own accounts with scoped permissions.
| Need them to read an email? Forward it. Need them to work on a
| repo? Add them as a contributor and enforce the same branch
| policies you would for any human.
|
| There are still risks, but they're similar to delegating work to
| humans, so it's up to you how much access and trust to give.
| hrimfaxi wrote:
| I think the issue is that people see them as agents of
| themselves with the authority to act on their behalf, much like
| a personal assistant, rather than a coworker.
| Faaak wrote:
| > I SSH into that server with key-forwarding
|
| Almost back to point A then. If the server is compromised in some
| way, they can use (not copy) OP's keys and use them to clone
| repos/inject code/etc..
| jeffrallen wrote:
| Also, "ssh -A" is your friend. Keep your ssh key on your yubikey
| where you control it. Let Claude play on it's own VM and in its
| own clone of your repo. Only when you choose to add the -A, do
| you temporarily, for that one ssh connection, have the
| possibility to push Claude's work to your repo, where you can
| review it.
|
| Treat it as a colleague, making PRs that you review.
| jbergqvist wrote:
| This works well for vibecoding on a codebase in isolation, which
| to be fair is what the author is addressing. I don't think it
| solves the problems at the current frontier of agent use though,
| where you expose internal infrastructure via tools to make the
| agent maximally productive. How to do this safely is still
| unsolved
| mettamage wrote:
| I mean this question unironically: how do you do it with
| interns?
| jbergqvist wrote:
| Limit access to whatever their project requires. The
| difference is that human interns have some common sense and
| won't suddenly be hijacked by a hidden message they stumble
| upon while searching the web, instructing them to exfiltrate
| a bunch of proprietary data. It is surprisingly easy to get
| an agent to do that though
| kusokurae wrote:
| Why not just not vibecode? Safer methods of injecting
| recreational narcotics, such madness.
| Uptrenda wrote:
| Apparently using SSH is some leet hacker thing according to this
| OP. Lmao...
| petcat wrote:
| People seem to come up with all manner of complicated setups with
| virtual machines or docker or whatever.
|
| All you need is a separate limited user account on your computer.
| Multi-user Unix-y systems were designed for this kind of thing
| for decades.
|
| My entire development environment is literally just "sudo".
| DaedalusII wrote:
| your kernel is not isolate and if you accidentally run the
| wrong command in sudo you will nuke your computer lol
|
| or just have a linux vps and ssh in for $5 a month
| petcat wrote:
| > if you accidentally run the wrong command in sudo
|
| I'm not seeing your point. Are you saying that I shouldn't
| use sudo because I might accidentally "run the wrong
| command"?
|
| I know all the commands that I run and what they do.
|
| > your kernel is not isolate
|
| Am I more afraid of an npm package exploiting a zero day
| kernel vulnerability on my mac? Or just stealing my AWS keys
| and installing a crypto miner? Sudo suits my threat model
| just fine.
|
| My m3 MacBook pro is a million times more powerful dev
| machine than a cheap $5 vps. Why would I waste my time with
| that.
| DaedalusII wrote:
| yes you right, i assume you using claude code which can in
| fact accidentally run the wrong command
|
| https://www.reddit.com/r/ClaudeAI/comments/1n1moqy/how_did_
| c...
|
| https://www.reddit.com/r/ClaudeCode/comments/1sa3fx8/claude
| _...
|
| https://old.reddit.com/r/ClaudeAI/comments/1jfidvb/claude_t
| r...
| petcat wrote:
| My Claude runs as a limited user account, which I invoke
| using sudo.
|
| Claude can run whatever commands it wants and the only
| harm it can do is nuke its own home directory. That's the
| whole point.
| indigodaddy wrote:
| They weren't getting that sudo was just your mechanism
| for changing user.
| secondcoming wrote:
| The advantage of VMs is that you can nuke them and be done with
| it if you need to.
|
| I use my personal laptop for $WORK and everything work related
| is done via the VM.
| petcat wrote:
| I can do that too by just rm-rf the agents home directory
| parliament32 wrote:
| Good checklist, but
|
| > The actual development happens on a rented server
|
| Why not Hyper-V or libvirt/KVM? VM escapes aren't a thing in real
| life (or VMs from hyperscalers wouldn't exist), so why deal with
| additional cost, latency, and third-party trust when you could
| just run it yourself?
___________________________________________________________________
(page generated 2026-04-08 23:01 UTC)