Running Claude Code as yourself …

The default setup for running Claude Code on your own computer is as follows:

In this setup, you are running claude as yourself.

Permissions and Risk

When you run claude, it runs as a process with your own permissions - and so does any sub-process that claude runs during development.

In the worst case, an AI might decide, for whatever reason, to do something destructive to your computer.

Claude Code has a system of permissions and controls designed to prevent AI “going rogue”.

But there is not just the risk of the claude application doing something bad – there is also the risk of the application being developed doing something bad when you run it.

There is no straightforward way for Claude Code itself to absolutely prevent an application it is developing from doing something it shouldn’t.

You can try telling it not to write an application that does something bad, but you are now in the fuzzy territory of trying to absolutely control what an AI does by telling it not to do things.

The “aicoder” user.

What you really want is some way for Claude Code to run as a process which doesn’t have all of your own personal permissions.

One approach might be to define a separate user on your computer with a suitable set of permissions, and log in as that user to run Claude Code.

We could call this user aicoder.

aicoder has the permissions required to run Claude Code and run local dev versions of the application being developed:

On a system where you have local admin rights, such as a typical personal computer, it’s easy enough to create such a user.

Executing commands as aicoder

So let us assume that you have created such an aicoder user.

How to do you use it?

You could just log in separately as aicoder.

But then you wouldn’t be able to do all the things you normally do logged in as yourself.

Even when developing code using Claude Code running as aicoder, there might still be some commands and applications that you want to use as yourself.

You don’t want to have a whole second computer just for aicoder to use, and you don’t even want to be switching between different interactive login sessions.

What you actually want is the ability to directly run commands as aicoder.

Exactly how you would do this can depend on your operating system. I’m on a Mac running MacOS.

On a Mac, the command to run a command as another user such as aicoder is:

By default this command will ask you to enter your password, which you don’t want to be doing all the time. The solution to that problem is to define an entry in /etc/sudoers.d which allows your personal user to run su -u aicoder * commands via passwordless sudo.

Sharing files

If you’re pure vibe-coding, then you might have the aicoder user do all the development in project directories within its own home directory.

But no matter how hard you vibe, there will come a time when you want to read and maybe even write some of the source code.

In principle you could have your copy of a project in a directory that you own and aicoder could have a copy of the project in its own directory and the two of you could push and pull to and from a shared remote git repository.

But this adds a certain amount of friction to the development process.

You will actually get stuff done quicker if you and aicoder can freely edit the same files.

One way of sharing files is to define a group, let us call it aidev, to which both yourself and aicoder belong, such that:

Wrapper scripts

Once the required passwordless sudo has been set up for sudo -u aicoder, you can create a wrapper script aicoder-run, for example in $HOME/bin, which runs a specified command as the aicoder user.

The main content of this script is:

sudo -u aicoder -E -H "$@"

Using the -E and -H flags means that the command is being run with whatever environment and path settings you yourself depend on when you run commands of any kind.

(One consequence of using -E is that you should not use your normal shell environment as a place to put secrets such as API tokens.)

The most important application to run with a wrapper is Claude Code itself (actually installed as a script claude).

This has it’s own special requirements, so it make sense to create a separate script $HOME/bin/aicoder-claude which runs Claude Code as aicoder.

However you also want to use the aicoder-run wrapper script as a way to run local dev versions of the application being developed within your own IDE (which you are running as yourself). This can generally be done by configuring the “run” and “debug” configurations for a project. (aicoder inside Claude Code doesn’t need to know about this, because it will be running any dev commands as itself.)

Keychains

On a Mac, secrets such as Claude AI credentials are stored in your keychain. In order to run Claude Code, your keychain needs to be open - this is something that happens when you log in.

But when you start a process as aicoder using sudo -u, aicoder’s keychain is not open.

Also aicoder cannot access your keychain (and you don’t want that to happen).

So the script aicoder-claude needs to open aicoder’s keychain in the script before starting.

To do that you need to have access to aicoders keychain password, and the proper way to manage that is to have aicoder’s keychain password be a value stored in your keychain.

So aicoder-claude needs to retrieve aicoder’ keychain password from your keychain (which will be open because you are interactively logged in), and then use that to open aicoder’s keychain within the command to sudo -u aicoder.

Claude updates

One feature of Claude Code is that it always does an update check when it starts.

But, if you installed Claude Code, and if aicoder is running Claude Code, the aicoder user does not have the required permissions to do the update.

The solution to this is to have the script that runs Claude Code as aicoder run claude update (as yourself), before running Claude Code as aicoder.

aicoder-setup

To fully set up the aicoder user as described is quite a lot of work.

So I have created a project https://github.com/pdorrell/aicoder-setup which contains some Ansible scripts to do the required setup on a Mac.

To use it, check the repository out locally, read README.md (which various warnings and caveats), and then execute the specified make task (or tasks if you want to do it one step at a time).

(I have written scripts that work on a Mac, because as it happens, a Mac is the only local dev computer that I own.)