WSL | Democratizing Data

How to Prevent gh CLI from Leaving a Plaintext Token on WSL2

Sun, 09 Aug 2026 13:18:00 -0700

On WSL2 without a working keyring, gh auth login falls back to storing the token in plaintext at ~/.config/gh/hosts.yml. Worse, the OAuth token GitHub CLI issues . covers this problem well.

This isn’t a theoretical risk. gh auth token shows up repeatedly as a credential-harvesting step in real npm supply chain attacks. Palo Alto Networks’ Unit 42 in the Mini Shai-Hulud campaign, where a malicious payload invoked Bun to run gh auth token alongside other credential-harvesting commands.

To work around it, I set up , a CLI that issues a GitHub App User Access Token and refreshes it every 8 hours. A recently added feature lets you set the backend to agent, which instead of relying on a keyring.

Here’s how I installed it, following .

Before you start

If you’ve ever run gh auth login on this WSL2 environment, a plaintext token is probably still sitting in ~/.config/gh/hosts.yml. Log out and invalidate it first.

gh auth status # check current state
gh auth logout

Once the logout succeeds, the file should be empty:

$ cat ~/.config/gh/hosts.yml
{}

Installation

I installed it via mise.

mise install ghtkn
mise use ghtkn

WSL2 environment prep: systemd + linger

First, confirm systemd=true is set in /etc/wsl.conf.

[boot]
systemd=true

Then run:

loginctl enable-linger "$USER"

Restart WSL2 from the Windows side for this to take effect.

wsl --shutdown

After restarting, confirm all of the following:

ps -p 1 -o comm=
# => systemd

loginctl show-user "$USER" --property=Linger
# => Linger=yes

ls -ld /run/user/1000
# => owned by {username}:{username} and present (if missing, ghtkn agent can't start,
# failing with `mkdir /run/user/1000: permission denied`)

If you run ghtkn agent start with the agent backend before linger is enabled, /run/user/1000 (XDG_RUNTIME_DIR) won’t exist yet, since systemd-logind never created it. You’ll hit this instead:

error="create the socket directory: mkdir /run/user/1000: permission denied"

Creating a GitHub App

Create a GitHub App and grab its client_id — you’ll need it for the config file.

I based mine on the URL from the author’s article:

Take the Client ID issued after creation and write it into the config file below.

Config file

Run ghtkn init to generate the config file, then fill in the GitHub App’s Client ID and pick a backend.

~/.config/ghtkn/ghtkn.yaml

apps:
 - name: suzuki-shunsuke/write # a name to identify this app; rename freely
 client_id: xxx # GitHub App Client ID

backend:
 type: agent

The default backend is the OS keyring, but WSL2 has rough edges there. Some people , but I went with the agent backend instead.

The agent backend gives you:

Tokens encrypted with AES-256-GCM and stored without a keyring
Refresh token support, so you skip the device-flow re-authentication every 8 hours (macOS/Linux only — avoid enabling this in environments where malware can easily escalate to root)

Initial authentication

To use the agent backend, start the agent first.

ghtkn agent start &
ghtkn agent unlock

On first run, it asks you to set a new passphrase (entered twice). Stash it in 1Password or similar so you don’t lose it.

ghtkn auth

This kicks off the device flow. , it no longer tries to open a browser in headless environments — on WSL2, you open the displayed URL yourself and enter the code.

If you run ghtkn auth with the agent backend before the agent is running, it fails with:

error="create a GitHub App User Access Token: begin the device flow on the agent: begin the device flow through the backend: the ghtkn agent is not running; run 'ghtkn agent start'"

Setting up as a systemd user service

To keep the agent running long-term on WSL2, register it as a systemd user service.

First, stop the manually-started agent, or it’ll conflict with the one systemd manages.

ghtkn agent stop

~/.config/systemd/user/ghtkn-agent.service

[Unit]
Description=ghtkn agent

[Service]
ExecStart=/home/aki/.local/share/mise/installs/ghtkn/latest/ghtkn agent start
Restart=on-failure

[Install]
WantedBy=default.target

Enable it:

systemctl --user daemon-reload
systemctl --user enable --now ghtkn-agent.service

Day-to-day operation: unlocking the agent

ghtkn agent unlock --enable-refresh

This turns on refresh tokens. Once enabled, the token renews automatically as long as WSL2 stays up.

I looked into feeding the passphrase in automatically via 1Password CLI’s op, but ghtkn blocks this . I’m treating that as intentional design and typing the passphrase by hand.

Wrapping the `gh` command

I added a shell function to ~/.zshrc so gh itself routes its token through ghtkn.

gh() {
 if [ "$1" = "auth" ]; then
 case "$2" in
 token)
 echo "[blocked] 'gh auth token' is disabled" >&2
 return 1
 ;;
 status)
 for arg in "$@"; do
 case "$arg" in
 --show-token|-t)
 echo "[blocked] 'gh auth status --show-token' is disabled" >&2
 return 1
 ;;
 esac
 done
 ;;
 esac
 fi
 ghtkn exec -- gh "$@"
}

ghtkn exec passes ghtkn’s short-lived token to the child process as an environment variable.

The function also blocks gh auth token and gh auth status --show-token, since both print the token in plaintext.

Check that it’s working:

$ gh auth status
github.com
 ✓ Logged in to github.com account chezou (GITHUB_TOKEN)
 - Active account: true
 - Git operations protocol: https
 - Token: ghu_************************************

A token starting with ghu_... confirms ghtkn issued it.

Integrating with mise

mise lets you set credential_command so .

mise settings set github.credential_command="$(mise which ghtkn) get -m 1h"

Confirm it:

$ mise token github
github.com: ghu_…(masked) (source: credential_command)

What’s still unhandled

pointed me to more gaps. I still need to check whether .

WSL2にghtknを設定してgh CLIがトークンをファイル平文保存するのを防ぐ

Sun, 09 Aug 2026 12:27:00 -0700

gh auth login はWSL2でkeyringが使えない場合、トークンを ~/.config/gh/hosts.yml に平文保存をしてしまう。また、GitHub CLIで生成されるOAuth tokenはトークンはである。この当たりはが詳しい。

これを回避するために、というCLIを導入した。ghtknはGitHub Appから8時間毎に更新されるUser Access Tokenを発行するCLIである。さらに、最近入った機能でバックエンドを agent にすることで、keyringに依存せずできる。

今回は、作者のを見ながらインストールをしたので、その方法をメモしておく。

はじめに

過去に一度でも gh auth login をWSL2環境でしていたら、 ~/.config/gh/hosts.yml に平文トークンが残っている。作業前にログアウトし、保存された平文トークンを無効化しておく。

gh auth status # 現状確認
gh auth logout

正常にログアウトされていれば空になる

$ cat ~/.config/gh/hosts.yml
{}

インストール

今回は mise 経由でインストールをした。

mise install ghtkn
mise use ghtkn

WSL2の環境設定準備: systemd + linger

まず、 /etc/wsl.conf で systemd=true が設定されていることを確認する。

[boot]
systemd=true

確認したら以下を実行する。

loginctl enable-linger "$USER"

その後、Windows側から一度WSL2を再起動して反映させる。

wsl --shutdown

再起動後、以下が正常に出力することを確認する。

ps -p 1 -o comm=
# => systemd

loginctl show-user "$USER" --property=Linger
# => Linger=yes

ls -ld /run/user/1000
# => {username}:{username} 所有で存在する(存在しないと `mkdir /run/user/1000: permission denied` でghtkn agentが起動できない)

lingerを有効にせずにagent backendで ghtkn agent startしようとすると、/run/user/1000(XDG_RUNTIME_DIR)がsystemd-logind経由で作られておらず、create the socket directory: mkdir /run/user/1000: permission deniedというエラーになる。

GitHub Appの作成

GitHub Appを作成し、client_idを取得する。これを設定ファイルに書けば良い。

今回は、作者の記事から以下のURLをベースに作成をした。

作成後に発行されるClient IDを次で設定する設定ファイルに書き込む。

設定ファイル

ghtkn init を実行して設定ファイルを生成し、そこにGitHub AppのClient IDと今回使うbackendの設定をする。

~/.config/ghtkn/ghtkn.yaml

apps:
 - name: suzuki-shunsuke/write # 識別用のapp名。適当に書き換える
 client_id: xxx # GitHub AppのClient ID

backend:
 type: agent

バックエンドはデフォルトはOS keyringだが、WSL2ではハマりどころがありそうだった（はいるにはいる）のでagentバックエンドを使うことにした。

agentバックエンドは以下の特徴がある。

トークンはAES-256-GCMで暗号化して保存（keyring不要）
refresh tokenに対応し、8時間毎のdevice flow再認証が不要になる（macOS/Linuxのみ対応。rootに用意に昇格できる環境では避けるべき）

初回認証

agent backendを使って初期設定するためには、先にagentを起動する必要がある。

ghtkn agent start &
ghtkn agent unlock

初回はパスフレーズを新規設定（2回入力）する必要がある。人間用に1Passwordにでも保存しておくと良い。

ghtkn auth

これを実行するとDevice Flowが開始される。ではheadless環境ではブラウザを開かなくなったため、WSL2では自分で表示されたURLを開いてコードを入力する。

なお、agent backendでagent未起動時にghtkn authを実行すると以下のエラーが出て失敗する。

error="create a GitHub App User Access Token: begin the device flow on the agent: begin the device flow through the backend: the ghtkn agent is not running; run 'ghtkn agent start'"

systemdユーザーサービス化

WSL2でagentを常駐させるために、systemdユーザーサービスとして登録する。

まず、この設定をする前に agentを停止する。そうしないと、systemdで管理するagentと競合する。

ghtkn agent stop

~/.config/systemd/user/ghtkn-agent.service

[Unit]
Description=ghtkn agent

[Service]
ExecStart=/home/aki/.local/share/mise/installs/ghtkn/latest/ghtkn agent start
Restart=on-failure

[Install]
WantedBy=default.target

以下のコマンドを実行して有効化する。

systemctl --user daemon-reload
systemctl --user enable --now ghtkn-agent.service

日常運用: agent unlock

ghtkn agent unlock --enable-refresh

を使うことで、refresh tokenするようになる。これを実行するとWSL2を落とさない限り自動更新する。

なお、1Password CLIの op 経由でパスフレーズを自動で入力できないか検討したが、ghtknので明示的に禁止されている。

設計思想として手動入力を前提にしていると受け入れた。

ghコマンドのラッパー化

gh コマンド事態もghtkn経由でトークンを渡すように、 ~/.zshrc にシェル関数を設定をした。

gh() {
 if [ "$1" = "auth" ]; then
 case "$2" in
 token)
 echo "[blocked] 'gh auth token' is disabled" >&2
 return 1
 ;;
 status)
 for arg in "$@"; do
 case "$arg" in
 --show-token|-t)
 echo "[blocked] 'gh auth status --show-token' is disabled" >&2
 return 1
 ;;
 esac
 done
 ;;
 esac
 fi
 ghtkn exec -- gh "$@"
}

ghtkn exec は ghtknが管理する短命トークンを環境変数として子プロセスに渡して実行する。

また、 gh auth token と gh auth status --show-token をされると平文でトークンが出るのでそれを防いでいる。

以下で動作確認ができる。

$ gh auth status
github.com
 ✓ Logged in to github.com account chezou (GITHUB_TOKEN)
 - Active account: true
 - Git operations protocol: https
 - Token: ghu_************************************

ghu_... で始まればghtkn経由のトークンを使っている。

miseとの連携

miseでは credential_command を設定することで。

mise settings set github.credential_command="$(mise which ghtkn) get -m 1h"

確認は以下のとおり。

$ mise token github
github.com: ghu_…(masked) (source: credential_command)

まだ対応していないこと

を読むと、まだ対応の余地がある点がいくつか残っているのに気づいた。特に、Claude Codeのセッション履歴にトークンが残る可能性は要検討。