name: clawdius
description: Clawdius is a Claude-native code editor: a fork of Visual Studio Code (code-oss) with the Claude Code CLI and agent built in. It is the same Electron application shell as Microsoft’s official code snap and behaves as a full desktop IDE. Snap summary: “Claude-native code editing.” Note for the reviewer: the linked snapcraft.yaml uses a build-time name substitution (name: @@NAME@@), which our packaging renders to clawdius at build time; the published snap name is clawdius.
snapcraft: clawdius/resources/linux/snap/snapcraft.yaml at main · chapmanjw/clawdius · GitHub
upstream: github . com/chapmanjw/clawdius (github . com/microsoft/vscode)
upstream-relation: The snap publisher chapmanjw (John Chapman) is the author and maintainer of the Clawdius fork. There is no separate third-party upstream between the publisher and the packaged software; the publisher is the upstream author. Clawdius derives from code-oss (microsoft/vscode) but is maintained as a distinct product.
supported-category: IDEs
reasoning: Clawdius is an IDE, which is a supported classic-confinement category, and it is the same category under which Microsoft’s official code, code-insiders, and vscode snaps ship. code is the archetype snap in the IDEs category; Clawdius is a code-oss fork with the same host-access needs, so the classic rationale that applies to code applies here for the same technical reasons. The modern approved IDE request processing (forum topic 47746) is the reasoning template followed below.
The IDE cannot function under strict confinement plus the existing interfaces because its core behaviors require open-ended host access that no interface can enumerate ahead of time. Mapping onto the policy’s qualifying criteria from topic 1460:
-
Running arbitrary, user-configurable developer commands. Clawdius executes toolchains found on the user’s
PATH– compilers, debuggers, linters, formatters, test runners, and language servers – whose identities and paths are unknown at build time and vary per project. This maps directly onto the policy criterion “running arbitrary command (esp if user-configurable such as a developer tool).” -
Host filesystem access outside the snap runtime and outside
$HOME. Thehomeandremovable-mediainterfaces confine access to the user’s home and mounted media. They cannot grant read/write to arbitrary locations such as/usr,/opt,/etc, or repositories checked out outside$HOME. This maps onto “access to files on the host outside the snap’s runtime (eg, /usr).” (The in-home case is covered byhome; the irreducible requirement is the out-of-home case, which no interface provides.) -
Bundled Claude Code CLI and agent. Clawdius ships the Claude Code CLI and agent, which spawns further host processes (including
gitand other developer tools), reads and writes the user’s~/.claudeconfiguration, and drives whatever binaries the user’s workflow references. These subprocesses are arbitrary and user-configurable and cannot be expressed as a fixed interface plug set. -
Third-party VS Code extensions. Clawdius installs and runs third-party extensions, which themselves invoke arbitrary host binaries, so the set of executed programs is unbounded and defined by the user, not the publisher.
-
Inherited shell environment. Integrated terminals and tasks inherit the user’s full shell environment (env vars, dotfiles, credential helpers) so they behave like a native install.
What I tried under strict confinement: I attempted strict confinement with the existing interfaces (home, removable-media, personal-files, system-files, and the process/spawn-related plugs). They cannot provide unrestricted filesystem read/write outside the home directory, nor arbitrary user-configured command execution across the host – the two irreducible requirements of a general-purpose IDE. snappy-debug confirms denials on host paths outside the snap runtime (eg /usr, /opt) and on execution of host binaries not covered by an interface. These are the same requirements that led the official code/code-insiders/vscode snaps to ship as classic.
For completeness: like the official VS Code snap, Clawdius launches Electron with --no-sandbox (verified in the packaging, apps section). This is parity with the code snap’s behavior and a consequence of the classic-mode host access model, not itself the justification for classic; the justification is items 1-5 above.
Confirmations:
- 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.