feat(cli): graceful fallback for keyring failures

[sheikhlimon]

Summary

Add automatic fallback to file-based storage when keyring is unavailable.
Provides user-friendly warnings and security guidance while maintaining configuration functionality.

• Detect keyring-specific errors vs other failures
• Auto-enable GOOSE_DISABLE_KEYRING for fallback
• Work normally for all subsequent operations

Type of Change

• Feature
• Bug fix
• Refactor / Code quality
• Performance improvement
• Documentation
• Tests
• Security fix
• Build / Release
• Other (specify below)

AI Assistance

• This PR was created or reviewed with AI assistance

Testing

Related Issues

Fixes #5790

[sheikhlimon]

@DOsinga, this fix should work. I tested this using LLM, but wasn't able to replicate the said error on my machine as yesterday. Tried disabling even the keyring, but goose configure and ./target/debug/goose configure work no matter what I do. So I wasn't able to manually test it. Probably setting up a Docker or environment without keyring might trigger the error. But with my low-spec machine, that's quite hectic to do.
From OP's log, though, it looks like the original issue may still be happening on OP's end because the keyring wasn’t fully configured, and gcr-ssh-agent.socket doesn’t appear to have been properly enabled. They mentioned trying the fix, but based on the output, the socket was likely still disabled.

Edit: I added fallback for DBus error as well, look at the comment down below. I tested this manually. It seems to be working but this DCO check is killing me. I think I messed up my commit messages.

[sheikhlimon]

i guess we should handle this as well

Error: Failed to access keyring: Platform secure storage failure: DBus error: Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead

Edit: Managed to setup docker. Seems to be working.

🐚 
  ••/goose                                        [▴200][▿233]
󰪢 7s ❯ docker run --rm -it goose-test                     

This will update your existing config files
  if you prefer, you can edit them directly at /root/.config/goose

┌   goose-configure 
│
◇  What would you like to configure?
│  Configure Providers 
│
◇  Which model provider should we use?
│  OpenAI 
│
◇  Provider OpenAI requires OPENAI_API_KEY, please enter a value
│  ▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪
│
▲  Keyring service unavailable. Falling back to file-based storage for secrets.
│  
●  For better security, consider:
│  
●    - Fixing your system's keyring service
│  
●    - Or using environment variables for sensitive data
│  
◆  Configuration will continue normally with file-based storage
│  
◆  Successfully stored secret using file-based storage
│  
◇  Provider OpenAI requires OPENAI_HOST, please enter a value
│  https://api.openai.com
│
◇  Provider OpenAI requires OPENAI_BASE_PATH, please enter a value
│  v1/chat/completions
│
◇  Model fetch complete
│
◇  Select a model:
│  gpt-4o 
│
◒  Checking your configuration...                              └  Configuration saved successfully to /root/.config/goose/config.yaml

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity for 23 days.

What happens next?

• If no further activity occurs, this PR will be automatically closed in 7 days
• To keep this PR active, simply add a comment, push new commits, or add the keep-open label
• If you believe this PR was marked as stale in error, please comment and we'll review it

Thank you for your contribution! 🚀

[sheikhlimon]

Need a look on this

[DOsinga]

I like this; but I think we should cut down on the logging and make sure we actually write the value to non keyring.

[sheikhlimon]

When merging with main, I encountered conflicts because configure.rs was refactored and logic was moved into separate functions. I accepted main’s structure rather than fighting the refactor.

As a result, the FallbackToFileStorage handling appears only in merge commit. It will not show up in my original commits, so please review the merge commit changes to configure.rs.

The core fallback logic in base.rs is unchanged from my original commits.

@DOsinga This PR has been open for a while, and ongoing changes in main are making it increasingly time-consuming to keep it rebased and conflict-free. A review or merge when convenient would be greatly appreciated.

[DOsinga]

sorry forgot to press the button

[sheikhlimon]

sorry forgot to press the button

No worries!