Describe the bug
On a headless Linux host with no D-Bus Secret Service running, sc login fails after the device-code step with a raw, unactionable error:
Error: Platform secure storage failure: DBus error: The name org.freedesktop.secrets was not provided by any .service files
Nothing in the output tells the user that a file-based session backend exists (session_backend = "file" under [auth] in config.toml), so the CLI appears broken on servers/VMs/containers without a desktop keyring.
Steps to reproduce
- On a headless Linux box (no gnome-keyring / Secret Service on the session bus).
- Run
sc login and complete the device-code verification in a browser.
- Login fails when persisting the session to the OS keyring.
Expected behavior
When the OS secret service is unavailable, the error should be actionable telling the user they can set session_backend = "file" under [auth] in config.toml and retry. (A file backend already exists; the failure just isn't discoverable.)
Actual behavior
Error: OS secret storage (keyring/Secret Service) is unavailable. Store the session in a local file instead: add `session_backend = "file"` under `[auth]` in /home/user/.config/scalable-cli/config.toml, then run 'sc login' again.
[auth]
session_backend = "file"
Caused by:
Platform secure storage failure: DBus error: The name org.freedesktop.secrets was not provided by any .service files
DBus error: The name org.freedesktop.secrets was not provided by any .service files
The name org.freedesktop.secrets was not provided by any .service files
CLI version
sc 0.3.0 — Linux (headless, no Secret Service)
Install method
Homebrew
OS and version
Debian 11
Architecture
x86_64
Shell
bash
Command
sc login
Output mode
Human
Logged in before running the command
Yes
Broker context selected
Yes
Additional context
No response
Checklist
Describe the bug
On a headless Linux host with no D-Bus Secret Service running,
sc loginfails after the device-code step with a raw, unactionable error:Error: Platform secure storage failure: DBus error: The name org.freedesktop.secrets was not provided by any .service files
Nothing in the output tells the user that a file-based session backend exists (
session_backend = "file"under[auth]in config.toml), so the CLI appears broken on servers/VMs/containers without a desktop keyring.Steps to reproduce
sc loginand complete the device-code verification in a browser.Expected behavior
When the OS secret service is unavailable, the error should be actionable telling the user they can set
session_backend = "file"under[auth]in config.toml and retry. (A file backend already exists; the failure just isn't discoverable.)Actual behavior
CLI version
sc 0.3.0 — Linux (headless, no Secret Service)
Install method
Homebrew
OS and version
Debian 11
Architecture
x86_64
Shell
bash
Command
sc login
Output mode
Human
Logged in before running the command
Yes
Broker context selected
Yes
Additional context
No response
Checklist