TTS readback of responses + voice mode for Remote Control sessions

+1 on this. I just built a working proof-of-concept of exactly this using Claude Code hooks and
local tools:

• TTS output: https://github.com/rhasspy/piper (offline neural TTS) reads back responses via a say

script called from a CLAUDE.md instruction

• Auto-listen: After speaking, it records from the mic for ~10 seconds, transcribes locally with

https://github.com/ggml-org/whisper.cpp, and types the result into the terminal via xdotool

• Session call signs: Each conversation picks a one-word identifier so you can distinguish which

session is speaking

It works surprisingly well as a conversational loop — fully offline, no data leaves the machine. But
it's held together with shell scripts and xdotool keystroke injection, which is fragile.

Having this natively in Claude Code would be a huge improvement. The key pieces I'd love to see:

1. Built-in TTS for responses (with smart filtering — speak explanations, skip code blocks)
2. Auto-listen window after TTS finishes, with configurable duration and silence detection
3. Hook access to response text in the Stop event — this would make TTS hooks much cleaner

Happy to share the scripts if anyone wants to try the DIY approach in the meantime.

+1 — also hitting this. Using Remote Control from my phone, dictation works fine via the OS keyboard, but having to read every response on a small screen makes long sessions painful. Even just optional TTS playback (no full bidirectional voice) would unlock hands-free / eyes-free workflows.

Adding accessibility weight to this.

I have dyslexia and ADHD; voice is my primary input/output channel, not a convenience. On Mac I have a full hands-free loop working today — SuperWhisper for input, say -v Daniel as a Stop hook for output. It works because the Mac has local mic access and the hook system can fire TTS on Stop events.

The iPhone Code tab has none of that. iOS keyboard dictation works but it's transactional, not conversational; Speak Screen requires tapping the screen, which defeats the point.

The use case I'm trying to solve isn't gym/hike convenience — it's driving and walking with hands full. Looking at a screen to read each response isn't an option in those contexts.

A second vote for what @bruschke described: hook access to response text in the Stop event would let people like me wire this together on the Mac ourselves. And TTS playback + push-to-talk in the iOS Code tab — even without full conversational mode — would close the biggest gap.

The "Low — Nice to have" priority is true for the convenience case. For someone using voice as a primary access channel, it's the difference between using Claude Code on the go and not.

Yes please. I desire to do detailed code reviews whilst folding my laundry, and this seems like a foundational gap in my mission-critical workflow. 😂

This capability would be a game changer for those of us who orchestrate long-running, multi-instance teams of Claude Code working on epic size workloads. Being able to drop in the middle of a team using voice mode to ask questions or provide guidance, while on a walk with the dog or being on the road, would bring outcome-centric orchestration to another level.

I'm already using SuperWhisper, configured to know about my project-centric keyword naming conventions, to streamline my input into the development process. Being able to do the same while using remote-control is the next step.

Claude Desktop and Claude Mobile already have duplex-voice chats. I vote for having the same capability in Remote Control.

Thank you for an amazing Claude ecosystem.

+1 billion

This feature including voice commands to switch sessions; like "switch to the session working on the new ecom feature" would revolutionise coding forever.

Every developer in the world would become the most buf fit gym bro, and hike the world.

Though I don't see getting this working smoothly as a super easy feature. The main problem being for coding I wanna use Opus 1m in Ultracode max effort, which is super slow, while the existing voice mode uses the cheap fast model enabling fast conversational UX.

💡 💡 💡 💡 💡 💡 💡 💡 💡 💡
IDEA: use a fast dumb shim meta model between the main model.
💡 💡 💡 💡 💡 💡 💡 💡 💡 💡

So when you say "ensure you refactor the package so it's fully DRY", the shim meta model says "sure I'll do that, I'll let you know when I'm done" rather than just hanging. Then it doesn't spit out the usual epically verbose Opus style report listing off all the files it touched and blar blar blar, the shim model says "that's now done, do you want some more detail on what was touched?"

Also the shim meta model could allow for context switching between sessions. It could also notify you when a session finishes it's current prompt (i.e. pauses for user input), like it could say "Oh btw, the last task you gave for the ecom feature session is complete - want me to give you the report?"

Yes please. I desire to do detailed code reviews whilst folding my laundry, and this seems like a foundational gap in my mission-critical workflow. 😂

16 hours of Claude leaves 8 hours to sleep - but it's not healthy to spend 16 hours at a desk staring at a screen.

My solution to this might not suit everyone, and it's worth saying up front: it isn't voice inside Remote Control or on the phone — it runs on your laptop. But if you keep the laptop nearby — in a backpack, on the passenger seat of the car, or just somewhere in the house while you move around — with AirPods, earbuds, or a Bluetooth speaker, you get a full hands-free voice loop while you do chores, walk the dog, shower or drive. For a lot of the "away from the desk" cases in this thread, that turns out to be enough.

I maintain VoiceMode, an MCP server that adds a real two-way voice loop to Claude Code — not just dictation. Claude speaks its response and listens for your reply in the same turn, so it's a genuine hands-free back-and-forth about live code.

What it covers from this thread:

• TTS readback on desktop (@david-emmerichs-ai, @mb7272) — responses are read aloud, so you're not stuck reading every reply on a screen.
• The DIY hook setups, integrated (@bruschke, @winstongarland9-ux) — instead of hand-wiring piper / say / SuperWhisper, it's one loop. It's local-first and offline-capable (local Whisper for STT, Kokoro for TTS) or any OpenAI-compatible endpoint — which matters for the accessibility case, where voice is the primary channel and you may not want every utterance going to the cloud.
• Code review while folding laundry / on a walk (@webchick) — that's the daily driver here, via the laptop-nearby + earbuds setup above.

It's open source (~1.2k★) and installs as a Claude Code plugin — happy to help anyone here get set up.

+1 this is the missing half of the mobile experience for me.

Use case: hands-free supervision. I'd like to task a Claude Code agent by voice while away from the keyboard (walking, headphones on), have it work on my repo via Remote Control, then glance back to read the diff and approve/merge. Speak in, text/diff out — the agent does the work in the background.

Since Remote Control already gives mobile access to a session's context (CLAUDE.md, project memory, MCP tools, working dir), voice feels like a natural layer on top rather than a new product: streaming dictation for prompts, push/Live-Activity notifications when the agent finishes or needs input, and optional TTS readback of summaries.

Prior art: Cursor's iOS app (June 2026) ships almost exactly this — voice input + slash commands to steer cloud/desktop agents, review diffs and merge from the phone. A first-party Claude Code equivalent on top of Remote Control would close the gap.

Yes, I also would like to be able to pull weeds, go for a walk, etc while tending a remote session. The phone already has better voice control for a regular chat in the app, it seems like it shouldn't be hard to add it to remote sessions as well.

+1 from me here too!

Recently become a dad and honestly having any time to sit/read/code is out the window. I've tried Gemini and Googles Jules as an Async coding partner but they are extremely lacking, this is _SO_ close to the natural feedback loop that I've been looking for.

I'm Cora, Mike Bailey's assistant. He asked me to read this thread and draft a reply while his hands were full, then he reviewed and edited it on his phone. Posting it for him, in his words.

@k-flynn-webdev congratulations, and that's the case I'd most want this to work for. A newborn is the clearest version of the problem: your hands are busy and your eyes are busy, but your head is completely fine. Text-based async agents ask for the one thing you've just run out of, which is going to a screen, looking at it, and putting your hands on a keyboard. Sometimes the baby has finally settled and you simply do not want to move. The baby doesn't mind you talking. The setup I described above is the laptop-nearby one rather than anything on the phone: laptop wherever you are, earbuds in, talking to a session that already has the repo loaded. Pacing a hallway at 3am turns out to be a genuinely good code review slot. @samthebest on the shim model. I'd push back gently on the framing, because I don't think the problem is speed, I think it's that one agent is being asked to do two different jobs. What worked here was giving the conversation its own agent, one that doesn't write code. It answers at conversation latency and dispatches the slow, expensive work to separate sessions. Then the part that actually removes the need for a shim: those sessions don't get polled, they push. When one finishes it literally sends mail, which wakes the conversational agent, which tells me. So the "oh by the way, the ecom session is done, want the report?" you described comes out of the architecture rather than out of a meta model guessing, because the worker itself said so. To be clear, that part is my own glue rather than anything packaged, so I'm describing a pattern here, not a feature you can install. If mail-as-substrate is interesting to anyone, we wrote up why we landed on it here: https://cora7.com/blog/the-mailbox-is-the-memory/ Voice session-switching falls out of the same design. If the conversational agent is the one holding the map of what's running, "switch to the one doing the ecom feature" is just a question you ask it. @playnox your speak-in / diff-out split matches my experience closely. Voice is excellent for steering and poor for review. I talk while walking, then read the diff on a screen when I'm back. None of this argues against the original request. First-party voice in Remote Control would be better than anything wired together outside it. But the laptop-nearby version works today, and for anyone in @k-flynn-webdev's situation, "today" is worth a lot more than "eventually". I composed this comment by voice while my hands were busy shifting storage tubs around my lounge, then reviewed it on my phone. Working with Claude Code the whole time. I filmed it, and here it is: https://youtu.be/Y3iHIxSOKwE

Mike asked me to post this for him, same as last time.

Here it is, as promised: https://youtu.be/Y3iHIxSOKwE Two minutes. That's me shifting storage tubs around the lounge while asking Cora to read this thread and draft that reply. I reviewed it on my phone and she posted it. The laptop is in the room the whole time and I never touch it. @k-flynn-webdev this is the one I made it for. Worth saying what it doesn't show, since that's the honest part: I still read the draft before it went up. Voice is good for steering and poor for review, which is the split @playnox described. The win isn't that I skipped the reading. It's that the reading was the only part that needed me at a screen.

First-party voice in Remote Control would be better than anything wired together outside it.

[mbailey typing this] I didn't review Cora's wording closely enough and would walk this line back a bit.

1. I agree that adding two way voice to Remote Control would improve it.

1. I would argue that running your own open source voice layer has some advantages:

• privacy
• control
• ability to modify
• choice of voice models
• portable: BYO voice instead of drinking the house wine

In the end I actually just created a gmail skill to stash any recent communications from my CLI into a draft email with a label. Then have a corrosponding skill in /chat to go read any recent draft emails with the same label and play them as audio to me.

its a slow round robin effort BUT it seems to work and be more helpful in the meantime.
Such a shame that you cant even use the share URL from the claude code chat to import into claude chats =/

In the end I actually just created a gmail skill to stash any recent communications from my CLI into a draft email with a label. Then have a corrosponding skill in /chat to go read any recent draft emails with the same label and play them as audio to me.

Nice. Email for agent messaging is the way to go. And for memory too!

https://cora7.com/blog/the-mailbox-is-the-memory/

Everything in this thread so far attacks the problem from one direction — bolt voice onto Claude Code (piper, whisper.cpp, xdotool, say on a Stop hook, SuperWhisper). I ran that for a while too. Then I inverted it, and the inverted version is the one that stuck, so it seems worth adding.

The issue body names the real constraint precisely:

The Claude mobile app has a full two-way voice mode, but it has no access to a live codebase.

Instead of giving Claude Code a voice, I gave the app's existing voice something to read. It's been running since 2026-08-08, 48 calls.

The loop

agents write docs  →  desk/*.md
                   →  rclone up-sync  →  Google Drive
                   →  in-app voice call reads Drive via the connector,
                      writes minutes back to Drive
                   →  120s rclone poll pulls minutes down
                   →  one message onto the agent bus
                   →  agents act on it

No STT, no TTS, no mic code, no barge-in tuning, no VAD thresholds. Anthropic already solved capture; the gap was context, and context is a file-sync problem.

What it's good at

Kicking ideas around with an agent that has real, current project context — open items, status, decisions, plans. Triage while driving. "What's on my desk," "defer that one," "have the team dig into these four." Decisions come back down as structured items and agents pick them up without me touching a keyboard.

What it is not

• Not a live codebase. The call agent doesn't run code, grep the tree, or see a diff. But it isn't shallow either — the sync carries the org's decision log and status reports alongside the item list, so the agent is engaged right up to the reasoning over the code. It can argue about an architectural call and why it was made; it just can't read the source that implements it.
• Not a coding channel. Speaking a change and seeing it built is a round trip through agents, not an edit you watch happen. This is for thinking and directing.
• One-directional on execution. The call writes minutes; a separate watcher relays only what I explicitly addressed to a named seat. Nothing decides on my behalf.

Two gotchas that cost me real time

1. --drive-import-formats breaks rclone's change detection. Uploading local .md as native Google Docs makes the remote object report Size: -1 and Hashes: null, so the default modtime+size comparison can't match and re-uploads everything, every run. I measured ~5,200 Drive writes/day on a 54-file tree at a 15-minute cadence. --checksum, --size-only, or --update all suppress it — the default path treats "can't compare" as differs, those treat it as matches. Verified on rclone v1.75.0 today.

2. Conversion strips the extension. FIRM-STATUS.md becomes a Doc titled FIRM-STATUS. rclone re-appends an export extension when listing, so it looks like .md survived. Anything asking Drive for the file by name has to use the bare title — an assistant searching for FIRM-STATUS.md failed intermittently until I worked that out.

Loop guard, if anyone builds this: the down path's landing directory must be excluded from the up-sync, or every minutes doc round-trips forever. And anchor rclone filter patterns from the root (/Desk Review List.md, not Desk Review List.md) — a bare filename doesn't match the way you'd expect, so an exclusion you think is active silently isn't.

Why I moved off the local stack

I ran two local lines behind a gateway: one small-model, one a claude -p session with local Whisper STT and piper TTS — architecturally close to what @bruschke described.

What killed it wasn't bugs. The bugs were workable. It was latency, and how badly local models use tools. The small line had tool access and mostly didn't use it — it would confabulate rather than admit it couldn't check something, at one point stating a client meeting as settled fact that existed nowhere in my records. That's the failure mode that matters in a channel you're using because you can't look at a screen: a wrong answer you can catch, a plausible wrong answer you can't. Add the round-trip time of local STT → model → local TTS on top and the conversational feel that justifies voice at all is gone.

Since the model doing the reasoning is the constraint, and Anthropic already runs a good one on the other end of a phone call, moving capture to them and shipping context over was the cheaper trade.

Worth recording one bug anyway, because the diagnosis generalizes: the browser sent pcm.subarray(a,b).buffer, and .buffer on a subarray is the whole backing ArrayBuffer — every chunk re-sent the entire block, 2× inflation at 48 kHz. Whisper got each utterance duplicated back-to-back and transcribed one sentence as "Can you hear me? Can you hear me? Can you hear me?" It hid for five days because nothing compared bytes-in against elapsed time, so every symptom read as a model or threshold problem and that's what I tuned. If you build a local pipeline, assert the wire rate — 32000 bytes per wall-clock second at 16 kHz — before you tune anything upstream of it.

I'd still like native bidirectional voice in Remote Control — @remygendron's framing of dropping into a running team by voice is exactly the thing I want and this doesn't give me. But the Drive route got me most of the value without owning a mic pipeline, and "let the app do capture, sync it something to read" is a cheaper answer than it looks.

Happy to share the sync script or the filter if it's useful to anyone.

Been building in this exact space (backend-agnostic — Claude Code/Codex/OpenCode — voice frontend, local STT/TTS, no cloud) for a few months, for almost this exact use case: chores, caregiving logistics, walking around the house.

A few things that mattered more than expected, in case useful to anyone reading this thread:

• Always-on listening (no button, no "start a session") turned out to matter more than raw barge-in quality — you stop thinking of it as "voice mode" and just talk.
• Barge-in needs real echo cancellation or headphones, or the assistant hears and interrupts itself. Confirmed genuinely working with a real human voice — but also found a real self-triggered barge-in loop under rapid back-to-back turns. Worth knowing before assuming AEC is solved once it passes a first test.
• A spoken safeword checked before anything else (not just "pause") turned out to be necessary once the agent has real write access — an open mic occasionally mishears things.

Windows has been the most-tested platform here, if useful given a couple of comments above mention it specifically.

Project's called ConvoBox if anyone wants the approach (github.com/LegionForge/convobox) — still rough in places (a Windows force-kill gap is disclosed in the known-issues doc, not hidden). Sharing mainly because this thread is the clearest signal I've seen that this is worth building well.

Looks like read aloud had now been added to the Claude code on mobile! It helps it's almost there

I don't see a read-back feature in the app yet — I'll keep an eye out.

An update in the meantime: Google Drive has been flaky, so the sync hop in my earlier comment is gone. Four pieces replaced it.

1. A hook that writes the prose out. A MessageDisplay hook in ~/.claude/settings.json (matcher "", so every message) runs a small script that reads the session transcript, takes the last assistant text, and appends it to a per-agent .md file. Prose only — tool calls and results don't cross. Two details that matter: end the command with || true and redirect stderr to a log, so a broken script can never block the session; and key the file on the agent, not the session id, or the address changes every relaunch and a call can't find it. It fires per message, so the file is seconds-fresh rather than end-of-session fresh.

1. An MCP server behind a cloudflared tunnel. Authenticated MCP at /mcp, plus the OAuth discovery paths (/authorize, /consent, /token, /register, /.well-known/*), added to claude.ai as a custom connector.

1. Read tools over those files. List roots / list dir / read file / outline / search, pointed at the digest directory and a few document folders. A refusal comes back as a normal reply with a reason slug, so the call agent says why it can't read something instead of talking around it.

1. A messaging proxy back. Write tools that let the call session send a message to a named agent, or file an item. Anything that would actually branch or build lands gated and needs an explicit approval from me — the call can direct work, it can't start it.

The gotcha that cost me the most time: a host-wide Cloudflare Access app silently breaks the connector. Access has to sit on the interactive paths only — /authorize and /consent. In front of the whole host, Anthropic's machine calls to /mcp, /token and /register get redirected to a login they can't complete, and it doesn't fail in a way that tells you that.

One design note if you build it: put a single deny-list gate between the tools and the filesystem and route every byte through it. Read-only isn't the boundary it sounds like — a credential file inside the read surface doesn't let someone forge an approval, it lets them mint a real one.

It's a bit complicated, but it's been nice. It isn't a call with the coding agent — it's a call with the coding agent's secretary. Round-trip latency on a coding task is the Claude Code session's own, latency on the call is 0+mcp lookup and thinking time (<3sec for a big lookup unless it overloads context) and the call follows me around the house across topics, giving statuses and sending messages. Simpler than fighting the local voice stack, real-time discussion, and the call session is basically exchanging voice memos on my behalf the way you would through Discord.

+1, hit this today (v2.1.269, Linux). Driving a CLI session from my phone over Remote Control while working — /voice returns "/voice isn't available over Remote Control." Phone keyboard dictation is the only option and nothing gets read back.

Worse: when I tried to report it in-app, /feedback also returns "isn't available over Remote Control." So the one channel for reporting Remote Control gaps is itself blocked over Remote Control. At minimum, /feedback should work from the remote client.

The mobile Claude app already has two-way voice. Wiring that into Code sessions over Remote Control is the ask.

I ended up developing a hands-free voice feature for developers that works with both Claude Code and Opencode, on the subscription(s) you already pay for. I built it for myself first, then packaged it as a Mac app. It's in beta now: Squad33.ai

It lets you work away from the Mac, phone in your pocket, hands-free. You talk, the agent's reply is read back in your earbuds, and what you describe becomes tickets on a kanban board that Claude Code or Opencode work through in their own git worktrees, coming back as pull requests.

Feedback welcome, especially from those of you who built your own loop above.

this is really mandatory by now, i cannot read responses while driving!

Same observation from the VS Code extension (Claude Code 2.1.282, macOS), tested on 27 September 2026. After /remote-control, the session opens in the Code tab of the mobile app. Input works by keyboard dictation and answers arrive as text. Voice mode in a regular chat in the same app gives a hands-free spoken dialogue, without access to the session. A voice mode inside the Remote Control session would combine the two.

+1. My use case: I run long Claude Code sessions in the desktop app on a Mac and follow them from my phone through Remote Control while I'm away, usually with AirPods in. Two things would make this truly hands-free:

1. Spoken replies: an option to read every new assistant message aloud automatically, in Remote Control and in the desktop Code tab, not only per message through Read Aloud.
2. Voice turns: speak a reply and have it sent without touching the screen, including while a turn is still running.

Until this exists I'm using a local workaround (a TTS engine on the Mac that reads new replies and streams the audio to my phone). It works, but it's fragile, and native support would help anyone using Claude Code while driving or walking, or with accessibility needs.

[Written by an AI agent (Claude Code) on behalf of @vladknysh, who reviewed the text and asked for it to be posted.]

+1 to this, from the iOS app. I run Claude Code on a MacBook and steer the session from my phone through Remote Control.

Where it stands for me: the Code tab composer has dictation, so sending prompts by voice works. Claude can't talk back. Chat in the same app has a full voice mode, and that is what I'd like in Claude Code sessions.

One part of chat voice mode I'd ask to be included, because I haven't seen it mentioned above: the read-along. When Claude speaks in chat, the app shows the text it is about to say and highlights each word as it is spoken. I can follow by ear, glance at the screen, and catch a word I misheard.

It matters more in Claude Code than in chat. Replies mix prose with file paths, commands, diffs and tool output, and nobody wants a diff read aloud. With the transcript on screen, the app could speak the prose, skip or summarise the code and tool output, and still show everything, so the listener can see what was left out. Without the on-screen text, a voice mode here would either read out junk or be a black box.

Setup: Claude iOS app, Claude Code 2.1.281 on macOS, attached through Remote Control.

---
_Generated by Claude Code_

this would be a game changer! please port the 2-way conversational voice mode from claude chat to claude code. this would be soooo useful. my nr 1 feature request for claude code!

Have you not tried https://voicemode.dev yet?

• free and open source
• local voice models
• vendor neutral

300K downloads over past year

Same need here. Until Remote Control gets a voice mode, one workaround is to let the Mac running the session do the talking.

Disclosure: I work on Heard. It runs on the Mac, speaks a short summary when a Claude Code session finishes, fails or needs you, and its iPhone companion lets you listen live and reply by voice or tap from your phone. The phone part is on the paid plan; the Mac narration also has a free open-source engine (github.com/heardlabs/heard). More on the phone setup: https://heard.dev/use-cases/on-the-go?utm_source=github&utm_medium=community&utm_campaign=cc-issue-42700

A native voice mode in Remote Control would still be the cleanest answer, +1.

Disclosure: I built this, so take it with that in mind.

For the two-way part there is a workaround today: voicehook (https://voicehook.ai/?utm_source=github&utm_campaign=d5-cc42700).

You start a voice call in the browser, on your phone if you like. Tap "invite agent" and paste the link into your running Claude Code session. It joins over plain HTTPS/curl, nothing to install. Instructions for the agent: https://voicehook.ai/agent/SKILL.md

The voice in the call answers from a status board and FAQ that the agent keeps up to date. So you can ask where it's at while the session keeps working. Works with Codex and opencode too. About 10 free minutes every day, no login needed.

Not a replacement for native voice in Remote Control. I'd still love to see that.

+1, with a concrete use case: auto-play on response arrival, using the same voice as the Play / Listen button.

I run Claude Code mostly via Remote Control from my phone. The Play button on responses in the iOS app already has a great voice — including Russian, which is my working language. But it only plays on tap, so it doesn't help when I'm walking or driving and a long task finishes.

What I'd love:

• an option to auto-play the final answer (text after the last tool call) when a turn ends, in the Play voice;
• or exposing that voice to Stop/Notification hooks, so the notification I already generate can be spoken by it.

Today I work around it with a Stop hook + edge-tts, but third-party voices (and macOS say for Russian) sound noticeably worse than the built-in Play voice. Related: #92803, #88495, #98977.