### Checklist <!-- Please test the latest versions, that will remove the possibility that you see a bug that is fixed in a newer version. --> - [X] I'm using the latest version of the extension (Run `glab --version`) - Extension version: _Put your extension version here_ - [X] Operating system and version: Ubuntu Linux 24.10 - [X] Gitlab.com or self-managed instance? gitlab.com - [X] GitLab version (if self-managed) glab 1.56.0 (6f8bb1f5) (Use the `version` endpoint, like this: gitlab.my-company.com/api/v4/version) - [X] I have performed `glab auth status` to check for authentication issues - [X] Run the command in debug mode (like `DEBUG=true glab mr list`) and attach any useful output ### Summary <!-- Summarize the bug encountered concisely --> When using the Snapcraft store version of Gitlab CLI, it is not allowed to access certain files under `/etc`, however, it is able to detect their presence. This causes it to try to access `/etc/gitconfig` which fails with permission denied and prevents normal functionality of the program as it exits due to unreadable configuration files. The workaround is to move that config file out of the way on the host system. The full session is seen here: ``` $ GITLAB_HOST=gitlab.com DEBUG=true glab repo clone gitlab-org/cli [git remote -v] 2025/04/28 00:48:37 [Args: gitlab-org/cli] 2025/04/28 00:48:37 [GitFlags: ] 2025/04/28 00:48:37 [Dir: ] [git clone git@gitlab.com:gitlab-org/cli.git] warning: unable to access '/etc/gitconfig': Permission denied warning: unable to access '/etc/gitconfig': Permission denied fatal: unknown error occurred while reading the configuration files ERROR: exit status 128 ``` Less severe, but a similar error is seen with using the SSH protocol on clone after removing the config file. This is not as critical as regular `git` can be used instead. ``` $ GITLAB_HOST=gitlab.com DEBUG=true glab repo clone gitlab-org/cli [git remote -v] [git config --get-regexp ^remote\..*\.glab-resolved$] 2025/04/28 01:03:35 [Args: gitlab-org/cli] 2025/04/28 01:03:35 [GitFlags: ] 2025/04/28 01:03:35 [Dir: ] [git clone git@gitlab.com:gitlab-org/cli.git] Cloning into 'cli'... warning: templates not found in /usr/share/git-core/templates fatal: cannot exec 'ssh': Permission denied fatal: unable to fork ERROR: exit status 128 ``` ### Environment <!-- on POSIX system (Linux, MacOS), run bash -c 'printf -- "- OS: %s\n- SHELL: %s\n- TERM: %s\n- GLAB: %s" "$(uname -srm)" "$SHELL" "$TERM" "$(glab --version)"' and replace the following section with the result. If you use non-POSIX system, fill in the section manually: - OS: Your operating system including version and architecture (Windows 11 - AMD64, MacOS Sonoma - ARM64) - SHELL: Your shell (bash, fish, zsh, ...) - TERM: Your terminal emulator (Kitty, Xterm2..) - GLAB: result of running `glab --version` (glab version 1.32.0 (2023-08-18)) --> - OS: Linux 6.11.0-21-generic x86_64 - SHELL: /bin/bash - TERM: tmux - GLAB: glab 1.56.0 (6f8bb1f5) <!-- Please include any other information that you believe might be relevant in debugging. For example, you may include a shell framework like oh-my-zsh or other customizations like editing the prompt (PS1, PS2, and others). --> Other: ### Steps to reproduce <!-- How one can reproduce the issue - this is very important --> Create an empty config file if one doesn't exist: ``` touch /etc/gitconfig ``` Run any CLI command that talks to the API: ``` git issue list ``` ### What is the current _bug_ behavior? It <!-- What actually happens --> ### What is the expected _correct_ behavior? <!-- What you should see instead --> ``` warning: unable to access '/etc/gitconfig': Permission denied warning: unable to access '/etc/gitconfig': Permission denied fatal: unknown error occurred while reading the configuration files ERROR: exit status 128 ``` ### Relevant logs and/or screenshots Valid command output. <!--- Paste the activity log from your command line --> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem --> The snap permissions should be modified to allow access to `/etc/gitconfig` or failure to read it should be non-fatal.