Bug Description

hermes auth add <provider> --auth-type api_key --api-key ... still prompts for a label with raw input(). In non-interactive environments, that prompt raises EOFError instead of falling back to the documented default label.

Affected files

• hermes_cli/auth_commands.py:160-163 — computes default_label, then unconditionally calls input() when --label is omitted

Why this is a bug

The command already has a deterministic fallback label (api-key-N), so automation and scripted usage should work without an interactive TTY. Right now the non-interactive path crashes before the credential is added.

Minimal reproduction

cd /Users/genie/.hermes/hermes-agent
source venv/bin/activate
python - <<'PY'
from types import SimpleNamespace
from hermes_cli.auth_commands import auth_add_command

auth_add_command(SimpleNamespace(
    provider='openrouter',
    auth_type='api_key',
    api_key='sk-test',
    label='',
))
PY

Actual result:

• prints Label (optional, default: api-key-1):
• raises EOFError: EOF when reading a line

Expected Behavior

If --label is omitted and stdin is non-interactive, the command should use api-key-N automatically (or another non-interactive-safe fallback) and proceed.

Actual Behavior

The command blocks on input() and crashes with EOFError in non-interactive use.

Suggested investigation direction

• Gate the label prompt on sys.stdin.isatty() (or equivalent)
• Reuse default_label automatically when no TTY is available
• Add a regression test covering non-interactive auth_add_command() with label=None/""