Request for classic confinement: antigravity-ide-snap

store-requests classic-confinement
1

  • name: antigravity-ide-snap

  • description: Snap packaging of Google’s Antigravity IDE — an agent-first coding environment built on the Electron/VS Code platform. Lets developers plan, build, debug and ship software with autonomous AI agents working directly in their codebase. Note that this is different from antigravity (published by Ivo Janski). antigravity is a pure agentic platform, this is another product that is similar to VSCode + Copilot (but with Gemini).

  • snapcraft: https://github.com/tingdahl/antigravity-ide-snap/blob/main/snap/snapcraft.yaml

  • upstream: PRIVATE (proprietary binary distributed by Google at https://antigravity.google). The snap code is under https://github.com/tingdahl/antigravity-ide-snap

  • upstream-relation: Independent third-party packager. I have no affiliation with Google; I repackage the official upstream Linux tarball that Google publishes. I am willing to drop this if there is an official snap.

  • supported-category: IDE

  • reasoning: Antigravity IDE is a general-purpose development environment that must drive the host’s developer toolchain to be useful. Strict confinement is fundamentally insufficient for the following reasons:

    1. Host toolchain execution — the IDE invokes host binaries such as git, ssh, gpg, gpgconf, compilers, language runtimes, and build tools that the developer has installed. There is no interface that permits running arbitrary host executables.

    2. SSH and GPG authentication — cloning repositories and signing commits requires access to ~/.ssh/config, ~/.gnupg/, and agent sockets under $XDG_RUNTIME_DIR. These paths cannot be fully enumerated for personal-files/system-files interfaces, and those interfaces additionally require per-revision manual review without a snap declaration.

    3. Real home directory — under strict confinement $HOME is remapped to ~/snap/…/current, making existing project files, dotfiles, and credentials in the user’s real home inaccessible to child processes.

    4. Integrated terminal — the IDE spawns the user’s login shell and arbitrary host commands; there is no interface for this.

    I verified these limitations by running the snap under strict confinement with snappy-debug and attempting to use home, ssh-keys, gpg-keys, and personal-files interfaces. Git operations, GPG signing, and shell execution all failed. The same application packaged as a raw tarball (the upstream distribution method) works correctly on the same host, confirming the failures are confinement-imposed. Classic confinement is the established precedent for this category: code (VS Code), intellij-idea-community, intellij-idea-ultimate, goland, clion, and sublime-text all use classic for identical reasons.

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.

Note that snappy-debug can be used to identify possible required interfaces. See https://snapcraft.io/docs/debug-snaps for more information.

2

This request has been added to the queue for review by the @reviewers team.

3

Hello @tingdahl,

The technical reasons for classic are clear and reasonable here, and this falls under the newly supported category “agents/assistants” as well as the ‘IDE’ category listed. This request effectively mirrors the classic request for antigravity, and as such I would encourage you to follow the same steps and attempt to transfer the snap to the ubuntu-snaps account if possible before classic is granted. @zyga do you agree that would be appropriate for this case, and would you be able to help with the process?

Thank you!