Give Claude Code Unrestricted Root (via 1Password) — Dangerous, Test‑Only

• Security

Use at Your Own Risk

This is dangerous. The pattern below lets a coding agent like Claude Code (or similar) obtain sudo credentials non‑interactively. Only consider this in isolated environments (throwaway VMs, local sandboxes) where you fully accept the risk. Do not do this on production systems. Prefer safer alternatives listed later.

Why Do This?

Some agents or automation flows (e.g., Claude Code) need to run commands that require root. Permission prompts block progress in non‑interactive modes. A 1Password service account can gate access to the password and provide audit logs, while the agent retrieves it on demand.

Prerequisites

  • 1Password account with permission to create a service account
  • 1Password CLI installed (docs)
  • Isolated test environment; you accept full risk

Steps

  1. Create a dedicated vault for automation (example: dev). Avoid using your personal vault with service accounts.
  2. In that vault, create a new password item named sudo:
    Title
    sudo
    Username
    root
    Password
    Your root password
  3. Create a 1Password service account scoped only to the dev vault (read‑only). See: Service accounts guide.
  4. Save the service account token in your shell environment (e.g., in a local .env): 
    OP_SERVICE_ACCOUNT_TOKEN="...your_token..."
  5. Retrieve the sudo password via the 1Password CLI when needed: 
    export OP_SERVICE_ACCOUNT_TOKEN
op read "op://dev/sudo/password"

You can embed these instructions into your agent’s runbook (for example, a CLAUDE.md note) describing how to request elevated actions. Again: test environments only.

Risks, Audit, and Hygiene

  • Exposure: Any process with the service account token can read items from the scoped vault.
  • Scope strictly: Create a dedicated vault with only the minimum items; grant read‑only to the service account.
  • Rotate and revoke: Treat the token as a secret. Rotate frequently; revoke when done.
  • Use audit logs: 1Password logs access; review them when testing this flow.

Safer Alternatives (Prefer These)

  • Limit with sudoers: Grant NOPASSWD for a small, explicit command allowlist instead of full root password.
  • Ephemeral machines: Run in disposable VMs/containers; destroy after each session.
  • Session escalation only: Prompt a human to approve specific commands; avoid storing passwords altogether.
  • Non‑root strategies: Use capabilities, file ACLs, or service users with least privilege.

Summary

This pattern enables unattended root in constrained scenarios by letting an agent fetch credentials through a tightly scoped 1Password service account. It is powerful and risky. Prefer safer alternatives; if you proceed, isolate, scope, audit, and clean up.