AUR packages cannot be built as root; run mise as a non-root

Error message

AUR packages cannot be built as root; run mise as a non-root user

What it means

AUR helpers must build packages with makepkg, which refuses to run as root; AurManager::install() therefore bails when `crate::system::sudo::is_root()` is true and the run is not a dry-run. This happens before elevation checks and helper invocation, because building AUR packages as root is unsupported and dangerous.

Source

Thrown at src/system/packages/aur.rs:194

    }

    async fn install(&self, pkgs: &[PackageRequest], opts: &InstallOpts) -> Result<()> {
        if let Some(pkg) = pkgs.iter().find(|pkg| pkg.version.is_some()) {
            bail!("AUR helpers cannot install a pinned version ('{pkg}')");
        }
        let helper = self
            .helper()
            .ok_or_else(|| eyre::eyre!(self.unavailable_reason()))?;
        let args = install_args(pkgs, opts);
        let command = std::iter::once(helper.to_string())
            .chain(args.iter().cloned())
            .collect::<Vec<_>>();
        if opts.dry_run {
            miseprintln!("{}", shell_words::join(command));
            return Ok(());
        }
        if crate::system::sudo::is_root() {
            bail!("AUR packages cannot be built as root; run mise as a non-root user");
        }
        crate::system::sudo::ensure_elevation_available(&shell_words::join(&command))?;
        let mut runner = CmdLineRunner::new(helper);
        for arg in &args {
            runner = runner.arg(arg);
        }
        runner.raw(true).execute()
    }

    async fn upgrade(&self, pkgs: &[PackageRequest], opts: &InstallOpts) -> Result<()> {
        let pkgs = resolve_foreign_packages(pkgs)
            .await?
            .into_iter()
            .filter_map(|package| {
                package.installed_name.map(|name| PackageRequest {
                    name,
                    version: None,
                    tap_url: None,

View on GitHub (pinned to afd2eddd3a)

Solutions

Run mise as a normal (non-root) user; mise will invoke the helper, which elevates only the pacman transaction via sudo.
In containers/CI, create a build user (`useradd -m builder && su builder`) and run `mise install` as that user, giving it passwordless sudo for pacman if needed.
Avoid `sudo mise install` / `sudo -i` workflows for AUR packages entirely; use mise's own elevation handling instead.
If only probing, use --dry-run, which returns before the root check.

Example fix

// before: root shell in CI
# mise install aur:yay
Error: AUR packages cannot be built as root; run mise as a non-root user

// after
# useradd -m builder && sudo -u builder mise install aur:yay

Defensive patterns

Strategy: validation

Validate before calling

// check before running mise AUR installs in scripts/CI
import { userInfo } from 'node:os';
if (userInfo().uid === 0) {
  throw new Error('Refusing to run mise AUR installs as root; switch to a non-root user with sudo access');
}

Try / catch

try {
  await mise.install('aur:yay');
} catch (err) {
  if (err instanceof Error && err.message.includes('cannot be built as root')) {
    // drop privileges and retry as the build user
    await run('sudo', ['-u', 'builder', 'mise', 'install', 'aur:yay']);
  } else throw err;
}

Prevention

Never run `sudo mise install/upgrade` for aur: packages; mise handles elevation itself.
In containers/CI that default to root, create and switch to an unprivileged build user before installing AUR tools.
Make the root check part of your provisioning scripts: bail early if `id -u` is 0 and AUR tools are in the tool list.
Give the build user targeted passwordless sudo (pacman only) so the helper can complete its transaction.

When it happens

Trigger: Running mise as root (root shell, sudo mise, sudo su, container/CI defaulting to root) and executing `mise install`/`mise upgrade` for any `aur:` package (non-dry-run) — the install path checks is_root() and bails.

Common situations: CI containers running as root, SSH-ing directly as root on an Arch box, bootstrapping dotfiles with `sudo mise`, or a provisioning script that runs everything under sudo.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/38de5d60ba30be4c. Report an issue: GitHub.