Persist authentication state in the "GitHub Pull Requests and Issues" VS Code extension

Help
1

I have been using NixOS & Home Manager for a couple of weeks now, and I am working on my configuration almost every day.

I’m using the VS Code extension GitHub Pull Requests and Issues, which requires the user to authenticate to GitHub.

The extension works fine, I can authenticate to GitHub and manage issues and PRs of the repo I’m currently in. The problem is that I don’t understand how to preserve the authentication state after a reboot.

I guess I need to use a secret management tool like sops-nix, but I dont know how to tell this VS Code extension (or VS Code in general?) where to pick this credential. From what I read in its FAQ section, this extension uses OAuth (OAuth 2.0 I guess) to manage the authentication flow, but the actual access token is stored by VS Code in some kind of KeyChain.

I’m also using the GitHub CLI (gh), which is less problematic in this regard. Since this application looks for a GITHUB_TOKEN environment variable, we can create a shell script that reads the secret (using sops-nix) and assigns the unencrypted value to GITHUB_TOKEN. For example, I created these two small wrappers around gh that have only the minimum set of permissions required to manage GitHub issues and workflows, respectively.

Wrapper 1: can only manage GitHub issues

{
  config,
  pkgs,
  ...
}:
# Usage:
# ghi list
# ghi create -a @me -l enhancement -t "My issue title"
# ghi status
# ghi view --web 15
let
  gh = "${pkgs.gh}/bin/gh";
in
  pkgs.writeShellScriptBin "ghi" ''
    export GITHUB_TOKEN=$(cat ${config.sops.secrets.github_token_workflow_developer.path})

    exec ${gh} issue "$@"
  ''

Wrapper 2: can only manage GitHub workflows

{
  config,
  pkgs,
  ...
}:
# Wrap the GitHub CLI in an environment containing a GITHUB_TOKEN that has only
# the minimum set of permissions required to manage GitHub workflows.
# Usage: ghw list
# See: gh workflow --help
let
  gh = "${pkgs.gh}/bin/gh";
in
  pkgs.writeShellScriptBin "ghw" ''
    export GITHUB_TOKEN=$(cat ${config.sops.secrets.github_token_workflow_developer.path})

    exec ${gh} workflow "$@"
  ''

My question is: can I adopt a similar approach for the GitHub Pull Requests and Issues VS Code extension?

Note: here is the initialize method of the CredentialStore class of the GitHub Pull Requests and Issues VS Code extension.

2

While it was possible in this VS Code extension to set a GitHub personal access token, I don’t think that any extension (GitHub Pull Requests and Issues, GitHub Actions, GitHub Copilot) allows us to do it.

As far as I know, the only way to persist the authentication state for these VS Code extensions is to use a keyring. In fact, if we try to click the Sign in to GitHub button and we don’t have a keyring daemon running, we receive this error:

You’re running in a GNOME environment but the OS keyring is not available for encryption. Ensure you have gnome-keyring or another libsecret compatible implementation installed and running.

In my case, I set this in my user config:

services.gnome-keyring.enable = true;

This piece of configuration installs this systemd user service, but does not automatically unlock the keyring at login. If you want to unlock your keyring automatically, you need to use a PAM module or a similar method to provide the passphrase to the keyring daemon (see here and here for details).

You can start the GNOME Keyring daemon using this command:

systemctl --user start gnome-keyring.service