[FEATURE] Support running claude code as a different, more restricted user

[gwk]

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

As a security-conscious user, I am distrustful of giving Claude Code carte blanche access to my dev environment. There have been many public stories of inappropriate behavior by coding agents and there are currently multiple open bugs regarding Claude bypassing its own permission system.

I have recently attempted to embrace the tool in earnest by setting up a separate agent user/group on my Mac (macOS 15.7.1) with the intention of explicitly setting "agent" unix group ownership and permissions for the files that I want Claude to interact with. Obviously this requires some fiddling, but with a couple of scripts to recursively set permissions that part is proving straightforward.

However getting the Claude CLI app to run as another user on macOS was a challenge. I have it working now but I wonder if the dev team might be interested in making this somewhat less difficult.

What follows is a mini dump of my recent experience. In any case, thanks for reading!

Resilience to permission errors

When claude encounters permissions errors, it tends to barf node exceptions instead of reporting nice errors. This is probably the most actionable and could be a separate bug issue.

ZSH compinit warning wrecks the terminal layout

It appears that as part of this process (either the sudo -i shell launch or claude itself) the .zshrc file gets run. If compinit issues a warning prompt about insecure permissions, then the whole claude UI ends up broken because the cursor is several lines out of place. I suspect that this will be a problem with any sort of interactive "[y\n]" prompt during initialization.

Note that once I started running sudo with -i this problem did resolve.

Keychain

The biggest challenge so far has been that Claude uses the macOS keychain to store its OAuth credentials. I could switch to using an API key, which can be provided to Claude via other means, but I would much prefer to be a monthly subscriber.

After a lot of fiddling (and asking claude for help!) I did the following:

• create a new "agent" user using dscl commands
• created a new login keychain for the user using security create-keychain -P login.keychain-db.
• got confused about semantics of keychain when running commands under sudo -u agent ….
• finally managed to copy my 'Claude Code-credentials' keychain item into agent's login keychain.

The key thing to understand is that plain sudo -u agent does not unlock that user's login keychain, but sudo -iu agent does. Note also that claude suggests that launchctl asuser is the "proper macOS way".

At this point I think I could write a script to automatically transfer the keychain item between users but it is more difficult than should be required of a new user.

Proposed Solution

This might not seem like a straightforward request. At a high level, I'm asking the dev team to consider whether they think this is a worthwhile strategy to support, and then try it to see the sharp edges for themselves.

The elevator pitch is that using plain ls -l, chmod -R, etc you can enforce agent access.

I would be happy to provide more polished scripts and documentation if anyone is seriously interested.

Alternative Solutions

I have read that some other tools like Cursor are using sandbox-exec which is macOS only, supposedly deprecated by Apple, and has its own configuration language. Or containers, which is a whole other world of tooling and configuration.

Feature Category

Configuration and settings

Use Case Example

If this approach is of interest to anyone, I can share the exact scripts that I have so far. At the moment they have only been tested on a single setup, and I probably need to do a clean run of setting up the user and keychain again before I would call them "working".

[github-actions[bot]]

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

[gwk]

This is still an issue!