[FEATURE]: Support non-interactive API-key login via auth login #57492

Activity

1. opencode-agent commented on Oct 20, 2026

   

   opencode-agentBot

   on Oct 20, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed request! In short, you'd like opencode auth login <provider> to accept an API key without a prompt, e.g. opencode auth login anthropic --api-key "$ANTHROPIC_API_KEY" (ideally with a stdin option too). That way CI, dev containers and setup scripts can save provider credentials without a terminal prompt.

   You're right that in v2 the API-key method always asks for the key in an interactive terminal, so this would be a new option. Maintainers will consider it.

   In the meantime, a partial workaround is to save the credentials once on a machine where you can enter them interactively, then copy them over: opencode auth export > creds.json there, and opencode auth import < creds.json (or opencode auth import creds.json) in the container or CI job. That file contains secrets, so handle it like one.

   Related:

   • [FEATURE]: CLI flags for auth login command #15725: the earlier request for the same flag, closed automatically for inactivity
   • feat(opencode): Adding options to auth login to skip questions #14470: added the options to skip the provider and method questions, but no key input
2. Dante-dan commented on Oct 20, 2026

   

   Dante-dan

   on Oct 20, 2026

   Contributor

   More actions

   I can take this on. Would maintainers approve a first version with --key-stdin and --key-env NAME, rather than an API key value in argv? For example:

   opencode auth login anthropic --key-env ANTHROPIC_API_KEY
   opencode auth login anthropic --key-stdin < /run/secrets/anthropic_api_key

   In current V2, keyLogin always calls secret() before the existing integration.connect.key({ integrationID, key, answer, location }) request. I would keep that connection path and change only the CLI input handling:

   • Require an existing integration ID/name; either input option selects its key method. Reject conflicting options, explicit non-key methods, unsupported providers, missing environment variables, and empty/whitespace-only keys. Keep interactive behavior when neither option is given. Leave well-known URL discovery outside this first noninteractive path so failed validation cannot add provider configuration.
   • Stdin must be redirected, read once to EOF with a size bound, remove only one final LF/CRLF, and reject embedded newlines. The env option reads the named variable, not a secret argument; CI environments still need normal secret handling.
   • Reuse --answer validation/defaults, but fail on missing required or external-interaction fields instead of prompting/opening a browser in this mode. Validate everything before the single connect request; do not write credential/config files directly or introduce a delete-then-replace flow.
   • Report success only after persistence succeeds; retain exit 1 for errors and 130 for cancellation. Never echo key input, including on errors. Saving a credential is not proof the provider accepts it.

   Tests would cover piped stdin and env persistence, option/method conflicts, malformed/empty input, provider form validation, no mutation on validation failure, persistence failure preserving existing accounts, output redaction, and interactive fallback. #14470 covers selector skipping; this would fill the remaining secret-input gap raised in #15725.