Enable classic confinement for the gh snap

The gh snap gives GitHub CLI users a bad experience, as evident by the number of issues that are first reported in our repo and then determined to have been caused by snap packaging/runtime:
https://github.com/cli/cli/issues?q=is%3Aissue+snap
https://github.com/cli/cli/discussions?discussions_q=snap

This often costs us (GitHub CLI maintainers) time to triage and asses these issues. Sometimes it's not evident that the user has installed gh via snap, as they don't always include that information in their report. Typical issues reported are "permission denied errors", git clone errors, filesystem errors, and other edge-case bugs that aren't present in our own builds of GitHub CLI, but are present in the gh snap.

I do not believe that these bugs are explicitly caused by your own repository, but I do think that snap (or, more generally, containerized or sandboxed packages) is an insufficient mechanism to distribute and run apps like ours. Installing an official gh binary locally on the system (either directly or from our debian package repo) is a vastly superior and stabler method to keep running gh without extra trouble, and yet when Ubuntu users type gh, they get suggested to install the snap, which sets them up for a bad experience:

$ gh

Command 'gh' not found, but can be installed with:

sudo snap install gh       # version 1.12.1-pre.0-15-gbf5b34d0, or
sudo apt  install gitsome  # version 0.8.0+ds-4

See 'snap info gh' for additional versions.

I do not know of ways to fix these issues, but I would much rather that the gh snap isn't featured so prominently, and the only way I can imagine fixing that is by unpublishing gh from the Snap store. An even more ideal solution would be so that nobody is allowed to publish a snap for GitHub CLI again, but I guess neither of us has that level of control over the Snap store.

Thank you for reading.

Ref. cli#328

Hey just curious how do I get back on the non snap version? I see the install instructions here: https://github.com/cli/cli/blob/v2.0.0/docs/install_linux.md but when I run
$ snap remove gh
and then those instructions I get
$ gh --version bash: /snap/bin/gh: No such file or directory
I assume I have the wrong directory for the bash alias. How do I fix that? What is the file for the normal install?

@woodsmanlucas

@woodsmanlucas You can run type gh in your shell to see what would be executed: a command, a shell function, or a shell alias.

After installing the Debian package, the path to it should be /usr/bin/gh, I think.

@mislav

hmm interesting @mislav I would prefer to get confirmation from https://github.com/orgs/snapcore/people before doing something as drastic as unpublishing.

Sure thing! I just wanted to make sure you're aware of the influx of issues we're seeing reported in our issue tracker due to Snap. 👍

Would snap clasic resolve some of these issues? Seems like getting around confinement would help a lot.

@jaron-l

@jaron-l "Classic" does sound like it would be a better confinement method for CLI tools such as ours. However, if users are required to explicitly opt into classic by means of --classic flag at install time, and if the default suggestion from Ubuntu when one types gh remains just sudo snap install gh (i.e. without the --classic flag), I think we'd still have a problem because I imagine the typical user not knowing that they are supposed to install in classic mode.

sudo snap install gh won't work if it's a --classic snap... you'd get an error message saying the --classic flag is required

sudo snap install gh won't work if it's a --classic snap... you'd get an error message saying the --classic flag is required

Can confirm this. "Classic" is the type of snap and the user gets prompted to add it if it's not there saying that they they need to add it if they know the risks. A good example of this is the vscode snap.

I use Ubuntu as my primary OS and I expect for many snaps to require classic, for them to fail without --classic and for me to retry with --classic. When I tried to use the snap gh it failed because it couldn't write to /etc. IMO the snap should not exist the way it is right now and agree with the original post.

Also agree here. The command doesn't work right and causes issues which seem to be gh's fault and not the snap.

Not an expert on snaps yet BUT to confirm what was said earlier, when this would be packages in the classic snap format the user must install with --classic and can NOT install it "wrongly". The first message would suggest it without --classic I think, but they would be reminded when trying that they need the switch.

I do think snap is actually a good way to distribute this. I installed the media player Clementine today and I needed to set a specific option to read and write from mounted drives. It had permission to my home directory by default. So even for the sandboxed snaps there are ways to get more permissions, but I think for this the classic package is probably the only thing that makes sense. Still because snap works on so many distros it is better than to maintain so many packages.

So my suggestion would be not to unpublish it, but to do a proper classic snap that has all the permissions and just acts like a normal binary from any other package manager that is distro specific.

Because of the tight integration into Ubuntu and derivates, it thinks it's amazing to have a message suggest an installation method for something that is outside the regular repos. That is FAR superior to having to add a PGP key, repo ... and install through apt ...

@mislav

So, @mislav, you guys can't build a proper snap and so you take your ball and go home? One of the links you provide as "evidence" of snap being insufficient is a thread on somebody using docker?

@mislav

@mislav Are you saying "remove gh from your machine and rest".
I tried to instal gh using sudo apt install gh
The machine returns E: Unable to locate package gh

@jonbirge

@jonbirge I admit that I wouldn't know how to build a better snap. My argument is that gh should never be packaged and distributed in any “containerized” format. From the Wikipedia page about snap:

Snaps are self-contained applications running in a sandbox with mediated access to the host system.

GitHub CLI, by design, should not be running in any kind of sandbox. It wants to have full access to the host system. It's true that some of the resources I've linked to are about Docker, not snap, but the argument is the same.

@ChrisNzoka GitHub CLI installation instructions for Debian/Ubuntu include information on how to add our own Debian package repository to your package sources. Without that, apt install gh will not work (or it will install the wrong thing).

@mislav

@mislav There are multiple ways for a snap to access the file system, some more safe than others, but all pretty easy. Both snap and docker are containerized, but unlike docker snap is designed to—-among other things—package CLI user tools whereas docker is aimed at server workloads, and so your statement is flat out wrong. Plenty of tools with the same requirement as yours work well as snaps, such as VS Code. Bottom line: if you don’t want somebody doing a poor job packaging your software do it right yourself. People want things like snap and flatpak because they are better than the old packaging formats.

Initial commit

@mislav

@mislav hey there. I'm a snapd developer and I'd love to help you guys out to make gh snap just prefect and working out of the box for everyone. Could we explore making gh use classic confinement as it was discussed above? What are the current blockers for this? Is it a process or a technical problem that's in the way?

There was some progress in #47 I think

Hmm this links to #47 that is closed that talks about a snapcrafters repo. A quick search on https://github.com/orgs/snapcrafters/repositories?q=gh finds nothing. Then there is https://github.com/casperdcl/cli but all I want is the user experience to be great:

zyga@x13:~$ snap info gh
name:      gh
summary:   The GitHub CLI
publisher: Casper (casper-dcl)
store-url: https://snapcraft.io/gh
contact:   https://github.com/casperdcl/cli/issues/new/choose
license:   MIT
description: |
  https://cli.github.com
  
  **`gh` - The GitHub CLI tool**
  
  `gh` is GitHub on the command line, and it's now available in beta. It brings pull requests,
  issues, and other GitHub concepts to
  the terminal next to where you are already working with `git` and your code.
  
  _Usage_
  
  - `gh pr [create, list, status, view, checkout, ...]`
  - `gh issue [create, list, status, view, ...]`
  - `gh [auth, browse, codespace, gist, org, project, release, repo, ...]`
  - `gh [cache, run, workflow, ...]`
  - `gh [alias, api, attestation, config, extension, gpg-key, label, preview, ruleset, search,
  secret, ssh-key, status, variable, ...]`
  - `gh help`
snap-id: RcphOHl3Jx7YP6wTXEJLdcGjnSTmGjNp
channels:
  latest/stable:    2.74.0-19-gea8fc856e 2025-06-09 (640) 43MB -
  latest/candidate: ↑                                          
  latest/beta:      ↑                                          
  latest/edge:      2.74.0-19-gea8fc856e 2025-06-09 (640) 43MB -

This is currently published with strict confinement but is fairly recent. Are the issues with classic confinement no longer relevant?

Could you try sudo snap install --classic gh --channel edge

100

Snap gh spôsobuje používateľom rozhrania GitHub CLI zlú skúsenosť, o čom svedčí počet problémov, ktoré sú najprv nahlásené v našom repozitári a potom sa zistilo, že boli spôsobené balením/runtime modulom snap: https://github.com/cli/cli/issues?q=is%3Aissue+snap https://github.com/cli/cli/discussions?discussions_q=snap

To nás (správcov GitHub CLI) často stojí čas na triedenie a posúdenie týchto problémov. Niekedy nie je zrejmé, že používateľ nainštaloval gh cez snap, pretože nie vždy uvedú túto informáciu vo svojom hlásení. Typické hlásené problémy sú chyby „permission denied“ (odmietnutie prístupu), chyby klonovania git, chyby súborového systému a ďalšie chyby na okraji prípadu, ktoré sa nevyskytujú v našich vlastných zostaveniach GitHub CLI, ale sú prítomné v gh snap.

Nemyslím si , že tieto chyby sú explicitne spôsobené vaším vlastným repozitárom, ale myslím si, že snap (alebo všeobecnejšie kontajnerizované alebo sandboxové balíčky) nie je dostatočný mechanizmus na distribúciu a spúšťanie aplikácií, ako je ten náš . Inštalácia oficiálneho binárneho súboru gh lokálne v systéme (buď priamo, alebo z nášho repozitára balíčkov Debian) je oveľa lepšia a stabilnejšia metóda na udržanie prevádzky gh bez ďalších problémov, a napriek tomu, keď používatelia Ubuntu zadajú gh, dostanú návrh na inštaláciu snapu, čo ich pripraví na zlú skúsenosť:
$ gh

Command 'gh' not found, but can be installed with:

sudo snap install gh       # version 1.12.1-pre.0-15-gbf5b34d0, or
sudo apt  install gitsome  # version 0.8.0+ds-4

See 'snap info gh' for additional versions.
Neviem, ako tieto problémy vyriešiť, ale oveľa radšej by som uprednostnil, keby sa snap gh nezobrazoval tak výrazne, a jediný spôsob, ako si viem predstaviť, že by som to mohol vyriešiť, je zrušiť publikovanie gh v obchode Snap. Ešte ideálnejším riešením by bolo, aby už nikto nemohol publikovať snap pre GitHub CLI, ale myslím, že ani jeden z nás nemá takú úroveň kontroly nad obchodom Snap.

Ďakujem za prečítanie.

Ref. [cli#328](#7 (comment)

sues/328)

The gh snap gives GitHub CLI users a bad experience, as evident by the number of issues that are first reported in our repo and then determined to have been caused by snap packaging/runtime: https://github.com/cli/cli/issues?q=is%3Aissue+snap https://github.com/cli/cli/discussions?discussions_q=snap

This often costs us (GitHub CLI maintainers) time to triage and asses these issues. Sometimes it's not evident that the user has installed gh via snap, as they don't always include that information in their report. Typical issues reported are "permission denied errors", git clone errors, filesystem errors, and other edge-case bugs that aren't present in our own builds of GitHub CLI, but are present in the gh snap.

I do not believe that these bugs are explicitly caused by your own repository, but I do think that snap (or, more generally, containerized or sandboxed packages) is an insufficient mechanism to distribute and run apps like ours. Installing an official gh binary locally on the system (either directly or from our debian package repo) is a vastly superior and stabler method to keep running gh without extra trouble, and yet when Ubuntu users type gh, they get suggested to install the snap, which sets them up for a bad experience:
$ gh

Command 'gh' not found, but can be installed with:

sudo snap install gh       # version 1.12.1-pre.0-15-gbf5b34d0, or
sudo apt  install gitsome  # version 0.8.0+ds-4

See 'snap info gh' for additional versions.
I do not know of ways to fix these issues, but I would much rather that the gh snap isn't featured so prominently, and the only way I can imagine fixing that is by unpublishing gh from the Snap store. An even more ideal solution would be so that nobody is allowed to publish a snap for GitHub CLI again, but I guess neither of us has that level of control over the Snap store.

Thank you for reading.

Ref. cli#328

Duplicate of #69

I think this is now done? b48244c

zyga@x13:~$ snap info gh
name: gh
summary: The GitHub CLI
publisher: Casper (casper-dcl)
store-url: https://snapcraft.io/gh
contact: https://github.com/casperdcl/cli/issues/new/choose
license: MIT
description: |
https://cli.github.com

gh - The GitHub CLI tool

gh is GitHub on the command line, and it's now available in beta. It brings pull requests,
issues, and other GitHub concepts to
the terminal next to where you are already working with git and your code.

Usage

gh pr [create, list, status, view, checkout, ...]
gh issue [create, list, status, view, ...]
gh [auth, browse, codespace, gist, org, project, release, repo, ...]
gh [cache, run, workflow, ...]
gh [alias, api, attestation, config, extension, gpg-key, label, preview, ruleset, search, secret, ssh-key, status, variable, ...]
gh help
snap-id: RcphOHl3Jx7YP6wTXEJLdcGjnSTmGjNp
channels:
latest/stable: 2.74.0-19-gea8fc856e 2025-06-09 (640) 43MB -
latest/candidate: ↑
latest/beta: ↑
latest/edge: 2.74.0-19-gea8fc856e 2025-06-09 (640) 43MB -### https://snapcraft.io/gh

Indeed

$ snap info gh --verbose | grep confinement
  confinement: classic

@casperdcl

~~Documentation has been amended at 1d9a43f~~ This is the same as #7 (comment), rebased 👍🏼

@casperdcl Do you think this issue can be closed?

Well given that this issue was renamed/repurposed from "unpublish" to "change to classic confinement" I suppose it can be closed as completed; yes.

Navigation Menu

Repository navigation

Enable classic confinement for the gh snap #7

31 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Enable classic confinement for the gh snap #7

Description

Activity

woodsmanlucas commented on Sep 9, 2021

mislav commented on Sep 9, 2021

casperdcl commented on Sep 14, 2021

mislav commented on Sep 15, 2021

jaron-l commented on Sep 27, 2021

mislav commented on Sep 28, 2021

casperdcl commented on Sep 28, 2021

jaron-l commented on Sep 28, 2021

charlesritchea commented on Nov 9, 2021

cardonator commented on Nov 10, 2021

nextgenthemes commented on Dec 1, 2021

jonbirge commented on Jan 28, 2022

ChrisNzoka commented on Feb 17, 2022

mislav commented on Feb 18, 2022

jonbirge commented on Feb 18, 2022

31 remaining items

zyga commented on Jun 7, 2025

casperdcl commented on Jun 9, 2025

zyga commented on Jun 9, 2025

casperdcl commented on Jun 9, 2025

emybk933-debug commented on Sep 4, 2025

patrron commented on Nov 7, 2025

phadungkiat627 commented on Nov 13, 2025

phadungkiat627 commented on Nov 13, 2025

astrojuanlu commented on Nov 13, 2025

ved130349-blip commented on Apr 28, 2026

astrojuanlu commented on Apr 28, 2026

astrojuanlu commented on Oct 13, 2026

casperdcl commented on Oct 13, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions