Alright, let's get this started. We've seen a few threads popping up about running Claude Code on shared infrastructure, and the consensus seems to be that it's powerful but the permission model can be a bit of a minefield if not set up correctly from the start. I want to outline a practical, defense-in-depth approach we've been using internally for our team's development server.
The core principle here is to treat the Claude Code session as a *user* on the system, with explicit, limited permissions, not as an all-powerful root or as your own personal account. The goal is to allow it to function as a useful coding assistant while creating clear boundaries around what it can and cannot access or modify. This involves three layers: system user/group permissions, a restricted shell environment, and careful management of the context you provide it (like the project directory).
First, create a dedicated system user and group. We'll call it `claude-code` for this example. The key is to add your human developers to the `claude-code` group, and then set up shared project directories with group ownership and the `setgid` bit so that new files inherit the group.
```bash
sudo adduser --system --group claude-code
sudo usermod -a -G claude-code devuser1
sudo usermod -a -G claude-code devuser2
mkdir /projects/team-alpha
sudo chown root:claude-code /projects/team-alpha
sudo chmod 2770 /projects/team-alpha # The '2' sets the setgid bit
```
Second, when you start your Claude Code session, you're launching a shell *as that user*. Never run it from your own logged-in session. Use `sudo -u claude-code` to drop privileges immediately. You can further restrict the shell's capabilities by setting a limited `$PATH` and potentially using a restricted shell wrapper that prevents `cd` commands outside of allowed project directories.
The final, crucial layer is the context you give Claude Code itself. When you point it at a repository, you are effectively granting it read access to everything in that directory tree. Be mindful of any secrets or configuration files that might be in that tree. A good practice is to have a clean, committed project state in the directory you open, not your live production configs.
This approach isn't about being paranoid, it's about establishing clear, maintainable guardrails. It ensures that a well-intentioned but overreaching suggestion from the AI, or a potential injection via context, can't easily affect other users' projects or critical system files. What other layers or specific tools are folks here using to harden their setups?
Ah, the inevitable overengineering. So now we're creating service accounts and chroot jails for a glorified text editor with a chatbot inside it.
I get the theory, I really do. But have you actually tried giving Claude Code a stripped-down shell? In my experience, the moment it can't run `pip` or `npm` because of some cage you built, it becomes useless. It starts hallucinating package names or writing scripts that fail silently because they can't touch the filesystem.
Why not just run it in a disposable container? Spin up a pod with the project directory bind-mounted, let it have its little sandboxed universe, then throw the whole thing away when the session ends. All this user/group wrangling feels like building a permanent moat for a temporary guest.
KISS