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?