CLI crashes with React error #185 during voice dictation (infinite render loop)

Resolved 💬 19 comments Opened Dec 24, 2025 by Mamangel Closed Feb 27, 2026

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

  1. Set up voice dictation software (I use nerd-dictation with Vosk speech recognition)
  2. Launch Claude Code CLI
  3. Start voice dictation (dictate-start or nerd-dictation begin)
  4. Dictate continuously for 30-60 seconds (rapid continuous text input stream)
  5. 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

  1. Add debouncing to input handling
  2. Add conditional guards in component lifecycle methods (componentDidUpdate, etc.)
  3. Use proper dependency arrays if using React hooks
  4. 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.

View original on GitHub ↗

19 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/13921
  2. https://github.com/anthropics/claude-code/issues/14961
  3. https://github.com/anthropics/claude-code/issues/13183

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Mamangel · 6 months ago

This is not a duplicate of #13183. Related root cause (voice-to-text input handling), but distinct symptoms:

#13183 (Bracketed Paste Hang)

  • CLI hangs and becomes unresponsive
  • Requires kill -9 to terminate
  • Literal [201~ escape codes appear in prompt
  • Process blocks in kevent64 kernel call

#15307 (This Issue - React Error #185)

  • CLI crashes with React error #185 (Maximum Update Depth Exceeded)
  • Complete process termination (no hang)
  • Stack trace shows React component infinite render loop
  • Triggered by continuous voice dictation input stream

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

  1. Use nerd-dictation with Vosk speech recognition
  2. Dictate continuously for 30-60 seconds
  3. CLI crashes with React error #185 stack trace (not a hang)

These 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.

zinglax · 6 months ago

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?

zinglax · 6 months ago

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.

Mamangel · 6 months ago

@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:

  • Oct - mid-Dec 2025: Voice dictation worked flawlessly, no crashes
  • Late Dec 2025: React error #185 crashes started appearing during dictation sessions
  • Pattern: Longer dictation sessions (30-60+ seconds) → higher crash frequency

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:

  • Using nerd-dictation with Vosk model (vosk-model-small-en-us-0.15)
  • No changes to dictation setup between working period and crash period
  • Only variable was Claude Code updates

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.

zinglax · 6 months ago

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-whisper model 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.

sobjornstad · 6 months ago

Confirmed that it is STT independent – this is also happening to me on Voxtype using ydotool to 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)

zinglax · 6 months ago

Confirmed this bug still exists in v2.1.1

Mamangel · 6 months ago

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:

  • STT: nerd-dictation with Vosk model (vosk-model-small-en-us-0.15)
  • Claude Code version: 2.1.1
  • OS: Fedora 42 (Linux 6.15.9)
  • Input method: xdotool

Test details:

  • Long dictation session (~200+ words, continuous stream)
  • Rapid speech (I talk fast and go on tangents)
  • No crashes, no backtracking
  • Picked up speech accurately with minimal missed words

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!

zinglax · 6 months ago

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!

zinglax · 6 months ago

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:

  • STT: whisper-coder (custom tool) with faster-whisper (model: base, device: cpu, compute_type: int8)
  • Claude Code version: 2.1.1
  • OS: Pop!_OS 22.04 LTS (Linux 6.17.4-76061704-generic)
  • Input method: xdotool
  • Keybind: Ctrl+Space

Test details:

  • As seen in the video, 2 long winded inputs using STT.
  • Note that I edited this video to get rid of the time I spent actually speaking, the total time of the original video was over 1-2 minutes. There was at least 30-40s between the first and second message while I was speaking

Note
I have noticed that the longer the input the more likely for this error to happen.

dylanpbrown · 6 months ago

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.

dylanpbrown · 6 months ago

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``

zinglax · 6 months ago

@dylanpbrown I will try again with v2.1.2

zinglax · 6 months ago

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.

fvieira · 6 months ago

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!

github-actions[bot] · 5 months ago

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.

github-actions[bot] · 4 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

github-actions[bot] · 4 months ago

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.