goose keyring errors on MacOS and Linux

[valerie-autumn-skye]

When running goose via runner.py on MacOS and Linux, keyring errors may occur.

thread 'main' panicked at /Users/runner/work/goose/goose/crates/goose-cli/src/session/builder.rs:53:61:
called `Result::unwrap()` on an `Err` value: Failed to access keyring: Platform secure storage failure: A default keychain could not be found.

It is definitely related to your goose configuration. I had this same keyring issue, but only when running under WSL2 Ubuntu. The fix was to install and start gnome-keyring in the background (see blog post). However, on Mac, this probably has a similar cause but different solution. I suspect your goose is configured to store your API keys in a way that requires some part of your login shell environment to be available.

Originally posted by @ct-parker in #16 (comment)

[github-actions]

Issue Summary: Goose Keyring Errors on macOS and Linux

This issue reports keyring-related failures when running goose via runner.py on macOS and Linux platforms. The error occurs when goose attempts to access the system keyring to retrieve stored API keys but cannot find or access the required keychain services.

Technical Details

Error Pattern:

thread 'main' panicked at /Users/runner/work/goose/goose/crates/goose-cli/src/session/builder.rs:53:61:
called `Result::unwrap()` on an `Err` value: Failed to access keyring: Platform secure storage failure: A default keychain could not be found.

Root Cause:
The error originates from goose's dependency on platform-specific secure storage mechanisms for API key management. When these services are unavailable or misconfigured, goose fails to initialize properly.

Platform-Specific Context

Linux/WSL2 Environment

@ct-parker previously resolved a similar issue on WSL2 Ubuntu by installing and configuring gnome-keyring:

• Solution: Install and start gnome-keyring as a background service
• Reference: Blog post about WSL configuration (link currently inaccessible)

macOS Environment

The issue likely stems from similar keychain access problems but requires a platform-specific solution, possibly involving:

• Keychain Access configuration
• Login session environment variables
• macOS Security Framework dependencies

Related Issues Context

This issue is part of a broader pattern of platform compatibility problems in metacoder:

1. Issue runner.py fails to use temporary Goose config on Windows #29: Windows-specific path and configuration problems with temporary goose configs
2. Issue Coders should not rely on default encoding from operating system. #14, Errors resulting from incorrect character encoding for sub-processes #23: Character encoding issues across platforms
3. Issue Test case names can result in invalid eval directory names #21, Forward slashes in test case names result in incorrect eval directory structure #22: Path validation and directory structure problems

Potential Solutions

1. Environment Detection: Implement platform-specific keyring initialization
2. Fallback Mechanisms: Provide alternative API key storage methods when keyring is unavailable
3. Configuration Validation: Add pre-flight checks for keyring availability
4. Documentation: Platform-specific setup guides for keyring configuration

Technical Investigation Needed

• Test keyring availability detection across platforms
• Investigate goose's keyring configuration options
• Evaluate alternative credential storage mechanisms
• Document platform-specific setup requirements

This appears to be a fundamental compatibility issue that affects the core functionality of metacoder when using goose across different operating systems.