OS credential store vs sume login: where the key lives

Inngest v1.45.0 stores OAuth credentials in the operating system's credential store, while the Sume CLI stores the key from sume login in a local config file at ~/.sume-com/config.json. The Sume docs do not mention an OS keychain, so protect that file and use SUME_API_KEY from a secret manager in CI.

What Inngest changed

The Releasebot Inngest feed says v1.45.0 on September 17, 2026 added OAuth login for CLI and MCP clients, and that "OAuth credentials are stored in the operating system's credential store and refreshed automatically".

Where Sume's CLI keeps the key

sume login opens the device approval page at www.sume.com/cli/login, waits for approval and stores a CLI-scoped API key in local config, by default under ~/.sume-com/config.json. SUME_CONFIG_DIR moves that directory for tests or isolated environments. The docs list SUME_API_KEY and the config file together as secrets that must never be printed or committed.

The login key is an API key, not an OAuth token pair, so there is no refresh step to rely on.

Practical rules

• Laptops: use sume login, and keep the config directory out of backups and repositories.
• CI and servers: set SUME_API_KEY from a secret manager; do not run sume login there.
• Headless machines: use sume login --no-browser to print the approval URL.
• Shared machines: set SUME_CONFIG_DIR per user or per job.
• Rotate a key from the API Keys dashboard if a config file leaks.

For hosted MCP, OAuth is the preferred path for interactive clients such as Cursor and Claude, and an API key stays available for automation. Which store your MCP client uses for its OAuth token is that client's choice.