[BUG] Spell checking cannot be turned off, making all entered text hard to read

Please find below a list of Claude's suggestions that did NOT work for me:

1. Go to Windows Settings → Time & Language → Typing → turn off "Highlight misspelled words". (didn't help)

<img width="1548" height="905" alt="Image" src="https://github.com/user-attachments/assets/605dde7d-ba76-4ba0-97ac-aa5f8241983a" />

1. Created settings.json with ELECTRON_ENABLE_SPELLCHECKING=0. (didn't help)

{
  "env": {
    "ELECTRON_ENABLE_SPELLCHECKING": "0"
  }
}

1. Add English language (didn't help)

<img width="1560" height="751" alt="Image" src="https://github.com/user-attachments/assets/a77d0d96-cc68-4fed-b645-94ff2545e5cc" />

This happens in macos, too. MacOS version 15.7.7 (24G720)
In systems settings > Keyboard > Input Sources > Text Input "Correct spelling automatically" is already disabled.
The red lines still appear in In Claude 1.11187.4 (584005) 2026-06-05T20:15:04.000Z

Since I am frequently switching between languages and using all kinds of lingo, spell-checking is more of a nuisance then a help.

Adding a third gap not yet covered here: no correction suggestions.

The input field currently underlines misspelled words but right-clicking
offers no spelling suggestions — making the spell checker a passive
annoyance rather than a useful tool, especially for multilingual users
writing in a language different from their OS locale.

This is directly tied to the two gaps already tracked in this issue:

• Language selection is a prerequisite — suggestions are only useful

if the correct dictionary is active

• On/off toggle gives users full control over the feature

Proposed UX: standard right-click context menu on underlined words
with ranked suggestions from the active dictionary.

Electron ships Chromium's spellcheck engine which natively supports this —
it's already the default behavior in VS Code, Slack, and Notion.
The underlining is there; surfacing suggestions is the missing last step.

Suggested config (aligned with the proposals above):

\``json
"spellcheck": {
"enabled": true,
"languages": ["en-US", "fr-FR"]
}
\``

Environment: Windows 11, Claude Code Desktop

Same in Czech language, I can't simply turn it off :-(

Same in Czech language, I can't simply turn it off :-(

Add cz dict, az shown here
https://github.com/anthropics/claude-code/issues/60012#issuecomment-4911823918

Or without a script: close all Claude processes, open %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\Preferences, add "en-US" to the spellcheck.dictionaries-array

still not fixed on Claude Desktop for Windows.

this is still a problem. i don't want any spellchecking whatsoever. it's just a nuisance.

@ssg Could you try the workaround 2 comments above yours and remove the locale code instead of changing it?

@ssg Could you try the workaround 2 comments above yours and remove the locale code instead of changing it?

@ygoe Didn't work. If I remove the only "en-US" entry from the dictionary, Claude Code puts it back. If I remove the whole spellcheck entry, Claude Code puts it back with "en-US".

EDIT: I instead replaced "en-US" with "xx-XX" and that seems to have disabled spellcheck completely, FYI.

Unfortunately this approach is not available on MacOS. It would be great if there was a toggle switch in the app. That would remove the need for any workaround regardless of the platform.

@ssg Thanks for the update. Setting an invalid value would have been my next suggestion. Glad that it worked. I might need it as well.

@ssg's suggestion indirectly worked for me on Mac OS, i replaced en-US with "xx-XX" and added "browser": { "enable_spellchecking": false } but when I reopened Claude, en-US was back again. but it automatically added use_spelling_service":false and now it's gone!

@ashleys0 thank you very much, I can confirm that this works on MacOS. For anyone wondering about the specifics on MacOS:

In Finder, choose Go > "Go to Folder…" and open: ~/Library/Application Support/Claude/

There you will find a file "Preferences" without a filetype extension, but containing effectively JSON syntax. You can edit the in TextEdit, but be aware that there are no linebreaks.
Note: don't accidentially add a .json extension or Claude will not accept the file.
Then it is exactly as ashleys0 said: modify "en-US", add the line with "browser ...". Open Claude. Spellcheck will be back on and the Preferences file will be reset to en-US. Close Claude and reopen. Spellcheck will be gone and the third line with "use_spelling_service" will have been added by Claude automatically, causing Spellcheck to be a thing of the past. Thank you all for helping!

Filed #88502 for the related case: rather than turning spellcheck off entirely, allow several dictionaries at once, so English stays checked while a second language stops being flagged. Electron's setSpellCheckerLanguages already takes an array — an "off" option and a multi-language option could land in the same setting.

Worth noting for this issue too: the %APPDATA%\Claude\Preferences workaround no longer works. I set spellcheck.dictionaries to ["en-US","nb"] and the running app rewrote it back to ["en-US"] within half an hour, no restart involved.

Workaround: turning the spell checker off in Claude Desktop on Windows — one setting, no admin rights

Reported several times: #35706, #67902, #68621, #72247, #88502.

Updated: this now uses Chromium's own browser.enable_spellchecking key directly. My earlier versions of this comment went the long way round — first a filesystem-permissions hack, then the xx-XX trick. Both worked, but the trick only worked because it made the app write this key by itself. Setting it directly is simpler, honest about what it does, and survives app updates.

The same approach was already being used on macOS earlier in this thread. What follows is the Windows version, the mechanism, and what the dead ends were.

---

The method

All commands below go into Windows PowerShell, as your normal user — no "Run as administrator" needed. To open it: press Win+X and pick Terminal or Windows PowerShell, or press Win, type powershell and hit Enter. Paste one command at a time and press Enter.

1. Fully exit Claude. Not just the window — the tray icon too. This matters: Chromium keeps Preferences in memory and flushes it to disk periodically, so an edit made while the app is running gets overwritten. Verify nothing is left:

Get-Process *claude* -EA SilentlyContinue | Stop-Process -Force; Start-Sleep 4; "running: " + (Get-Process *claude* -EA SilentlyContinue | Measure-Object).Count

Must print 0.

2. Turn spell checking off. This one-liner finds the profile, backs up Preferences to your Desktop, and sets the key:

$r = @("$env:APPDATA\Claude") + (Get-ChildItem "$env:LOCALAPPDATA\Packages" -Directory -Filter "Claude_*" -EA SilentlyContinue | % { "$($_.FullName)\LocalCache\Roaming\Claude" }) | ? { Test-Path "$_\Preferences" } | Select-Object -First 1; Copy-Item "$r\Preferences" "$env:USERPROFILE\Desktop\Preferences-backup" -Force; $j = Get-Content "$r\Preferences" -Raw | ConvertFrom-Json; if(-not $j.browser){ $j | Add-Member -NotePropertyName browser -NotePropertyValue ([pscustomobject]@{}) -Force }; $j.browser | Add-Member -NotePropertyName enable_spellchecking -NotePropertyValue $false -Force; [System.IO.File]::WriteAllText("$r\Preferences", ($j | ConvertTo-Json -Depth 100 -Compress), (New-Object System.Text.UTF8Encoding($false))); "PROFILE: $r"; "browser: " + ((Get-Content "$r\Preferences" -Raw | ConvertFrom-Json).browser | ConvertTo-Json -Compress)

It should print two lines: PROFILE: followed by the path it found, and browser: {"enable_spellchecking":false}. If no PROFILE: path appears, the app has never been run on this account yet — start Claude once, close it fully, and run the command again.

<details>
<summary>Prefer to edit the file by hand?</summary>

This read-only command prints the path to your profile (it changes nothing):

@("$env:APPDATA\Claude") + (Get-ChildItem "$env:LOCALAPPDATA\Packages" -Directory -Filter "Claude_*" -EA SilentlyContinue | % { "$($_.FullName)\LocalCache\Roaming\Claude" }) | ? { Test-Path "$_\Preferences" } | Select-Object -First 1

The file may sit under %APPDATA%\Claude or under %LOCALAPPDATA%\Packages\Claude_*\LocalCache\Roaming\Claude — it varies between installs, which is why the command checks both.

Open Preferences there (no file extension, JSON on a single line), back it up first, and set:

"browser": { "enable_spellchecking": false }

</details>

3. Start Claude and type a few words — type them, don't paste; pasted text isn't spell-checked at all (see below). The underlines are gone.

To undo, close Claude and run the command from step 2 with $true in place of $false, or restore Preferences-backup from your Desktop:

$r = @("$env:APPDATA\Claude") + (Get-ChildItem "$env:LOCALAPPDATA\Packages" -Directory -Filter "Claude_*" -EA SilentlyContinue | % { "$($_.FullName)\LocalCache\Roaming\Claude" }) | ? { Test-Path "$_\Preferences" } | Select-Object -First 1; Get-Process *claude* -EA SilentlyContinue | Stop-Process -Force; Start-Sleep 3; Copy-Item "$env:USERPROFILE\Desktop\Preferences-backup" "$r\Preferences" -Force; "restored"

<details>
<summary><b>⚠️ How to test this — pasted text is NOT spell-checked</b></summary>

This cost me an hour, so it's worth its own section. Pasting text into the input box does not trigger a spell check. Paste the worst gibberish you like and nothing is underlined. The check only runs on a line once you type into it. The same applies to generated documents in the side panel: nothing is flagged until you click into the text.

So when verifying, type by hand (or type a few extra characters into each pasted line). Otherwise "no underlines" means nothing at all, and you will happily conclude that a workaround works when it doesn't.

Test with a language you are not writing in. If you only type Slovak and Slovak is the checked language, correct text looks identical whether checking is on or off. Two lines that settle it:

The weather is beautiful today.
I recieve a lot of mesages every day.

Another quirk worth knowing: words in ALL CAPS are never flagged. Chromium treats them as acronyms. AHOJ is clean, ahoj is not — that is not a sign that your language is being checked.

</details>

<details>
<summary><b>Why it works, and why the other approaches were misleading</b></summary>

browser.enable_spellchecking is Chromium's own on/off switch for local spell checking. Claude Desktop doesn't expose it in Settings, but it reads it, and it does not overwrite it.

What confused this thread, including me:

• spellcheck.dictionaries is a separate thing, and it is honoured. A valid list survives a restart: ["en-US","sk"] stayed untouched, with English checked and Slovak not.
• An empty list is refilled from the OS language on the next launch. This is what several of us reported as "the app ignores the file". It does not; it fills in a blank.
• A list of only unknown codes (xx-XX, nn) ends up empty after filtering, and the app then writes browser.enable_spellchecking: false itself. That's why the xx-XX trick worked at all — it was an indirect way of setting the key above. Setting the key directly skips the detour.

Proof that the key, not the trick, is what holds: after an app update my dictionaries had been refilled to ["sk"] while enable_spellchecking stayed false, and nothing was underlined. Flipping that key to true brought the underlines straight back with the same dictionary list, and flipping it to false removed them again.

One more finding I haven't seen written down: spellcheck.dictionaries also controls the Windows platform spell checker, not just Hunspell. Adding en-US switched English checking on with no .bdic anywhere on disk.

</details>

<details>
<summary><b>Verified</b></summary>

• Survives app updates. Set on 2.110.1.0, still in force on 2.9939.2.0 (MSIX) after the app updated itself, even though spellcheck.dictionaries had been rewritten in the meantime.
• Works whether or not Windows has a spell checker for your language. Tested with Language.Basic~~~sk-SK installed and removed. No Windows language components need to be touched — if you removed any for an earlier workaround, you can put them back with Add-WindowsCapability -Online -Name "Language.Basic~~~sk-SK~0.0.1.0".
• Reaches the side-panel document editor, not just the chat input — the same setting covers both.

</details>

---

If you'd rather keep spell checking, just in more languages

There is a second workaround in this thread for that: leave enable_spellchecking alone and put both languages in the list, e.g. "dictionaries": ["en-US","nb"], with the app fully closed. Chromium only flags a word when it's missing from all of the loaded dictionaries, so both languages read clean and real typos still get caught. See this comment and #88502.

With the app fully closed (step 1 above), this sets the list for you. As written it sets English (US) + Slovak; find @("en-US","sk") in the command and put your own codes there:

$r = @("$env:APPDATA\Claude") + (Get-ChildItem "$env:LOCALAPPDATA\Packages" -Directory -Filter "Claude_*" -EA SilentlyContinue | % { "$($_.FullName)\LocalCache\Roaming\Claude" }) | ? { Test-Path "$_\Preferences" } | Select-Object -First 1; Copy-Item "$r\Preferences" "$env:USERPROFILE\Desktop\Preferences-backup" -Force; $j = Get-Content "$r\Preferences" -Raw | ConvertFrom-Json; if(-not $j.spellcheck){ $j | Add-Member -NotePropertyName spellcheck -NotePropertyValue ([pscustomobject]@{}) -Force }; $j.spellcheck | Add-Member -NotePropertyName dictionaries -NotePropertyValue @("en-US","sk") -Force; $j.spellcheck | Add-Member -NotePropertyName dictionary -NotePropertyValue "" -Force; if($j.browser){ $j.browser | Add-Member -NotePropertyName enable_spellchecking -NotePropertyValue $true -Force }; [System.IO.File]::WriteAllText("$r\Preferences", ($j | ConvertTo-Json -Depth 100 -Compress), (New-Object System.Text.UTF8Encoding($false))); "PROFILE: $r"; "spellcheck: " + ((Get-Content "$r\Preferences" -Raw | ConvertFrom-Json).spellcheck | ConvertTo-Json -Compress)

Use the short code where a language has only one dictionary (sk, pl, nb) and the regional one where it doesn't (en-US, en-GB). An unknown code is silently dropped — and if every code in the list is dropped, you get the off switch from the top of this comment instead of what you wanted, so check the printed result.

---

<details>
<summary><b>Dead ends — tested, don't bother</b></summary>

Setting spellcheck.dictionaries to []. Refilled from the OS language on the next launch.

Setting spellcheck.use_spelling_service to false. No effect on its own. The app writes this key alongside the real one, which makes it look like the off switch. It isn't — with enable_spellchecking back at true, flipping this one changes nothing.

Chromium feature flags. The MSIX package has no execution alias, but flags can be injected with Invoke-CommandInDesktopPackage. --disable-features=WinUseBrowserSpellChecker,UseBrowserSpellChecker demonstrably reaches the main process and every renderer (visible on their command lines) and changes nothing.

Reordering the Windows preferred-language list. I added Latin (la-VA), which has no Windows spell checker at all, and later English (Australia) with its Basic typing removed, and put each at the top. Both appeared first in the app's own preferredSystemLanguages and the app still launched with --lang=sk. The app follows the Windows display language, not the list order.

Spellchecking per language in Get-WinUserLanguageList / Set-WinUserLanguageList. The property is writable and the change persists, but has no effect on the app. Any later change to the language list silently resets it to True.

Enterprise policy. The documented keys under HKLM\SOFTWARE\Policies\Claude cover updates, extensions, MCP and login. There is no spell-check key.

DevTools. Ctrl+Shift+I, F12, Ctrl+Shift+C don't open them in the production build.

Right-click on an underlined word. Suggestions and "Add to dictionary" only. No toggle.

Editing anything in C:\Program Files\WindowsApps. Breaks the MSIX signature and is overwritten by the next update.

The filesystem-permissions hack from my first version of this comment — replacing the downloaded .bdic with an empty file and locking the Dictionaries folder with a Deny ACE. It works, but it only applies when Chromium is using Hunspell, and making it apply otherwise meant removing Windows language components (admin rights, and you lose handwriting, OCR and text-to-speech for that language). Don't. If you already did it, removing the Deny rules on Dictionaries undoes it.

A note on removing Windows language components, if you end up doing it for some other reason: Remove-WindowsCapability fails with Permanent package cannot be uninstalled when other capabilities depend on Basic typing (Handwriting, OCR, TextToSpeech, Speech). Remove those first and it goes through. The error text is misleading — the package isn't permanent.

</details>

<details>
<summary><b>Not verified</b></summary>

• behaviour on a non-MSIX install
• languages other than Slovak, English and Norwegian
• whether an app update ever rewrites browser.enable_spellchecking itself (it survived one update here, and spellcheck.dictionaries was rewritten in the same period, so the two are clearly treated differently)

</details>

---

Tested on Claude Desktop 2.110.1.0 and 2.9939.2.0 (MSIX), Windows 11 Home 10.0.26200, Slovak display language.

It's still a workaround: invisible to anyone who doesn't find this thread, and it means hand-editing a JSON file with the app closed. The real fix is a Spell check: on/off switch in Settings, ideally with a language picker — the app already reads both prefs, and session.setSpellCheckerEnabled and setSpellCheckerLanguages are right there in Electron. Please keep this issue open.

Alternative workaround that keeps spellcheck on instead of disabling it.

Chromium supports multiple simultaneous dictionaries, and it only underlines a word when it's missing from all of them. So instead of enable_spellchecking: false, you can just add your second language. Tested on Windows with English + Norwegian Bokmål, and it does what you'd expect: English text is clean, Norwegian text is clean, actual typos in either language still get flagged.

On the reports that the Preferences edit gets reverted: I think that's a timing issue rather than the app enforcing en-US. Chromium's PrefService loads Preferences into memory at launch and flushes it back to disk periodically, so an edit made while the app is running gets overwritten by the in-memory copy on the next flush. @malinfossum's note that it reverted "within half an hour, no restart involved" fits that pattern. Chrome behaves the same way. I can't rule out that the app also sets the language at startup on some builds, but a clean edit stuck for me.

Steps on Windows:

1. Fully exit Claude, including the tray icon. Confirm no claude.exe is left in Task Manager.
2. Edit %APPDATA%\Claude\Preferences (JSON, no line breaks) and set:

"spellcheck": { "dictionaries": ["en-US", "nb"], "dictionary": "" },
"browser": { "enable_spellchecking": true }

1. Start Claude and type a few words in the second language.

Two things that can make it look like it failed:

• The Hunspell dictionary isn't bundled. Chromium downloads the .bdic on first use into %APPDATA%\Claude\Dictionaries\. If that request is blocked (corporate proxy, filtered network), the language is listed but nothing is actually checked against it. Check that the file appeared.
• Use the codes from Chromium's supported list, not OS locale names. nb for Norwegian Bokmål, for example. There's no Nynorsk dictionary.

This also covers most of what #88502 is asking for, at least as a manual workaround. The setting UI would still be the right fix, since this survives app updates but is invisible to anyone who doesn't find this thread.

PS: I did this with a script, but it's sanitized for my machine and nobody else, so I'd rather you control your own environment. :)

Confirmed on Windows 11, Claude Desktop 2.2553.1 (MSIX): ["en-US","nb"] in Preferences sticks when the app is fully closed before the edit, and both languages are checked at once — English clean, Norwegian clean, real typos in either still underlined.

That also means my note above was wrong about the cause. I edited the file while the app was running, so what I saw was the in-memory copy being flushed back over my edit, not the app enforcing en-US. Thanks for the correction.

One detail for anyone whose Dictionaries folder stays empty (or never appears) after this: if Windows has "Basic typing" installed for the language, Chromium uses the platform spell checker and never downloads a .bdic. That is not a failure — the check still works.

Still a workaround, not a fix: it is invisible unless you find this thread. I've updated #88502 to point here.

This issue is still there. I dont get it, the need to edit some hidden json file just to add a language is moronic. Simple check box to disable spellchek is not that hard to implement.

I completely agree. But for now, we have the solution in two steps, all automated through PowerShell. See my comment in the thread above.

How is it possible that this still isnt fixed?

It's driving me insane to have to look at these damn lines all day long... Wtf....

Same problem here on Windows 11 with the Claude desktop app (Spanish UI, Spanish (Spain) installed as a preferred language).

Turning off "Highlight misspelled words" and "Autocorrect misspelled words" under Time & language > Typing changes nothing, and I restarted the app. Right-clicking an underlined word only shows suggestions and "Add to dictionary", so there is no way to turn the checker off or pick its language from the app.

Having everything I write underlined in red is tiring and stressful to look at all day. Could you add a setting to disable spell check, or at least to choose its language?

Same pain here on Windows 11 (Norwegian + English). There is a partial workaround for the language part: the desktop app reads a "dictionaries" list from its config, and a valid list like ["en-US","nb"] survives app updates. Path and details are in #88502, which asks for a proper language picker in the app.

Since this issue haven't been fixed yet, and in the hope that people might benefit, I choose to post the script I used to try to make a fix easier to implement (at your own risk).
Been confirmed for Norwegian language, and has worked for me ever since through multiple reboots and updates (for now).

The language codes should be ISO 639 combined with ISO 3166-1 country codes to identify language dictionaries Hunspell

Substitute the nb with whatever language you need added in this line:

$json.spellcheck | Add-Member -NotePropertyName dictionaries -NotePropertyValue @('en-US','nb') -Force

For example fr, de, and nl should work - even without the country-specific code after like fr-FR, de-AT or similar syntax.

Run as your normal user, not elevated. Make sure Claude sessions, tasks, etc. are not running at the time.

$prefs = "$env:APPDATA\Claude\Preferences"

# Claude Desktop and Claude Code are both claude.exe; Desktop is the MSIX install under WindowsApps,
# Code lives in ~\.local\bin, so matching on the path closes Desktop only
$desktop = Get-Process claude -ErrorAction SilentlyContinue | Where-Object { $_.Path -like '*\WindowsApps\Claude_*' }
$desktop | Stop-Process -Force
# Desktop rewrites Preferences on exit, so wait until it is actually gone rather than sleeping a fixed time
$desktop | Wait-Process -Timeout 15 -ErrorAction SilentlyContinue

Copy-Item $prefs "$prefs.bak" -Force

$json = Get-Content $prefs -Raw | ConvertFrom-Json

if (-not $json.spellcheck) {
    $json | Add-Member -NotePropertyName spellcheck -NotePropertyValue ([pscustomobject]@{})
}
$json.spellcheck | Add-Member -NotePropertyName dictionaries -NotePropertyValue @('en-US','nb') -Force
$json.spellcheck | Add-Member -NotePropertyName dictionary   -NotePropertyValue ''             -Force

if (-not $json.browser) {
    $json | Add-Member -NotePropertyName browser -NotePropertyValue ([pscustomobject]@{})
}
$json.browser | Add-Member -NotePropertyName enable_spellchecking -NotePropertyValue $true -Force

# .NET write avoids the BOM that Set-Content adds on PS 5.1
[System.IO.File]::WriteAllText($prefs, ($json | ConvertTo-Json -Depth 20 -Compress))