name: odysseus
description: Self-hosted AI workspace
snapcraft: odysseus-snap/snap/snapcraft.yaml at main · kenvandine/odysseus-snap · GitHub
upstream: GitHub - pewdiepie-archdaemon/odysseus: Self-hosted AI workspace. · GitHub
upstream-relation: I only maintain the snap packaging. I am not involved with the upstream project.
supported-category: agent/assistant that runs arbitrary user-directed code and needs to reach files and programs that aren’t known at build time (same bucket as shells and coding assistants).
reasoning:
odysseus runs a self-hosted web workspace: chat, document analysis, deep web research, image generation, speech-to-text, email, and MCP servers, backed by a bundled Python runtime. It works against the user’s own documents and tools, so the files and programs it reaches depend on how they set it up.
None of that is knowable when I build the snap, which is what makes strict confinement unworkable. There’s no interface (or set of them) that allows reading arbitrary user files and running arbitrary helper programs, and snappy-debug under strict just keeps surfacing new denials. So it’s published as classic.
On isolation: classic means the agent can do whatever the person running it can do. Because of that, the docs recommend installing and running it inside an LXD container rather than directly on the host. That keeps the broad access inside a boundary the user sets up themselves (throwaway filesystem, limited network, nothing reaching the rest of their data), while the agent can still use whatever tools and files it needs inside that container. Strict confinement would just break the agent and give weaker guarantees than containing it properly anyway.