Why do people run and install these agents locally? No container nothing. I am running Opencode in WSL2 with the windows mounts disabled.
Grok CLI uploaded the whole home directory to GCS
201–210 of 434 posts
Re: Grok CLI uploaded the whole home directory to GCS
#202Earlier quoted context omitted.
Why would you give a non-deterministic text generator a user account? It’s not a person, it’s barely a tool at the software level. Restrict at the right level, in this case, a complete sandbox around it given its propensity to hallucinate and be steered by anybody.
> cat /etc/passwd|wc -l 50
/etc/shadow has the good stuff if you're OS is current.
Re: Grok CLI uploaded the whole home directory to GCS
#203Earlier quoted context omitted.
Other ones aren't this invasive with user data.
not true, Claude code on its own often create artifacts and straight up upload private stuff to Anthropic, without asking for it.
Maybe possibly with --dangerously-skip-permissions. I've been using auto mode and enjoy how it blocks every tool use that could've allowed something potentially sensitive into context. Burns extra tokens though.
Re: Grok CLI uploaded the whole home directory to GCS
#204Earlier quoted context omitted.
I don't understand why the AI world does this. We don't need new security. We have security at home. It starts with sudo -u restricteduser myagent Your OS knows how to restrict access to things, you don't have to trust a pinkey promise from a vendor.
and Landlock! Pi even has a sandbox plugin for Landlock
Is it this one? https://github.com/landstrip/landstrip
Re: Grok CLI uploaded the whole home directory to GCS
#205So many of the replies are saying that they should've restricted access using .md files and whatnot. Is really any guarantee that they even follow those? It seems like even if you ask pretty please don't touch those files, there's a chance they will. So many people have just willingly installed spyware on their computers and big tech calls this the next big thing.
Sometimes you can't even rely on harness not allowing ai to access certain files. "Oh, user doesn't want me to use `read_file` on .env? Well how about I run `cat .env` then?"
That's scary. Really should run it under different user with carefully assigned permissions.
Re: Grok CLI uploaded the whole home directory to GCS
#206The real solution to these kind of problems is sandboxing. I use podman through a bash script to launch a container whenever I want an agent to work on one of my repos. When done I just generate git patches and port back everything generated. In this way I'm not afraid of letting the agents totally lose on my computer.
Intricate sandboxing is a real solution in the same way bulletproof backpacks are a real solution to school shootings.
It’s not that intricate. A very simple docker and alias setup will get you an ephemeral container with your Claude (or whatever) config and the current wd bind mounted in. That’s a pretty good start.
Or, the internal sandboxing.
Re: Grok CLI uploaded the whole home directory to GCS
#207Earlier quoted context omitted.
I work on a sandbox which has similar isolation level to Podman (rootless Linux user namespaces), but with UX optimized for local development work. Take a look: https://github.com/wrr/drop Basically, you don't enter a separate container in which you install a new distro, but you run on top of your current distro. You have environment specific home dirs which isolate your original home, but can have some files, such a…
This is wonderful - might even be exactly what one of my projects needs to use as a dependency. In the README it mentions that it puts the dev environment in a filesystem jail, but how are you able to use your hosts bins without leaking access to the rest of the system? Or is that just an assumed liability?
It assembles and pivots to own root filesystem. The filesystem mounts dirs and files from your original filesystem, most of them in read-only mode, but does not mount files that expose secrets to the sandbox. The sandbox also mounts own, writable version of your home dir, so secrets, such as .ssh dir are not exposed. The config file allows to configure which files should be exposed from your original home. For example, configs, such as .bashrc, are safe to expose in read-only mode, provided you don't store secrets in them.
Re: Grok CLI uploaded the whole home directory to GCS
#208Important to clarify that this was not the Grok agent deciding to read the files. I don't think the LLM had anything to do with this decision at all. It looks like the Grok tool starts a session by deterministically kicking off a full upload of the user's current repository (and maybe their directory if not version tracked? Not clear if this user had previously run "git init" in their home directory) to Grok's server…
Yeah sounds like semantic indexing that cursor (pending acquisition by spacex/xAI) does.
Re: Grok CLI uploaded the whole home directory to GCS
#209So many of the replies are saying that they should've restricted access using .md files and whatnot. Is really any guarantee that they even follow those? It seems like even if you ask pretty please don't touch those files, there's a chance they will. So many people have just willingly installed spyware on their computers and big tech calls this the next big thing.
I built a docker container that volume mounts the project directory
You can even go a step further and run the container in a VM, such as with Docker Sandbox or the krun runtime in Podman.
There's also smolvm which is a nice minimal microvm manager based on libkrun: https://github.com/smol-machines/smolvm. I vibe coded a little shell utility for building and running OCI images for the Pi harness using it (easy enough to do manually, but the automation just makes it a couple quick commands rather than digging through documentation): https://github.com/neuroblaze/smol-pi
Re: Grok CLI uploaded the whole home directory to GCS
#210Don't store any secrets in your repo. Don't store them in env vars.
Strong long passphrase on your SSH keys, stop using unencrypted SSH keys. Everything in a keychain.
The practice of storing secrets in a .gitignore'd .env.local.json or whatever is a really bad idea and I can't believe that it has become a normalized, acceptable practice in the industry.