[FEATURE] Voice mode: wake-word activation, toggle-to-talk, and configurable keybinding

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

*Single feature — sub-items are implementation options, not separate requests

Voice mode currently requires holding Space to record (push-to-talk). This works but limits hands-free
usage. Three related improvements that would make voice mode significantly more flexible.

Proposed Solution

1. Wake-word activation (primary request)

A configurable wake phrase (e.g., "Hey Claude") that starts recording without touching the keyboard. This
enables truly hands-free interaction — useful when reading docs, whiteboarding, or working away from the
terminal. Recording could stop on silence detection (already seems to exist) or a stop phrase.

1. Toggle-to-talk

Press Space once to start recording, press again to stop. Lower-effort alternative to hold-to-talk,
especially for longer dictations where holding a key is awkward.

1. Configurable voice keybinding

Allow users to remap the voice trigger key via /config or settings. Space conflicts with terminal scrolling
habits, and different keyboard layouts / accessibility needs may prefer a different key.

Alternative Solutions

xdotool / keybinding approach:

• Terminal focus required. xdotool sends keystrokes to the focused window. If you alt-tab away, the hotkey

fires into the wrong app. You'd need xdotool to first focus the correct terminal, which is brittle in
multi-terminal setups.

• Hold vs press. Voice mode needs Space held down for the duration of speech. Simulating a sustained hold

with xdotool key --delay is clunky — you'd need to simulate keydown on trigger, keyup on release. Two
separate events, timed correctly.

• WSL layer. You're on WSL2. xdotool talks to X11/Wayland — it can't reach Windows Terminal or whatever

terminal host you're using without an X server running. You'd likely need to use a Windows-side tool
(AutoHotkey) instead, which adds another layer.

Wake-word (Porcupine/Vosk) approach:

• Always-on mic. The wake-word listener needs continuous microphone access. On WSL2, mic passthrough is

already non-trivial (PulseAudio/PipeWire bridge). You'd be running two things competing for the mic — the
wake-word detector and Claude Code's voice mode.

• Latency. Wake word detected → simulate keydown → Claude Code starts recording → you start speaking.

There's a gap where your first words get clipped unless you pause after the wake word.

• Resource overhead. Porcupine is lightweight (~1% CPU). Vosk is heavier. Either way it's a persistent

background process.

• False positives. Any wake-word system triggers occasionally on ambient audio. In a home lab environment

with other audio sources, this could fire unexpectedly.

The honest assessment:

The juice probably isn't worth the squeeze right now. The biggest friction points — WSL2 mic passthrough,
hold-to-talk simulation, terminal focus management — stack up fast. A native feature request for
configurable keybinding or toggle-to-talk (press once to start, press again to stop) would solve this much
more cleanly than any workaround.

If you still want to try something, AutoHotkey on the Windows side is the most viable path since it can
target the terminal window directly and simulate proper key hold/release events without the X11/WSL
abstraction issues.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

I work in WSL2 where setting up OS-level workarounds (xdotool, AutoHotkey, external wake-word daemons) to
simulate the Space hold is fragile due to terminal focus requirements, WSL mic passthrough complexity, and
hold-vs-press timing issues. A native solution would eliminate all of that.

Priority suggestion: Toggle-to-talk is probably the simplest win. Wake-word is the most impactful.
Configurable keybinding is the most broadly useful.

Additional Context

VS Code already supports this pattern with "Hey Code" (accessibility.voice.keywordActivation). A similar
"Hey Claude" activation for the CLI would bring parity for terminal-first workflows.

Sources:

• VS Code Voice Support Docs

- VS Code adds 'Hey Code' voice command — InfoWorld

• Original GitHub issue exploring voice activation