Installer Prompts

install-binary.sh copies the unprivileged CLI (sevorix) to ~/.local/bin, then works through a sequence of interactive [Y/n] prompts, each of which explains itself before asking. Below is what each decision buys you and what declining costs — in the order you will be asked.

1. sevsh into a root-owned directory

sevsh is installed to /usr/local/lib/sevorix/sevsh as root:root 0755, with a PATH-visible symlink at /usr/local/bin/sevsh, and its SHA-256 recorded alongside it.

It is deliberately not placed in ~/.local/bin. A root launcher bind-mounts sevsh over /bin/bash for the agent it is constraining, so a copy in a directory that agent can write to would let the guarded party replace the guard. The launcher checks three things before mounting, and fails closed on any of them: that sevsh and every directory above it are root-owned and not group- or other-writable; that its SHA-256 matches the recorded digest; and that the file it hashed is the same inode it mounts (it holds the binary open on a descriptor throughout, so the path cannot be swapped in between).

The digest is recorded from the installed bytes on every install rather than baked in at build time, so a legitimate upgrade replaces the binary and its digest together and keeps passing.

Declining: shell interception is unavailable, and the agent launcher will refuse to start a session rather than launch one it cannot verify.

2. The eBPF daemon, and how it gets its privilege

eBPF tracing is not available in current releases

Current Sevorix Pro release bundles ship the eBPF daemon but not the eBPF kernel bytecode it loads. The installer says so — eBPF kernel bytecode not present in this bundle — eBPF monitoring will be unavailable — and continues. On a bundle install today, eBPF syscall tracing is unavailable whichever way you answer the prompts below, and so is the Advanced (BPF LSM) enforcement tier. Syscall enforcement runs at the seccomp-based Standard tier, which is fully functional and unaffected.

The eBPF daemon runs as root, so it goes to /usr/local/lib/sevorix/ for the same reason sevsh does. There are up to three prompts:

• Install the daemon to /usr/local/lib/sevorix/ (root-owned, verified the same way as sevsh).
• Grant Linux capabilities — setcap cap_bpf,cap_perfmon,cap_net_admin,cap_sys_admin+ep on the daemon, so it can load eBPF programs without being root at runtime. Prefer this.
• A passwordless sudoers rule for the daemon, so Sevorix can launch it without a password prompt. The installer refuses to write the rule at all unless the target path is verified root-owned and non-user-writable, along with every directory above it. This check is not a formality: sudo runs whatever file is at the path it was given, so a rule naming a path under $HOME would be a local root escalation.

If an older install left the daemon or a sudoers rule pointing into your home directory, the installer removes them first.

Declining: eBPF tracing is unavailable; the Standard tier still applies.

3. The cgroup helper

Installs /usr/local/bin/sevorix-cgroup-helper and optionally a passwordless sudoers rule for it. This is what lets Sevorix freeze, unfreeze and kill an agent's whole process tree by cgroup.

Declining: sevorix session freeze/kill cannot contain a session, and — more consequentially — Yellow Lane reviews cannot suspend the agent while you decide. Under the default intervention.containment: "required", flagged actions are then blocked rather than reviewed. See human-in-the-loop review.

4. The agent launcher

Installs /usr/local/bin/sevorix-agent-launcher (plus an optional passwordless sudoers rule). This is the privileged launcher that wraps an agent binary — Claude Code, Codex, OpenClaw — in a mount namespace, binding sevsh over /bin/bash and /bin/sh so the agent's shell commands are intercepted even when it invokes /bin/bash by absolute path. It also runs the agent's own process through sevsh's network-namespace sandbox.

5. The agent-wrap helper

Installs /usr/local/bin/sevorix-agent-wrap, the helper that places a launched agent's entire process tree into a sevorix-managed cgroup: it creates /sys/fs/cgroup/sevorix/agent-<uuid>, enrolls itself so the agent inherits the cgroup by forking, registers it with the daemon, and tears it down when the agent exits. The agent launcher refuses to launch anything without it.

If you are upgrading from an older install, you will also be offered removal of the superseded sevorix-claude-launcher and its sudoers rule (/etc/sudoers.d/sevorix-claude).

6. Unprivileged user namespaces (a system-wide change)

This one changes your kernel configuration, not just Sevorix

The prompt sets kernel.apparmor_restrict_unprivileged_userns=0, persisted to /etc/sysctl.d/60-sevorix-userns.conf and applied immediately. That disables an Ubuntu 24.04+ AppArmor hardening feature system-wide, for every process on the machine — not only for Sevorix.

sevsh's network sandbox uses unprivileged user namespaces. Declining is a supported choice: sevsh still works, but falls back to a weaker sandbox. Weigh that against removing a kernel hardening feature from the whole host, and note that --yes and --force accept this prompt along with all the others. On a machine where unprivileged user namespaces are already enabled, you will not be asked.

7. Default policies and roles from Sevorix Hub

Downloads the canonical default policy set (default-policies@1.0.0, default-roles@1.0.0) from the public Hub registry, and — if ~/.sevorix/settings.json does not exist yet — activates the default role in it. Requires internet access. If you already have configuration in ~/.sevorix, this step is skipped and your files are left alone.

The installer states a disclaimer here, and it is worth repeating: the default policies and roles provide minimal safeguards only. They are a starting point, not a security posture. Review them against your actual use case — see Policy Format — before treating the install as complete.

Declining: you start with no policies. A session with no role configured blocks all traffic, so this is a safe default in the fail-closed direction, but it is not a usable one until you write policies of your own.

8. TLS interception CA

Without TLS interception, an HTTPS CONNECT is an opaque byte pipe: outbound requests can still be seen at the connection level, but Inbound policies have nothing to read. Startup logs a warning if inbound policies are loaded in that configuration.

TLS interception is off by default, and its CA certificate is generated the first time Sevorix starts with it enabled — so on a fresh install there is nothing to trust yet, and the installer only prints how to turn it on. To enable it:

1. Add { "tls_mitm": { "enabled": true } } to ~/.sevorix/settings.json.
2. Start Sevorix once, so the CA is generated at ~/.sevorix/ca/ca.crt.
3. Re-run ./install-binary.sh. It now offers to add the CA to the system trust store — after which every program on the machine that uses that store will accept certificates the CA issues.

Manage the CA afterwards with sevorix ca print | path | regenerate.

9. Clean up installation files

Finally, the installer offers to delete the extracted bundle directory and the downloaded archive and checksum. It only does so when the directory is recognisably a Sevorix release bundle.

Next

Log in, start the daemon, and verify enforcement.