Working safely with an AI on the command line

An AI on the command line (Claude Code, for instance) runs real commands on your workstation. You should not run it under your own account, and even less under root. The good practice is to give it its own user account, without sudo, and to share a single directory with it through a common group. The AI can then only reach its home and that shared directory.

The scheme rests on three pieces: a user dedicated to the AI, a shared group, and a setgid directory.

1. Create an account dedicated to the AI

Create a normal user (here agent), with no login password and above all without adding it to the sudo group:

bash

adduser --disabled-password --gecos "" agent

Important

Never put this account in sudo. An AI without elevation rights cannot break the machine, it can only act in the directories you allow.

Logging in to the AI account

Since the account has no password, you log in with an SSH key. ssh-copy-id is of no use here (it would need a password to drop the key), so the public key is installed by hand.

You have to be root (the -o/-g options and chown to another user require it). Put your public key (the one of your workstation, YOUR_USER) into the AI account:

bash

install -d -o agent -g agent -m 700 ~agent/.ssh
cat /home/YOUR_USER/.ssh/id_ed25519.pub >> ~agent/.ssh/authorized_keys
chown agent:agent ~agent/.ssh/authorized_keys
chmod 600 ~agent/.ssh/authorized_keys

The connection then needs no password:

bash

ssh agent@localhost

To go faster, create a small ~/bin/agent wrapper:

~/bin/agent

#!/bin/bash
ssh agent@localhost

Make it executable (755):

bash

chmod 755 ~/bin/agent

To be able to start it by simply typing agent, the ~/bin directory must be in the PATH. Add this line at the end of your ~/.profile (or ~/.bashrc):

bash

export PATH="$HOME/bin:$PATH"

Reload the file (or open a new terminal) to apply it:

bash

source ~/.profile

You can now connect with a simple:

bash

agent

2. Create the shared group

This group is the common ground between you (the developer or the sysadmin) and the AI:

bash

addgroup equipe

3. Add the developer and the AI to the group

One command per member:

bash

adduser dev equipe
adduser agent equipe

Each user has to open a new session (or run newgrp equipe) for the group membership to take effect.

Check:

bash

getent group equipe

equipe:x:1200:dev,agent

4. Create the shared directory with the right permissions

The key point is the setgid bit (the s in the group permissions): every file or directory created inside automatically inherits the equipe group, whoever created it.

bash

mkdir /home/projet
chown root:equipe /home/projet
chmod 2770 /home/projet

2770 reads as:

• 2: setgid bit (group inheritance on new files);
• 770: the group has read, write and execute; other users have nothing.

Check, the s must appear in place of the group x:

bash

ls -ld /home/projet

drwxrws--- 2 root equipe 4096 juil. 24 10:00 /home/projet

5. Check the umask

Setgid passes on the right group, but not the group write permission: for files created in the shared directory to be editable by the whole group, they must be 664, so the umask must be 002. On Debian that is the default setting. Check:

bash

umask

It must answer 0002. If it does not, add umask 002 to the ~/.profile of the AI account.

Careful with cp -a

A file arriving normally in the directory (editor, touch, >, cp, cp -r) automatically gets the right group thanks to setgid. But cp -a (like rsync -a) includes --preserve=ownership: it restores the group of the source and ignores setgid. The copy can therefore land with a wrong group, out of reach of the other member.

To fix the group afterwards, without root rights, just recreate it in place with a cp -r to a temporary name, then replace the original:

bash

cp -r data data.tmp   # the copy inherits the setgid group (files AND directories)
rm -rf data
mv data.tmp data

cp -r does not preserve ownership: the copy takes the group of the directory (and the setgid bit on directories). The rm and the mv are allowed because the directory is group writable (with no sticky bit), even if the files do not belong to you.

Better still: avoid the problem at the source by not preserving ownership when copying (cp -r, cp -a --no-preserve=ownership, rsync -rlt).

6. Check the result

Logged in as agent (ssh agent@localhost), create a file in the shared directory: it must belong to the equipe group and be writable by the group.

bash

touch /home/projet/test.txt
ls -l /home/projet/test.txt

-rw-rw-r-- 1 agent equipe 0 juil. 24 10:05 /home/projet/test.txt

The group (equipe) does have rw: the developer will be able to edit this file, and the other way round.

Good practices

• No sudo for the AI account: it only works in its home and in the shared directory.
• One shared directory per project: do not share the whole home of the developer.
• Backup and versioning: keep the work under Git in the shared directory, so you can roll back easily.