Improve error message when Secret Service is unavailable on Linux

[WXY-V1hZ]

Body

What are you proposing?

I ran into this issue after saving my DeepSeek API key in Zed. Everything worked fine until I restarted Zed — the API key was gone and I had to reconfigure it just to use the AI features again. I checked the logs and found this error.

When Zed on Linux cannot reach a Secret Service provider (org.freedesktop.secrets on DBus), it currently logs a raw, cryptic DBus error and silently falls back to storing API keys only in memory — they are lost on restart.

I propose that Zed detect the missing Secret Service early and show a clear, human-readable warning or error to the user.

For example, instead of this in the logs:

ERROR [crates/language_model/src/api_key.rs:117] DBus error service error org.freedesktop.zbus.Error: The name is not activatable

Show the user something like:

⚠️ Cannot securely store API keys: no Secret Service provider was detected on your system.
Keys will only be kept for this session and will be lost when Zed is closed.
Install gnome-keyring (or an equivalent) to persist keys across restarts.

The underlying secure-storage mechanism (Secret Service DBus API) is fine — this is purely about the error message UX.

Why does this matter?

Many Linux users run lightweight window managers or compositors (Sway, i3, Hyprland, niri, dwm, etc.) that do not bundle a Secret Service daemon like gnome-keyring or KWallet. These users hit the bug without any clue what went wrong — they just notice their API key disappeared after restarting Zed.

The raw DBus error is meaningless to almost everyone. A friendly message:

• Saves users hours of debugging — searching the error, finding forum posts, piecing it together.
• Makes Zed more approachable on Linux, especially for users coming from macOS/Windows where key storage "just works."
• Costs almost nothing to implement — it's a check + a message.

Are there any examples or context?

Other tools that do this well

• VS Code detects the missing gnome-keyring at startup and shows a notification suggesting to install it for credential storage.
• 1Password CLI prints a clean message: "DBus secret service is not available; password storage will not persist."

The broken user journey (today)

1. User sets API key in Zed               → works fine
2. User restarts Zed                      → key is gone
3. User checks logs, sees:
   "org.freedesktop.zbus.Error: The name is not activatable"
4. User has no idea what this means
5. User researches, installs gnome-keyring, fixes it — 30+ minutes wasted

The fixed user journey (proposed)

1. User sets API key in Zed               → Zed warns:
   "No Secret Service detected. Key will not persist."
2. User installs gnome-keyring, restarts  → problem gone
   2 minutes total

Possible approach

The check is straightforward — try to introspect the org.freedesktop.secrets name on the session DBus. If unavailable:

1. On key save: Show a one-time warning popup / toast explaining the situation and linking to docs.
2. Optionally, on startup: If no Secret Service is available and the user has configured an AI provider, surface a persistent status-bar icon or notification.

The code path likely already exists around:

crates/language_model/src/api_key.rs

where the DBus error is currently emitted. That error-handling branch is the natural place to add a user-facing message. No new infrastructure is required — just convert a raw error into a friendly one.