CLI crashes with React error #185 during voice dictation (infinite render loop)
Claude Code Crash During Voice Dictation - React Error #185
Reported: December 24, 2025
Claude Code Version: 2.0.76
Platform: Linux (Fedora 42, kernel 6.15.9-201.fc42.x86_64)
Bug Description
Claude Code crashes with React error #185 (Maximum Update Depth Exceeded) when receiving continuous text input from voice dictation software. The CLI terminates completely, losing all dictated content.
Error Message
Error: Minified React error #185; visit https://react.dev/errors/185 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
at UQ (file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:252:16256)
at Y1 (file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:252:15769)
at _7 (file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:252:31880)
at Z9 (file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:252:31479)
at file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:2625:2046
at xA (file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:4674:620)
at onInput (file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:2587:10737)
at Object.wrappedOnInput [as current] (file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:2587:7595)
at file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:379:2516
at _i.J (file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:379:3364)
Steps to Reproduce
- Set up voice dictation software (I use
nerd-dictationwith Vosk speech recognition) - Launch Claude Code CLI
- Start voice dictation (
dictate-startornerd-dictation begin) - Dictate continuously for 30-60 seconds (rapid continuous text input stream)
- CLI crashes with React error #185
What React Error #185 Means
Per React docs: Maximum Update Depth Exceeded
- Indicates infinite rendering loop
- Component repeatedly calling setState
- React terminates to prevent browser/system crash
Root Cause (Suspected)
The continuous stream of text from voice dictation triggers rapid input events that cause the CLI's display components to enter an infinite re-render loop. The input handling code likely updates state on every character/word without proper debouncing or conditional guards.
Frequency
This has occurred 3 times during dictation sessions. It appears to be deterministic when dictating for extended periods (30+ seconds of continuous input).
Impact
- Severity: High - Complete CLI crash, data loss
- User Experience: Cannot use voice dictation reliably with Claude Code
- Workarounds:
- Dictate in short bursts (<30 seconds)
- Dictate to text editor first, then paste
- Type instead of dictate (defeats accessibility purpose)
Expected Behavior
CLI should handle rapid continuous text input without crashing, similar to how it handles fast typing or pasted content.
Additional Context
- Voice dictation is critical for accessibility and for users who process thoughts better verbally than through typing
- This bug makes Claude Code unusable for voice-based workflows
- The minified error message makes debugging difficult - development build would help identify exact component
Suggested Fix
- Add debouncing to input handling
- Add conditional guards in component lifecycle methods (componentDidUpdate, etc.)
- Use proper dependency arrays if using React hooks
- Provide development build for better error messages during debugging
Environment
- OS: Fedora Linux 42
- Kernel: 6.15.9-201.fc42.x86_64
- Claude Code: 2.0.76
- Voice Dictation: nerd-dictation with vosk-model-small-en-us-0.15
- Terminal: Gnome Terminal (default)
---
User Impact Statement:
I rely on voice dictation for processing complex thoughts and trauma work. Having Claude Code crash mid-session interrupts critical therapeutic/creative work and creates data loss. This bug makes the tool unusable for its most valuable use case for me.
19 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is not a duplicate of #13183. Related root cause (voice-to-text input handling), but distinct symptoms:
#13183 (Bracketed Paste Hang)
kill -9to terminate[201~escape codes appear in promptkevent64kernel call#15307 (This Issue - React Error #185)
Why These Are Different
#13183 = Terminal/TUI-level paste sequence handling failure → process hang
#15307 = React component-level state update loop → crash during rapid input
Both involve voice-to-text tools, but the failure mechanisms are distinct. This issue specifically documents the React rendering problem during voice dictation, which is a separate bug from the bracketed paste hang.
Reproduction Specific to This Issue
nerd-dictationwith Vosk speech recognitionThese may share a common root in input handling, but the symptoms and fixes will be different. Please keep this issue open as a distinct bug report.
I am having this issue also using STT. My guess is that it has something to do with how fast the input is going into the text area. It could be related to fixes for #4851, I am not sure if this was an issue a few months ago. @Mamangel have you been using Claude-Code + STT/Diction for over a few months?
I have also found that the longer the dictation the more frequent this error. This bug did not always happen and was not appearing in Oct/Nov 2025.
@zinglax Yes, I've been using Claude Code + nerd-dictation (Vosk STT) since early October 2025 without any issues. This crash started suddenly in late December 2025 - voice dictation worked perfectly for ~2 months before that.
Timeline:
This aligns with your observation that the bug didn't exist in Oct/Nov 2025. Given that it appeared suddenly after working fine for months, I agree this was likely introduced by a recent update/change to Claude Code.
Additional context:
nerd-dictationwith Vosk model (vosk-model-small-en-us-0.15)The fact that this worked consistently for 2+ months and then suddenly started crashing suggests a regression in recent Claude Code releases. This strengthens the case that this is NOT a duplicate of the older bracketed paste issue #13183, but rather a new bug introduced in a recent update.
Thanks @Mamangel for that context, I agree that there has been a regression here. This is a new bug.
Thank you for sharing you STT setup (nerd-diction w/ Vosk Model), I "claude coded" a custom STT setup that uses the
faster-whispermodel in python and have no issues with dictations in other text fields or the command line itself.This makes me think that it is STT independent, it is something to do with how claude code accepts input.
Confirmed that it is STT independent – this is also happening to me on Voxtype using
ydotoolto type on an X11 desktop. (I only started using this dictation setup a couple days ago though, so I can't confirm it was working before)Confirmed this bug still exists in v2.1.1
Update: Dictation working on v2.1.1
Just tested on Claude Code v2.1.1 (released Jan 6, 2026) - dictation is working perfectly for me.
My setup:
Test details:
Previously (Oct-mid Dec) this same setup worked fine. Late December it started crashing with React error #185. As of tonight (Jan 7, 8:01 PM EST), it's working again.
Either the fix in v2.1.1 resolved it for my setup, or there's something specific about the other users' configurations triggering the bug. Worth noting for troubleshooting.
Happy to provide more diagnostic info if helpful!
hey thanks for the note, I will try to repro again on my setup. I might also have been using some of the older 2.0.76 sessions while some of my newer conversations had updated to 2.1.1. Will try some long winded dictation!
https://github.com/user-attachments/assets/70c8534d-8b09-45b5-8f46-7806deff434f
Okay so I just tried again on v2.1.1 and this error still persists. I would say no change for this issue for me between v2.0.76 and v2.1.1.
My setup:
Test details:
Note
I have noticed that the longer the input the more likely for this error to happen.
Confirmed on Omarchy 3.3.3 w/ voxtype 0.4.9-1.
Setup: Hyprland 0.53.1 (wayland) | voxtype using wtype for text insertion | ALSA -> Pipewire route for audio via .asoundrc
Reproduced: 100% crash when dictation wraps to the second line and text reaches ~2/3-3/4 across the screen.
The voxtype install is fresh w/ omarchy 3.3 (1-8-2026), reproduced consistently when dictation is at least long enough to reach the end of line 2.
Update: Actually, upon reading that there was a newer version of CC (Bug was reproduced on v2.0.76) in @zinglax 's comment, I updated to v2.1.2 and the crash is no longer being reproduced.
Note for other Omarchy users: Omarchy is currently shipping 2.0.76 from the repo, but you can upgrade to the latest version using ``
yay -S aur/claude-code``@dylanpbrown I will try again with v2.1.2
I confirmed that this error is still happening in v2.1.5. the linked issue #17500 might actually be what we are running into now. It is seeming like it has more to do with the length of the input rather than the speed at which the input is put in. Once the input gets to a certain length then it becomes a problem. I wonder if you just type a certain amount if it would happen.
It also happens to me while using ydotool for dictation, in v2.1.5. Luckily it doesn't happen all that often and often happens when I'm in a long session already, maybe with some task running a long time, and I dictate a pretty long text. It doesn't always happen and I've dictated very long texts that were typed very fast (2ms per char) without it crashing. So I'm not sure what is causing this.
It also doesn't prevent me from using dictation with Claude Code, but it certainly makes it a bit more annoying. I still love it, though!
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.