[FEATURE] Voice mode hardcodes "dummy-key-for-local" instead of supporting configurable API keys for local STT services

Resolved 💬 4 comments Opened Sep 10, 2025 by lruthotto Closed Jan 11, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Summary

Voice mode fails to authenticate with local STT services that require API keys because it hardcodes "dummy-key-for-local" instead of allowing user-configurable authentication.

Expected Behavior

Users should be able to configure API keys for local STT services (like self-hosted Whisper) via environment variables, similar to how OPENAI_API_KEY works for OpenAI services.

Actual Behavior

Voice mode hardcodes "dummy-key-for-local" for all non-OpenAI providers, making it impossible to authenticate with secured local STT endpoints.

Code Location

In voice_mode/tools/converse.py:

# Use dummy API key for local services, real key for OpenAI
tts_api_key = OPENAI_API_KEY if tts_config.get('provider_type') == 'openai' else "dummy-key-for-local"
stt_api_key = OPENAI_API_KEY if stt_config.get('provider_type') == 'openai' else "dummy-key-for-local"

Steps to Reproduce

  1. Set up a local STT service with API key authentication (e.g., Whisper server)
  2. Configure voice mode to use the local STT endpoint via VOICEMODE_STT_BASE_URLS
  3. Attempt to use voice mode with converse("test message")
  4. Observe 401 Unauthorized errors in server logs

Debug Evidence

Server logs show voice mode sending Authorization: Bearer dummy-key-for-local instead of a valid API key:

🔍 Authorization: Bearer dummy-key-for-local
🔍 RESPONSE: 401

Impact

This prevents users from:

  • Using secured local voice services
  • Following security best practices for self-hosted deployments
  • Properly integrating Claude Code with existing voice infrastructure

Proposed Solution

Proposed Solution

Add support for local provider API keys, such as:

  • VOICEMODE_STT_API_KEY for STT services
  • VOICEMODE_TTS_API_KEY for TTS services

Update the authentication logic to check for these environment variables before falling back to dummy keys.

Alternative Solutions

Modify the local service to accept the hardcoded dummy key (not recommended for production).

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗