MCP OAuth credentials are lost when a volatile GNOME Keyring session restarts

[shivam13verma]

What version of Codex CLI is running?

codex-cli 0.144.6

What subscription do you have?

ChatGPT workspace account.

Which model were you using?

Not model-specific. The issue affects MCP OAuth credential storage before a model turn.

What platform is your computer?

Linux 6.14.0-1021-gcp x86_64 x86_64

Ubuntu 24.04.3 LTS, gnome-keyring-daemon 46.1, headless VM accessed over SSH.

What terminal emulator and version are you using?

SSH shell, sometimes inside tmux.

Codex doctor report

Not available. codex doctor --json did not return before it was interrupted.

What issue are you seeing?

With the default mcp_oauth_credentials_store = "auto", Codex selects GNOME Keyring for remote MCP OAuth credentials. On this headless Linux VM, the default GNOME keyring collection is the volatile session collection:

$ cat ~/.local/share/keyrings/default
session

gnome-keyring-daemon repeatedly crashes while processing a Secret Service/PKCS#11 request:

gkd_secret_service_get_pkcs11_session: assertion 'client' failed
aes_negotiate: assertion 'session' failed
gkd_secret_service_publish_dispatch: assertion 'client' failed
g_variant_get_type: assertion 'value != NULL' failed
g_variant_new: expected GVariant of type 'v' but received value has type '(null)'
gnome-keyring-daemon.service: Main process exited, code=killed, status=5/TRAP
gnome-keyring-daemon.service: Failed with result 'signal'

I observed 19 SIGTRAP crashes in six days. Systemd restarts the daemon, but every Codex MCP OAuth credential disappears because the selected collection was in memory. Afterwards, all previously authenticated remote servers appear as Not logged in in codex mcp list. Codex's primary model login remains intact.

The logs do not identify which Secret Service client triggered the bad request, so I cannot establish that Codex itself caused the GNOME Keyring crash. The Codex-specific problem is that auto accepts a volatile session keyring as durable credential storage and does not preserve or recover MCP credentials after the daemon restarts.

What steps can reproduce the bug?

1. Use Codex on a headless Linux VM with GNOME Keyring available and ~/.local/share/keyrings/default set to session.
2. Leave mcp_oauth_credentials_store unset or set it to auto.
3. Authenticate one or more remote OAuth MCP servers with codex mcp login.
4. Restart or crash gnome-keyring-daemon.service.
5. Run codex mcp list.

The remote MCP servers are no longer authenticated. A daemon restart reliably reproduces the credential loss; the upstream GNOME assertion crash itself is intermittent.

What is the expected behavior?

auto should not treat a volatile session keyring as durable MCP credential storage on a headless machine. A transient credential-service restart should not silently erase every MCP login.

Possible remedies:

• Detect a volatile session collection and select file-backed storage instead.
• Persist a durable file fallback when keyring storage is selected.
• Recover from keyring unavailability/restart by loading a file fallback.
• At minimum, warn clearly that the selected keyring is session-only and credentials will be lost when the daemon exits.

Additional information

The verified workaround is:

mcp_oauth_credentials_store = "file"

After re-authenticating the MCP servers once, credentials are stored under CODEX_HOME and no longer depend on the GNOME Keyring daemon.

This appears related to credential-store fallback behavior, but it is distinct from issue #25002: this report concerns auto selecting volatile Linux keyring storage and losing all MCP credentials after a keyring-daemon crash/restart.

[shivam13verma]

Additional affected Codex thread/session ID for correlation: 019f6702-5d2a-7d90-8606-733f06c70be2.