Keyring token caching fails on macOS - tokens don't persist between commands

[amandacdillon]

Problem

When running eightctl on macOS, the keyring token caching doesn't work correctly. Tokens are reported as "saved" but cannot be read back on subsequent commands, causing fresh login attempts each time.

Steps to Reproduce

1. Run eightctl status --verbose
2. Observe logs show:
   • keyring get failed error="The specified item could not be found in the keyring"
   • authenticating with server
   • keyring saved token
3. Run eightctl status --verbose again
4. Same "keyring get failed" appears - token was not actually persisted

Expected Behavior

After first successful auth, token should be cached and reused on subsequent commands.

Actual Behavior

Every command triggers a fresh login, quickly hitting Eight Sleep's rate limits (429 Too Many Requests).

Environment

• macOS (arm64)
• eightctl version: 0.1.0-dev
• Keychain access was approved when prompted

Workaround

Currently none - users hit rate limits quickly when running multiple commands.

Suggestion

Consider adding file-based token caching as a fallback (e.g., ~/.config/eightctl/token.json) when keyring access fails, similar to how many other CLI tools handle this.

[drgrib]

I've been testing the proposed fixes (like PR #16) for this in a headless macOS environment via Go server running eightctl via an Exec call and, unfortunately, they don't fully resolve the hang.

While the file-cache fallback is a great addition, the underlying 99designs/keyring dependency is designed to hunt for the most secure OS-native storage first. Because the macOS Keychain is present, the library still prioritizes it.

When eightctl creates a new keychain item upon daily token rotation, macOS treats it as an entirely new authorization request. Because the locally compiled Go binary lacks a stable Apple Developer signature and is spawned by rotating background process IDs, the OS aggressively forces a new UI prompt, completely hanging the headless execution.

To actually bypass the keychain in these environments, we need a way to explicitly force the keyring.Config to file mode, completely blinding it to the OS.

Adding a --no-keychain flag (or an EIGHTCTL_NO_KEYCHAIN=true env var) that does this would cleanly solve the headless hang:

// Example implementation passing the override to internal/tokencache
keyring.Config{
    AllowedBackends: []keyring.BackendType{keyring.FileBackend},
    ServiceName:     "eightctl",
    // ...
}

Temporary Workaround for macOS Users

If you are currently blocked by these headless keychain prompts, you can manually force the dependency into file-mode by pulling PR #16, vendoring the modules, and injecting a bypass into the keyring library before compiling.

Run this in your terminal:

git clone https://github.com/steipete/eightctl.git
cd eightctl

# Pull the file-cache PR
git fetch origin pull/16/head:file-cache
git checkout file-cache

# Vendor dependencies to allow local modification
go mod vendor

# Force the keyring library to ignore the macOS Keychain and strictly use File mode
perl -pi -e 's/^(func Open\([^)]+\).*\{)/$1\n\tcfg.AllowedBackends = []BackendType{FileBackend};/g' vendor/github.com/99designs/keyring/keyring.go

# Compile and install using the modified vendor code
go install -mod=vendor ./cmd/eightctl

This will successfully cache your token in ~/.config/eightctl/ and permanently stop macOS from prompting your background processes.