* name: nexora-ai
* description: NexoraAI is a local-first, on-device AI development environment (an IDE): an Electron desktop app that helps developers scaffold, build, run and test web/app projects on their own machine, with all model inference running locally on the device. It edits the user’s project files and drives the user’s own installed development toolchain.
* snapcraft: Built with electron-builder; the snap configuration is the build.snap stanza of package.json: https://github.com/mutlukurt/NexoraAIEnvironment/blob/main/package.json (no standalone snapcraft.yaml; happy to share the generated one on request). For the classic build, confinement will be classic.
* upstream: https://github.com/mutlukurt/NexoraAIEnvironment (open-source, MIT)
* upstream-relation: I am the author and sole maintainer of the project, and the snap publisher.
* supported-category: IDEs
* reasoning:
NexoraAI is an IDE that orchestrates the user’s own development toolchain and workspaces. Two things are core to its function and cannot be provided by the strict interfaces:
-
It executes the user’s host-installed toolchain. To scaffold projects, install dependencies, run dev servers and run tests against the code the user is working on, it invokes the executables on the user’s own
$PATH—node,npm/pnpm/yarn,git,viteand similar. Under strict confinement the snap runs in a private mount namespace containing only the snap’s own runtime, so the user’s installed toolchain on the host is not reachable, and there is no interface that exposes the host$PATH/executables to the confined process. This is the user’s own toolchain being driven by the IDE — not a host-only dependency of the snap itself. -
It reads and writes the arbitrary project directories the user opens. Projects live anywhere the user chooses (e.g.
~/Desktop/<project>, external/removable media, other mount points), outside$SNAP_USER_DATA. Spawned toolchain processes also need the user’s real environment ($PATH, git config, globally-installed node/npm packages).
I have tried the strict interfaces (home, system-files, removable-media, process-control): they grant file access but do not allow executing the user’s host toolchain or exposing the host $PATH/environment to spawned processes, which is central to the app.
This is the same requirement that established IDEs rely on — e.g. the code (VS Code) snap, and the classic request for shiftide (an Electron AI code editor + terminal that runs the host git/node/python toolchain) which was granted on 2026-07-14. As noted by a reviewer on a prior IDE request: “As an IDE, it fits in a supported category and has an understood requirement for classic confinement.”
I understand that strict confinement is generally preferred over classic. I’ve tried the existing interfaces to make the snap work under strict confinement.
