[FEATURE] Process Isolation: Run Claude Code as a separate user for enforceable tool restrictions

Resolved 💬 4 comments Opened Mar 31, 2026 by sean-escendant Closed May 30, 2026

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

Problem

Claude Code runs as the invoking user's shell session, inheriting full access to all tools, binaries, and permissions available to that user. This means any tool restrictions (e.g., "never use xcodebuild directly, use MCP tools instead") are enforced only by prompt instructions — which the agent can and does ignore, even when the same correction has been given across multiple sessions.

There is no mechanism to enforce hard boundaries on what CLI tools or filesystem paths Claude Code can access. The agent can always fall back to calling any binary on $PATH or reading/writing any file the user owns.

Expected behavior

Users should be able to enforce tool restrictions at the OS level, not just via prompt instructions. For example:

  • Restrict $PATH so only approved binaries are available
  • Use unix file permissions to prevent access to specific tools (e.g., xcodebuild)
  • Limit filesystem read/write access to specific directories
  • Prevent execution of certain commands entirely

Proposed Solution

Run the Claude Code agent process as a separate OS user (e.g., _claude or configurable) rather than inheriting the invoking user's identity. This would allow users to:

  1. Control $PATH and available binaries for the agent user
  2. Use standard unix permissions / ACLs to restrict file and tool access
  3. Use sudoers or similar to grant specific elevated permissions only when needed
  4. Audit agent actions separately from user actions in system logs

This follows the principle of least privilege — the agent should only have access to the tools and files it actually needs, enforced by the OS rather than by self-compliance.

Alternative Solutions

  • Prompt-based restrictions: Current approach. Unreliable — the agent has been corrected multiple times across sessions for the same violation and still doesn't comply consistently.
  • Sandbox profiles (macOS): Could work but are complex to configure and not cross-platform.
  • Container/namespace isolation: Heavier-weight but would provide strong boundaries on Linux.

Priority

High - Significant impact on productivity

Feature Category

File operations

Use Case Example

_No response_

Additional Context

This isn't just about convenience — it's a security concern. An agent running with full user permissions could accidentally (or via prompt injection) execute destructive commands, access sensitive files, or interact with services it shouldn't. OS-level isolation would provide defense in depth regardless of how well the agent follows instructions.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗