Windows Codex Desktop spellcheck detects misspellings but shows No Guesses Found

Summary

Codex Desktop on Windows detects misspellings in the composer and shows the spellcheck context menu, but the menu always shows No Guesses Found instead of replacement suggestions.

This still happens after:

• confirming Windows native spellcheck works in Notepad
• confirming Windows language spellchecking is enabled for en-US
• confirming Codex preferences use en-US
• manually provisioning Chromium en-US-10-1.bdic dictionaries into both likely Codex profile locations
• normalizing Codex spellcheck preferences to en-US
• fully restarting Codex and retesting common misspellings such as speling

Reproduction

1. Open Codex Desktop on Windows.
2. Type a common misspelling in the composer, for example:

• speling
• teh
• recieve
• thoght

1. Right-click the underlined misspelled word.
2. Observe the context menu.

Actual result

The context menu shows:

• No Guesses Found
• Learn Spelling
• Search with Google
• edit commands such as Cut, Copy, Paste, Select All

No replacement suggestions are shown.

Expected result

The context menu should show correction suggestions for common misspellings, similar to Notepad/Windows spellcheck behavior on the same machine.

Environment

• OS: Microsoft Windows 11 Home
• OS version: 10.0.26200
• OS build: 26200
• Codex Desktop package: OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
• Codex Desktop version: 26.601.2237.0
• Codex executable: C:\Program Files\WindowsApps\OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0\app\Codex.exe
• Chromium/Electron runtime annotation: ver=149.0.7827.54
• Active culture: en-US
• Windows language list reports spellchecking enabled for en-US, en-IL, and he
• Windows spellcheck works in Notepad on the same machine

Profile and dictionary state

Packaged Windows app profile root:

C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex

Nested active web profile observed from Codex process/Crashpad command line:

C:\Users\<user>\AppData\Roaming\Codex\web\Codex

MSIX redirected location for that nested profile:

C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex

The official Chromium en-US-10-1.bdic dictionary was downloaded from:

https://redirector.gvt1.com/edgedl/chrome/dict/en-us-10-1.bdic

Dictionary verification:

• file size: 451,968 bytes
• magic header: BDic
• SHA-256: A075B01D9B015C616511A9E87DA77DA3D9881621DB32F584E4606DDABF1C1100

Dictionary was placed in all of these locations:

C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\en-US-10-1.bdic
C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\Dictionaries\en-US-10-1.bdic
C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\en-US-10-1.bdic
C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\Dictionaries\en-US-10-1.bdic

Codex preferences were normalized to:

{
  "spellcheck": {
    "dictionaries": ["en-US"],
    "dictionary": "en-US"
  },
  "intl": {
    "selected_languages": "en-US"
  }
}

After a full restart, the bug still reproduced.

Packaged app inspection

The packaged app.asar JavaScript was extracted for inspection only. The installed app was not modified.

Findings:

• Primary windows are created with webPreferences.spellcheck: true.
• The context menu implementation reads params.dictionarySuggestions.
• If params.misspelledWord is present but params.dictionarySuggestions.length === 0, Codex displays No Guesses Found.
• The observed UI exactly matches that fallback path, meaning Electron/Chromium is detecting a misspelled word but is returning an empty suggestion array.

Relevant behavior:

params.dictionarySuggestions.length > 0
  ? params.dictionarySuggestions.map(...)
  : { label: "No Guesses Found", enabled: false }

Searches of the extracted packaged JavaScript found no calls to:

• setSpellCheckerLanguages
• setSpellCheckerDictionaryDownloadURL
• getSpellCheckerLanguages
• availableSpellCheckerLanguages

Related Windows/MSIX path signals from local audit

The same Windows Codex install also shows other path/package fragility:

• protected packaged rg.exe exists but cannot be executed directly:

C:\Program Files\WindowsApps\OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0\app\resources\rg.exe
Access is denied

• Codex logs repeatedly report:

Windows Computer Use helper paths are unavailable

• Codex logs show a Windows path being converted to /C:/Users/... and rejected:

Invalid request: AbsolutePathBuf deserialized without a base path
path=/C:/Users/<user>/Documents/Codex/...

These may be separate bugs, but they suggest Windows Store/MSIX path redirection and protected install paths are worth checking for this spellchecker issue too.

Suggested engineering checks

1. In the actual composer webContents, log the context-menu event fields:

• params.spellcheckEnabled
• params.misspelledWord
• params.dictionarySuggestions
• session partition/name
• webContents.session.availableSpellCheckerLanguages
• webContents.session.getSpellCheckerLanguages()

1. Explicitly call, for the same session/partition used by the composer:

webContents.session.setSpellCheckerLanguages(["en-US"])

1. Verify dictionary provisioning/loading for the Windows Store/MSIX package profile and the nested web\Codex profile.

1. If Codex relies on Chromium/Electron defaults, add a Windows smoke test asserting dictionarySuggestions.length > 0 for common misspellings such as speling, teh, and recieve.

Related issue

This is related to, but more specific than, #25431. That issue asks for spellcheck settings; this issue is about suggestions being empty even when spellcheck is active, en-US is configured, dictionaries are present, and misspellings are detected.

Contact preference

The reporter would prefer a direct/private follow-up path if possible. I am intentionally not posting their email address publicly in this issue body for privacy.