Zenus is a natural language system shell for Linux. It translates user intent into validated system operations — managing files, processes, services, packages, git repositories, network, and browser automation.
Why classic confinement is required:
Zenus operates as a system shell and requires the same level of access as a traditional shell script or CLI tool. Specifically:
Filesystem access: unrestricted read/write across the entire filesystem (e.g. organizing downloads, reading logs, editing configs outside $HOME)
Process management: spawn, inspect, and kill arbitrary processes (including system services)
Package management: invoke apt, dnf, pacman to install/remove packages
Service control: start/stop/restart systemd services
Git operations: operate on repositories anywhere on the filesystem
Strict or devmode confinement cannot satisfy these requirements because they restrict filesystem access to $HOME and snap-specific paths, and block execution of arbitrary system binaries — which is fundamentally incompatible with a system operations layer.
I understand that strict confinement is generally preferred over classic. I’ve tried the existing interfaces to make the snap to work under strict confinement.
Your package needs to fit into one of the supported categories listed there and must not touch any of the ones listed in unsupported to actually be considered for classic confinement at all …
This is clearly one of the unsupported use cases …
(* 3rd party installer snaps (eg, for native packages, appimages, flatpaks, snaps, etc))
Thanks for the review. You’re right to flag that. That “package management” was a poor choice of words on my part. Zenus is actually a natural language shell (I think it falls better under “terminal emulators, multiplexers and shells”), not a package installer. Like bash or zsh, it needs classic confinement because it executes arbitrary user commands across the filesystem, manages processes, controls services, and runs any binary the user requests. When a user says “install vim”, Zenus constructs and runs apt install vim on their behalf, the same as typing it in a terminal. Zenus itself does not package, distribute, or install native packages; it is the shell layer that orchestrates whatever the user intends. I’d like to revise my justification accordingly, but I’m not sure if I can edit original description.
I don’t think zenus clearly fit in any of the supported categories. Even in that case, classic confinement is a sensitive matter that is reserved for very well-known applications. As of now, I could not find evidences that zenus meets this criteria
