Concurrent HEY CLI keyring probes repeatedly abort gnome-keyring-daemon 50.0

[tony-ho]

Description

Running HEY CLI through the Omarchy HEY bar plugin repeatedly causes
gnome-keyring-daemon 50.0 to abort while handling a Secret Service
OpenSession request.

The daemon has crashed 24 times during the current login session. The crashes
occur around the plugin's periodic refreshes and always have the same assertion
sequence and stack.

This appears related to #165, which notes that concurrent HEY CLI processes
currently probe keyring availability by writing and deleting the shared
hey::test item.

Environment

• HEY CLI: 1.2.1
  • Commit: 58c83f1e62f7542af04fbac343711f7fd643b576
  • Built: 2026-08-26
• OS: Omarchy / Arch Linux
• gnome-keyring: 1:50.0-1
• GLib: 2.88.3-1
• HEY integration: basecamp/omarchy-hey-plugin
• HEY CLI keyring dependency: github.com/zalando/go-keyring v0.2.8

The Omarchy plugin runs a long-lived hey watch process and short-lived commands
such as account, Imbox, Screener and authentication-status reads.

Observed behavior

gnome-keyring-daemon logs:

gkd_secret_service_get_pkcs11_session: assertion 'client' failed
plain_negotiate: assertion 'session' failed
gkd_secret_service_publish_dispatch: assertion 'client' failed
GLib: g_variant_get_type: assertion 'value != NULL' failed
GLib: g_variant_type_is_subtype_of: assertion 'g_variant_type_check (type)' failed
GLib: g_variant_get_type_string: assertion 'value != NULL' failed
GLib: g_variant_new: expected GVariant of type 'v' but received value has type '(null)'

It then exits with SIGABRT. Systemd restarts it automatically.

There were 24 identical crashes during one login session. Several occurred close
together, including:

2026-08-26 13:31:05
2026-08-26 13:31:40
2026-08-26 13:41:05
2026-08-26 14:11:05
2026-08-26 14:21:05

Later crashes continued with the same signature.

Symbolized backtrace

The important frames are:

#3  abort
#4  _g_log_abort
#9  g_variant_valist_new_nnp
#12 g_variant_new ("(@vo)")
#13 gkd_exported_service_complete_open_session
    output=0x0, result=0x0
    daemon/dbus/gkd-secrets-generated.c:3074
#14 service_method_open_session
    daemon/dbus/gkd-secret-service.c:441
#21 _gkd_exported_service_skeleton_handle_method_call
    interface_name="org.freedesktop.Secret.Service"
    method_name="OpenSession"
#28 main

The preceding assertions show that GNOME Keyring no longer had a registered
client when HEY's Secret Service session negotiation ran. Session negotiation
returned without setting output or result, after which the generated D-Bus
completion code attempted to construct a variant from the null values and GLib
aborted.

There was no OOM event and approximately 21 GiB of memory remained available.

Expected behavior

Concurrent HEY CLI processes should not race during keyring availability checks
or cause overlapping Secret Service client setup/teardown. Read-only HEY
operations should not mutate a shared keyring probe entry.

A keyring backend failure should fall back cleanly without destabilizing the
desktop keyring daemon.

Workaround

Running HEY with:

HEY_NO_KEYRING=1 hey ...

avoids Secret Service and uses:

~/.config/hey-cli/credentials.json

This prevents HEY from exercising the crashing path, at the cost of storing its
credentials in a mode-0600 plaintext file.

Possible fix

PR #165 looks directly relevant:

• Replace the shared write/delete hey::test availability probe with a
  read-only lookup.
• Avoid unnecessary Secret Service mutations and client disconnects during
  concurrent CLI startup.

It may also be worth adding a concurrency regression test that starts several
credential-store instances simultaneously on Linux.

Related

• Make keyring availability checks read-only #165 — Make keyring availability checks read-only
• GNOME Keyring itself should not abort on this race, but HEY CLI's concurrent
  write/delete probe appears to be the trigger in this environment.

[skuthus]

Independent reproduction on a second Omarchy machine — still present on HEY CLI 1.3.0.

Environment: Omarchy / Arch, gnome-keyring 1:50.0-1, HEY CLI 1.3.0 (mise install), Omarchy HEY bar plugin running hey --account all watch plus the short-lived hey … --json reads.

Crashes: 2 so far (coredumpctl): 2026-08-28 21:54:31 and 2026-08-29 13:47:14, both SIGABRT with the identical assertion sequence from the issue body (gkd_secret_service_get_pkcs11_session: assertion 'client' failed → … → g_variant_new: expected GVariant of type 'v' but received value has type '(null)'). No OOM, ~23 GiB free. systemd restarts the daemon each time.

Extra data point from a busctl --user monitor capture: once a minute the keyring receives a burst of 4–6 separate short-lived D-Bus connections (each lives ~14 ms), each doing OpenSession("plain") → Unlock → SearchItems → Get → Close, and some of them CreateItem/Delete on Password for 'hey::test' on 'hey'. The crash timestamp (13:47:14.565) lands exactly on that one-minute tick (13:45:25, 13:46:15, 13:47:14, 13:48:14, 13:49:14 …). The write/delete probe also leaves the keyring log full of asked to register item …/Default_5fkeyring/NNN, but it's already registered — 646 such lines today, item IDs up to ~590 while only 5 real items exist.

So the same conclusion as above: the crash is a gnome-keyring bug (it should return a D-Bus error for a vanished client, not abort), but the multiple-connections-per-invocation + hey::test write/delete pattern is what triggers it. A single connection per process and a read-only availability check (#165) would very likely make it disappear in practice.