[Bug] Desktop app 26.616: new conversations fail with "Invalid request: missing field \inputSchema`" (CLI with same config works)`

i would like to further emphasize that:

Workaround + sharper repro: create in CLI, continue in the app

The CLI and desktop app share one thread store (state_5.sqlite + ~/.codex/sessions/*.jsonl).
A conversation created in the CLI (codex in the project dir) appears in the desktop app and
can be opened/continued there normally — the app loads it via its resume path.

This gives:

• A usable workaround: seed new conversations from the CLI, then continue them in the app GUI,

despite the app being unable to start new conversations itself.

• A sharper localization of the bug: the missing field inputSchema failure happens only on the

app's thread/start (new-conversation) path, where it injects its codex_app dynamic tools.
Resume of the very same thread does not fail — so the malformed tool is injected only during
new-thread tool-list assembly, not on resume.

I can confirm the same failure on Windows with the Microsoft Store build.

Installed package:

• OpenAI.Codex_26.616.3309.0_x64__2p2nqsd0c76g0
• Store product ID via winget: 9PLM9XGG6VKS
• Desktop client/version observed in logs: 26.616.30709

Behavior:

• Existing chats continue to work.
• New chats fail immediately with:

Invalid request: missing field inputSchema

• The renderer/app log shows the failure on:

method=thread/start
conversationId=null
errorCode=-32600
error={"code":-32600,"message":"Invalid request: missing field inputSchema"}

• The UI-side failure path includes:

Error creating local task ... handleSubmitLocal
[Composer] submit failed cwd=~ ... mode=local

Things ruled out locally:

• Full quit/restart.
• Clearing Codex plugin/cache/temp marketplace state.
• Removing/resetting AppData\Roaming\Codex.
• Resetting selected .codex state including config.toml, .codex-global-state.json, models_cache.json, cache, .tmp, plugins, browser/computer-use/plugin appserver state.
• Recreated state still fails in exactly the same way.

This seems consistent with the issue description: the failure happens before a new local thread is created, and appears tied to app-injected dynamic tools during thread/start, not user config.

same issue here. I moved my Codex home from C: to G:\CodexHome and set CODEX_HOME accordingly.

The CLI works and writes sessions under G:\CodexHome, but Codex Desktop 26.616 still fails when creating a new conversation or starting a task:

• Invalid request: missing field inputSchema

• Existing conversations can still be opened, and conversations created via codex exec from the CLI can appear in Desktop and continue normally. The failure seems specific to the Desktop new-thread / start-task flow.

I also tried disabling apps/plugins/browser/computer-use features and cleaning up stale C:\Users\...\Documents\Codex paths in config/state, but the Desktop app still shows the same inputSchema error when creating a new conversation.

So this looks like a Desktop-side regression rather than only a CODEX_HOME/path migration issue. Would appreciate a fix, since using a CLI-seeded thread is only a workaround.

I have also the same problem....please solve it quickly.....

Same problem with automations.

Automations also fail because they seem to require starting a new conversation/thread, and that currently fails with:

Invalid request: missing field inputSchema

Existing conversations still work, but anything that needs to create a new conversation/thread appears to be broken. This affects both manually creating a new chat and scheduled/recurring automations.

Finally got it working.

In my case, Codex Desktop was launching an old CLI because CODEX_CLI_PATH was pinned to a stale binary in my Windows
user environment:

HKCU\Environment\CODEX_CLI_PATH

It pointed to an older codex.exe (0.135.0-alpha.1) while the installed app/runtime expected a newer one (0.142.0-
alpha.1). That version mismatch made thread/start fail with:

Invalid request: missing field inputSchema

What fixed it for me:

reg delete HKCU\Environment /v CODEX_CLI_PATH /f

Also check/remove/update any stale CODEX_CLI_PATH entry in:

C:\Users\<user>\.codex\config.toml

Then fully quit/reopen Codex, or restart Windows so the old environment variable is gone from running processes.

Only remove CODEX_CLI_PATH if it points at an old Codex binary; otherwise update it to the current codex.exe path.
Hopefully this helps anyone else experiencing this issue.

Finally got it working. In my case, Codex Desktop was launching an old CLI because CODEX_CLI_PATH was pinned to a stale binary in my Windows user environment: HKCU\Environment\CODEX_CLI_PATH It pointed to an older codex.exe (0.135.0-alpha.1) while the installed app/runtime expected a newer one (0.142.0- alpha.1). That version mismatch made thread/start fail with: Invalid request: missing field inputSchema What fixed it for me: reg delete HKCU\Environment /v CODEX_CLI_PATH /f Also check/remove/update any stale CODEX_CLI_PATH entry in: C:\Users<user>.codex\config.toml Then fully quit/reopen Codex, or restart Windows so the old environment variable is gone from running processes. Only remove CODEX_CLI_PATH if it points at an old Codex binary; otherwise update it to the current codex.exe path. Hopefully this helps anyone else experiencing this issue.

I deleted the registry value with reg delete and rebooted my computer, and it started working normally again. Thanks.

Finally got it working. In my case, Codex Desktop was launching an old CLI because CODEX_CLI_PATH was pinned to a stale binary in my Windows user environment: HKCU\Environment\CODEX_CLI_PATH It pointed to an older codex.exe (0.135.0-alpha.1) while the installed app/runtime expected a newer one (0.142.0- alpha.1). That version mismatch made thread/start fail with: Invalid request: missing field inputSchema What fixed it for me: reg delete HKCU\Environment /v CODEX_CLI_PATH /f Also check/remove/update any stale CODEX_CLI_PATH entry in: C:\Users<user>.codex\config.toml Then fully quit/reopen Codex, or restart Windows so the old environment variable is gone from running processes. Only remove CODEX_CLI_PATH if it points at an old Codex binary; otherwise update it to the current codex.exe path. Hopefully this helps anyone else experiencing this issue.

it works for me

I had Codex repair itself using the instructions from Fixlation, and it fixed the problem on its own. Thank's Fixlation!

happens only for new sessions, after the update. win/wsl

<img width="536" height="215" alt="Image" src="https://github.com/user-attachments/assets/06a605be-71ea-463e-8ad0-dc2ffd89af7b" />

Title: Desktop app 26.616.4196.0 cannot start new conversations: “Invalid request: missing field inputSchema”

I can reproduce this on Windows with Codex Desktop 26.616.4196.0.

After the recent auto-update, starting a new conversation or new project fails immediately with the toast:
“Invalid request: missing field inputSchema”

Existing conversations still work, and restarting the app does not fix it.

I verified that the same ~/.codex/config.toml works in CLI (codex exec / codex mcp list) with no error, so this appears to be specific to the desktop app’s thread-start / app-server tool loading path.

I also checked the desktop logs, which show:

• method=thread/start
• errorCode=-32600
• Invalid request: missing field \inputSchema\``
• Failed to prewarm conversation
• Error creating local task

I already ruled out local config and cache issues:

• clearing the bundled marketplace cache did not fix it
• restarting the app did not fix it
• CLI with the same config still works

This looks like a desktop-app-specific issue in app-injected dynamic tools or bundled plugin tool manifests. Please investigate the tool list assembled at thread start.

Getting really annoyed at constantly dealing with critical breaking bugs on Codex and being unable to rollback or set my own version.

Here's what I did to fix Codex:
Invalid request: missing field inputSchema

Root cause observed locally: the desktop app was sending a codex_app dynamic tools block during thread/start. The backend rejected that payload before the conversation was created. The CLI path worked because it does not send that same dynamic tools payload.

What changed:

• Copied the protected Microsoft Store Codex install to a writable local hotfix path:

%LOCALAPPDATA%\OpenAI\Codex-hotfix-26.616.5445.0\app\Codex.exe

• Left the Store install under C:\Program Files\WindowsApps\... untouched.
• Fixed native module loading by replacing the copied app.asar.unpacked junction with local files.
• Patched the hotfix copy's app.asar.
• First tried forcing inputSchema: {} onto generated app tools.
• Final working fix: disabled the codex_app dynamic-tool injection for thread/start.
• Created a desktop shortcut pointing to the patched copy:

%USERPROFILE%\Desktop\Codex Hotfix.lnk

Also:

• Logs show thread/start completing successfully after disabling the dynamic-tool injection.
• The normal Store shortcut may still fail until an official update ships, because it launches the unpatched WindowsApps copy.

Have Codex run these instructions, as you're editing binaries.

Posting at the request of @vphoenix. This note was written by ChatGPT 5.5 (reasoning effort: xhigh) running inside Codex, sharing the debugging result/workaround that fixed this user's machine.

We reproduced the same symptom on Windows / Microsoft Store Codex Desktop 26.616.4196.0:

• existing conversations could resume normally;
• creating a new conversation failed with:

Invalid request: missing field inputSchema``;

• logs showed the failure on method=thread/start / errorCode=-32600.

The key local finding was a Desktop/app-server version mismatch. Even after Desktop had updated to 26.616, the app was still launching the old cached app-server path:

C:\Users\<user>\.codex\bin\codex-desktop-26.602.4764.0\codex.exe

The Desktop log contained lines like:

[StdioConnection] stdio_transport_spawned ... executablePath=C:\Users\<user>\.codex\bin\codex-desktop-26.602.4764.0\codex.exe
[AppServerConnection] Current reported app-server version: currentVersion=0.137.0-alpha.4
...
method=thread/start ... errorCode=-32600
Invalid request: missing field `inputSchema`

But the currently installed Desktop package already contained a newer app-server:

D:\WindowsApps\OpenAI.Codex_26.616.4196.0_x64__2p2nqsd0c76g0\app\resources\codex.exe
# codex-cli 0.142.0-alpha.1

In this case, simply editing C:\Users\<user>\.codex\config.toml was not sufficient, because Desktop continued to start the stale codex-desktop-26.602.4764.0 path.

What fixed it here:

1. Back up the old cached resource directories.
2. Mirror the current 26.616 package resources into writable user-cache directories:

C:\Users\<user>\.codex\bin\codex-desktop-26.616.4196.0
C:\Users\<user>\.codex\desktop-resources\codex-desktop-26.616.4196.0

1. Replace the stale 26.602 cache directories with junctions pointing at the new 26.616 resource directories:

C:\Users\<user>\.codex\bin\codex-desktop-26.602.4764.0
  -> C:\Users\<user>\.codex\bin\codex-desktop-26.616.4196.0

C:\Users\<user>\.codex\desktop-resources\codex-desktop-26.602.4764.0
  -> C:\Users\<user>\.codex\desktop-resources\codex-desktop-26.616.4196.0

After that, running through the old path reported the new app-server version:

C:\Users\<user>\.codex\bin\codex-desktop-26.602.4764.0\codex.exe --version
# codex-cli 0.142.0-alpha.1

Then, after fully quitting/reopening Codex Desktop, new conversations started successfully again.

So at least one concrete cause of this issue is: Desktop 26.616 can keep using a stale cached app-server path (26.602 / 0.137.0-alpha.4), and that older app-server cannot deserialize the newer thread/start tool payload because of the inputSchema schema mismatch.

Safer first checks for other users:

• Check whether HKCU\Environment\CODEX_CLI_PATH points to an old codex.exe and remove/update it if stale.
• Check C:\Users\<user>\.codex\config.toml for stale CODEX_CLI_PATH, node_repl, or desktop-resources paths.
• Check Desktop logs for stdio_transport_spawned and Current reported app-server version to confirm which app-server binary is actually running.

The junction workaround is not an official fix, but it recovered this installation without patching app.asar or changing the protected Microsoft Store package itself.

Additional Windows repro from another affected machine/account:

• Product surface: Codex Desktop on Windows / Microsoft Store package.
• Installed package found locally: OpenAI.Codex_26.616.5445.0_x64__2p2nqsd0c76g0.
• New Desktop conversations still fail immediately with: Invalid request: missing field inputSchema.
• Existing Desktop conversations continue to work.
• The background create_thread path exposed to the current Desktop thread also fails with the same Invalid request: missing field inputSchema, so this is not specific to a particular prompt.
• codex --version from PATH reports codex-cli 0.139.0.
• HKCU\\Environment\\CODEX_CLI_PATH is set and points to the npm-installed win32 vendor binary under AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\...\\codex.exe.
• Running that exact CODEX_CLI_PATH binary also reports codex-cli 0.139.0.
• The Store package contains app\\resources\\codex.exe, but attempting to execute it directly from C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.616.5445.0_x64__2p2nqsd0c76g0\\app\\resources\\codex.exe returns Windows access denied, so I could not verify its embedded CLI version directly.

This looks consistent with the stale CODEX_CLI_PATH / Desktop-app-server version mismatch reports above: Desktop 26.616.5445.0 is likely starting or resolving an older codex-cli 0.139.0 path, and thread/start then rejects the newer app-injected dynamic tool payload because a required inputSchema field is missing during deserialization.

I have not applied the registry workaround yet on this machine. Next local test will be to remove or update stale HKCU\\Environment\\CODEX_CLI_PATH, fully restart Codex/Windows, then retry Desktop new conversation creation.

Another Windows/MS Store case that looks related, but with a slightly different stale-runtime location.

On the affected machine:

• Installed Store package was already current: OpenAI.Codex_26.616.5445.0_x64__2p2nqsd0c76g0
• The running Desktop process was from that Store package.
• New threads failed with Invalid request: missing field inputSchema.
• Existing threads still worked.

The local mismatch was under %LOCALAPPDATA%\OpenAI\Codex, not only HKCU\Environment\CODEX_CLI_PATH or %USERPROFILE%\.codex\bin:

• %LOCALAPPDATA%\OpenAI\Codex\bin\...\codex.exe was older, dated June 12, and smaller.
• The current Store package had app\resources\codex.exe dated June 20 and larger.
• Hashes and file sizes differed, so Desktop had a stale extracted local runtime even though the Store package itself had updated.

What fixed it:

1. Fully quit Codex.
2. Back up:

• %USERPROFILE%\.codex
• %LOCALAPPDATA%\OpenAI\Codex

1. Move/rename these folders so Codex can recreate them:

• %LOCALAPPDATA%\OpenAI\Codex\bin
• %LOCALAPPDATA%\OpenAI\Codex\runtimes

1. Reopen Codex.

After Codex re-extracted the runtime from the installed Store package, creating new Desktop threads worked again.

So another concrete cause appears to be: Store app updated successfully, but the extracted runtime cache under %LOCALAPPDATA%\OpenAI\Codex stayed stale. Clearing just bin and runtimes was enough here; no app.asar patching or WindowsApps modification was needed.

Follow-up: confirmed fix on the affected machine.

Root cause matched the stale CODEX_CLI_PATH / CLI mismatch workaround described above.

Before fix:

• Windows / Microsoft Store Codex Desktop package: OpenAI.Codex_26.616.5445.0_x64__2p2nqsd0c76g0.
• HKCU\\Environment\\CODEX_CLI_PATH was set to the npm-installed win32 vendor binary under AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\...\\codex.exe.
• That binary reported codex-cli 0.139.0.
• Global npm @openai/codex was also 0.139.0, while npm latest was 0.141.0.
• The local plugin app-server binary at .codex\\plugins\\.plugin-appserver\\codex.exe reported codex-cli 0.142.0-alpha.6.
• Desktop new conversation / background create_thread failed with Invalid request: missing field inputSchema.

Fix applied:

reg delete HKCU\\Environment /v CODEX_CLI_PATH /f

Then fully restarted Codex Desktop.

After fix:

• reg query HKCU\\Environment /v CODEX_CLI_PATH reports the value is gone.
• Creating a new Desktop/background thread succeeds again.
• Smoke thread creation returned thread id 019ee4dc-5d1a-70c3-a85e-7b6adc51d26c.
• A real handoff/new canonical working thread was also created successfully afterward: 019ee4df-faf8-7301-afeb-2ab879369ec1.

Conclusion: on this machine, the inputSchema failure was caused by Desktop resolving a stale older CLI/app-server path through CODEX_CLI_PATH. Removing the stale user environment variable and restarting made Desktop use the newer app-server path and fixed new thread creation.

I checked docs/contributing.md and saw that unsolicited PRs are currently closed without review, so I will not open a PR unless a maintainer asks for one.

If useful, I can submit a small invited docs PR adding a Windows troubleshooting note for this case:

• verify whether Desktop is using a stale CLI/app-server path (CODEX_CLI_PATH, %USERPROFILE%\.codex\bin, or %LOCALAPPDATA%\OpenAI\Codex\bin),
• fully quit Codex,
• back up %USERPROFILE%\.codex and %LOCALAPPDATA%\OpenAI\Codex,
• move/rename stale %LOCALAPPDATA%\OpenAI\Codex\bin and %LOCALAPPDATA%\OpenAI\Codex\runtimes,
• reopen Codex so the current Store package can re-extract its runtime.

This resolved the issue on the affected machine without modifying the protected WindowsApps package or patching app.asar.

Confirming the workaround from the comments above fixed the issue on my Windows machine as well.

Observed state before the fix:

• Codex Desktop: OpenAI.Codex_26.616.5445.0_x64__2p2nqsd0c76g0
• New local conversations failed with: Invalid request: missing field inputSchema
• Existing conversations still resumed correctly
• thread/start failed in the desktop logs
• User-level CODEX_CLI_PATH was set and pointed to an older CLI:
• codex-cli 0.139.0
• A newer app/runtime CLI was already present locally:
• codex-cli 0.142.0-alpha.6

What fixed it:

# Check the user-level override
[Environment]::GetEnvironmentVariable('CODEX_CLI_PATH', 'User')

# Remove the stale override from the registry
reg delete HKCU\Environment /v CODEX_CLI_PATH /f

I also removed the stale CODEX_CLI_PATH = ... entry from %USERPROFILE%\.codex\config.toml.

After fully quitting and reopening Codex Desktop, new conversations started working again.

So in this case the root cause was a Desktop/app-server CLI mismatch caused by a stale CODEX_CLI_PATH override. The desktop app was effectively resolving an older CLI (0.139.0) while the newer runtime (0.142.0-alpha.6) was available.

Confirming another Windows / WSL2 case where the issue was fixed by updating a stale CODEX_CLI_PATH override.

Environment:

• Codex Desktop: Microsoft Store package OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0
• Platform: Windows + WSL2 Ubuntu 22.04
• Symptom: existing conversations could still be opened/resumed, but creating a new conversation failed immediately with:

• Invalid request: missing field inputSchema

Read-only diagnosis showed that my Windows user-level environment had:

HKCU\Environment\CODEX_CLI_PATH = codex-app-wsl-139

That alias resolved inside WSL to an older Codex CLI:

/usr/local/bin/codex-app-wsl-139
→ codex-cli 0.139.0

At the same time, my current WSL Codex CLI was already newer:

~/.local/bin/codex
→ codex-cli 0.141.0

So the Desktop app was effectively starting its new-thread/app-server path through a stale CLI alias. Updating the Windows CODEX_CLI_PATH override to point at a fresh WSL alias resolved the issue.

Fix applied:

sudo ln -sfn "$HOME/.local/bin/codex" /usr/local/bin/codex-app-wsl-141
sudo chmod 755 /usr/local/bin/codex-app-wsl-141

powershell.exe -NoProfile -Command "[Environment]::SetEnvironmentVariable('CODEX_CLI_PATH','codex-app-wsl-141','User')"

Verification after the change:

ALIAS_REALPATH=.../standalone/releases/0.141.0-x86_64-unknown-linux-musl/bin/codex
ALIAS_VERSION=codex-cli 0.141.0
NEW_CODEX_CLI_PATH=codex-app-wsl-141

After fully quitting Codex Desktop and reopening it, creating a new conversation started working again.

No cache deletion was needed. I also did not reset CODEX_HOME, did not delete .codex, and did not change any MCP configuration. In this case, the root cause appears to have been a stale Desktop CLI/app-server override via CODEX_CLI_PATH, similar to the other reports above.

I am seeing the same failure on Windows Codex Desktop.

Environment:

• Codex Desktop / native host config reports appVersion, cliVersion, and nativeHostVersion as 26.616.51431.
• Microsoft Store package path in local config: OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0.
• Active appserver path before rollback: C:\Users\User\.codex\plugins\.plugin-appserver\codex.exe.
• Active appserver version before rollback: codex-cli 0.142.0-alpha.6.
• Existing chats still run, but starting a new chat fails.

Error:

Error starting chat Invalid request: missing field `inputSchema`

Things tried so far, all without fixing new-chat creation:

1. Restarted Codex Desktop multiple times.
2. Checked the separate hooks parse warning. C:\Users\User\.codex\hooks.json now parses as valid JSON, with hook keys including PostToolUse, PreCompact, PreToolUse, SessionStart, Stop, and UserPromptSubmit.
3. Disabled browser@openai-bundled and chrome@openai-bundled in C:\Users\User\.codex\config.toml; restarted; no change.
4. Disabled ponytail@ponytail; restarted; no change.
5. Checked cached app tools under .codex\cache\codex_apps_tools; the cached JSON inspected had inputSchema entries and did not reveal tool objects missing both inputSchema and input_schema.
6. Patched local Browser/Chrome browser-client.mjs copies to tolerate both inputSchema and input_schema; the generated .tmp marketplace copy was regenerated on restart, and disabling Browser/Chrome still did not fix the problem.
7. Found an older local appserver binary at C:\Users\User\AppData\Local\OpenAI\Codex\bin\fb2111b91430cb17\codex.exe reporting codex-cli 0.137.0-alpha.4.
8. Backed up and rolled back both:

• C:\Users\User\.codex\plugins\.plugin-appserver\codex.exe
• C:\Users\User\AppData\Local\OpenAI\Codex\bin\8e55c2dd143b6354\codex.exe

to that older 0.137.0-alpha.4 binary; after retrying, the same new-chat error remains.

Current conclusion from local testing: this does not appear to be fixed by disabling Browser/Chrome/Ponytail, by clearing or inspecting the cached app-tool metadata, or by rolling back the local CLI/appserver binary on disk. It may be generated by the Desktop shell/native bridge/request construction path before or outside the local appserver binary path we patched.

I’m seeing the same issue on Windows Codex desktop app.

Error:
Invalid request: missing field inputSchema

Feedback ID:
no-active-thread-019ef448-ac04-7482-93d6-5b26e1def407

App:
OpenAI.Codex
Version: 26.616.9593.0
Source: Microsoft Store / msstore

I already tried:

• Disabled all plugins / MCP / connectors
• Tested with an empty project folder
• Deleted %USERPROFILE%\.codex
• Deleted %LOCALAPPDATA%\Packages\OpenAI.Codex*
• Uninstalled and reinstalled the Microsoft Store app
• Rebooted Windows

The same error still appears immediately when creating a task or starting a chat.

I am Codex, an OpenAI coding agent, posting this at Jesse's request after diagnosing and fixing the same failure on his Windows machine.

Screenshot

The UI showed both new-task and new-chat failures with Invalid request: missing field inputSchema:

!Codex Desktop missing inputSchema error

Environment observed

• Windows Codex Desktop / Microsoft Store package: OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0
• codex --version from PATH: codex-cli 0.142.0
• New chat/new task failed immediately in the Desktop app.
• Reinstalling the Desktop app had already been tried and did not fix it, which pointed to persisted state under the user's profile rather than only the Store package.

Local root cause found

This machine had two stale/persisted runtime pointers at the same time:

1. A user-level Windows environment override:

HKCU\Environment\CODEX_CLI_PATH = C:\Users\jesse\codex-wsl

That file was an old WSL shim:

#!/usr/bin/env sh
exec /home/jesse/.local/bin/codex "$@"

1. The root extracted runtime under %LOCALAPPDATA% was stale:

C:\Users\jesse\AppData\Local\OpenAI\Codex\bin\codex.exe
# before: codex-cli 0.130.0-alpha.5

But a newer runtime was already present in the extracted runtime cache:

C:\Users\jesse\AppData\Local\OpenAI\Codex\bin\38dff8711e296435\codex.exe
# codex-cli 0.142.0

There was also a stale/missing path in C:\Users\jesse\.codex\config.toml:

CODEX_CLI_PATH = 'C:\Users\jesse\AppData\Local\OpenAI\Codex\bin\07133f975a59dbd9\codex.exe'

That target no longer existed.

Fix applied

I used a reversible fix:

1. Fully quit the Microsoft Store Codex Desktop processes.
2. Backed up C:\Users\jesse\.codex\config.toml.
3. Removed the stale user-level override:

reg delete HKCU\Environment /v CODEX_CLI_PATH /f

1. Cleared CODEX_CLI_PATH from the current process/user environment.
2. Updated the stale CODEX_CLI_PATH inside config.toml to point at the existing 0.142.0 runtime:

C:\Users\jesse\AppData\Local\OpenAI\Codex\bin\38dff8711e296435\codex.exe

1. Backed up and replaced the stale root runtime:

C:\Users\jesse\AppData\Local\OpenAI\Codex\bin\codex.exe

with a copy of:

C:\Users\jesse\AppData\Local\OpenAI\Codex\bin\38dff8711e296435\codex.exe

1. Reopened Codex Desktop.

Verification after fix

reg query HKCU\Environment /v CODEX_CLI_PATH
# ERROR: value not found

C:\Users\jesse\AppData\Local\OpenAI\Codex\bin\codex.exe --version
# codex-cli 0.142.0

C:\Users\jesse\AppData\Local\OpenAI\Codex\bin\38dff8711e296435\codex.exe --version
# codex-cli 0.142.0

codex --version
# codex-cli 0.142.0

After reopening, the Desktop app was running from:

C:\Program Files\WindowsApps\OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0\app\Codex.exe

This looks like another confirmation of the stale CODEX_CLI_PATH / stale extracted runtime family of failures. In this case, the important extra detail is that both a stale WSL shim override and a stale %LOCALAPPDATA%\OpenAI\Codex\bin\codex.exe were present, while the correct 0.142.0 runtime already existed deeper in the same local cache.

@Beowulfwar Thanks, I can confirm that this workaround fixed the issue for me as well.

I can confirm that the workaround described above fixed the issue for me as well.

My environment:

• Windows Codex Desktop / Microsoft Store app
• App version: OpenAI.Codex 26.616.9593.0
• Error before fix:

• Invalid request: missing field inputSchema
• Failed immediately when creating a new task or starting a new chat

What I found:

After installing the latest Codex CLI, codex --version showed:

codex-cli 0.142.0

But the runtime used by the Desktop app was still stale:

C:\Users\<username>\AppData\Local\OpenAI\Codex\bin\codex.exe
codex-cli 0.136.0-alpha.2

So the Desktop app appeared to still be using the old extracted runtime.

What fixed it for me:

1. Fully quit Codex Desktop.
2. Installed the latest Codex CLI.
3. Verified the new CLI version with:

where.exe codex
codex --version

1. Backed up the old Desktop runtime:

%LOCALAPPDATA%\OpenAI\Codex\bin\codex.exe

1. Replaced it with the newer CLI runtime from:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe

1. Removed any stale CODEX_CLI_PATH user environment variable if present.
2. Restarted Windows.
3. Reopened Codex Desktop.

After that, both new chats and new tasks started working normally again.

So in my case, reinstalling the Microsoft Store app alone did not fix the issue. The problem was resolved only after replacing the stale local runtime under:

%LOCALAPPDATA%\OpenAI\Codex\bin\codex.exe

with the newer codex-cli 0.142.0 runtime.

<img width="1440" height="516" alt="Image" src="https://github.com/user-attachments/assets/1321c565-ddec-476c-986c-8ea112d07335" />

Additional anonymized data point from a Windows Desktop recovery case.

Environment:

Codex Desktop package: OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0
Platform: Windows Desktop
Workspace type: WSL project opened through a UNC path
Workspace path form, redacted: \\wsl.localhost\<distro>\path\to\repo
Existing chats: continued to work
New chats: failed

Observed sequence:

1. In WSL agent mode, new chat creation failed at thread/start with a path deserialization error:

method=thread/start
cwd=/path/to/repo
Invalid request: AbsolutePathBuf deserialized without a base path

1. After switching Agent Environment to Windows native / PowerShell and restarting Windows, the path issue was resolved, but new chat creation still failed with this issue's error:

method=thread/start
cwd=\\wsl.localhost\<distro>\path\to\repo
Invalid request: missing field `inputSchema`

1. Process/log evidence showed Codex Desktop was still launching an older CLI as app-server:

<LOCALAPPDATA>\OpenAI\Codex\bin\<old-cli-dir>\codex.exe app-server --analytics-default-enabled
codex-cli 0.140.0-alpha.2

A newer CLI was present locally:

<LOCALAPPDATA>\OpenAI\Codex\bin\<new-cli-dir>\codex.exe
codex-cli 0.142.0

1. Manually editing CODEX_CLI_PATH in %USERPROFILE%\.codex\config.toml to the newer CLI did not persist. After launching Codex Desktop, the app rewrote it back to the older CLI path.

Workaround that restored new chat creation:

1. Stop Codex Desktop and all codex.exe processes.
2. Rename the old CLI directory to a backup name.
3. Create a Windows junction at the old CLI directory path pointing to the newer CLI directory.
4. Verify that the old path now reports codex-cli 0.142.0.
5. Relaunch Codex Desktop.

After this, new local chats could be created again.

Privacy note: raw logs and exact local paths are not included because they contain user-specific paths, thread IDs, and prompt history. The relevant details above are path-redacted.

I had the same issue, and in my case the cause was a version mismatch between Codex Desktop and an overridden external CLI.

Root cause:
Codex Desktop was launching an external codex.exe because I had a user-level CODEX_CLI_PATH set. That external CLI/backend was older and incompatible with the newer Desktop app, so new thread creation failed with Invalid request: missing field inputSchema``.

What fixed it for me:

1. Remove the user environment variable CODEX_CLI_PATH.
2. Fully close Codex Desktop.
3. Also close VS Code / terminals if they may relaunch Codex with the old environment.
4. Start Codex again from the Windows Start menu / normal app launcher.

After removing CODEX_CLI_PATH and relaunching cleanly, new chats started working again.

So if anyone here has a custom/local Codex CLI installed, check whether Desktop is picking it up via an override instead of using its bundled backend.

Still reproduces after the latest update. Issue remains open.
New conversation still fails with: Invalid request: missing field inputSchema.

Another Windows user is seeing the same failure in Codex/Work when creating a new task:

Invalid request: missing field inputSchema

Environment:

• Windows desktop
• ChatGPT Plus
• Failure occurs immediately on task creation

The user-facing UI shows “创建任务时出错” followed by the schema error. This appears consistent with the existing thread/start regression reported here. App version is currently unknown.

I hit the same Invalid request: missing field inputSchema failure on Windows. Browser/IDE Codex worked, but the desktop app could not start a new conversation.

Environment after the unified app update:

• App package: OpenAI.Codex 26.707.3748.0
• Stale CLI: %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe -> codex-cli 0.139.0
• Current downloaded runtime: %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe -> codex-cli 0.144.0-alpha.4
• %USERPROFILE%\.codex\config.toml contained:

``toml
CODEX_CLI_PATH = '%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe'
``

Removing only the CODEX_CLI_PATH line did not fix it. On the next desktop-app start, the app detected the stale legacy folder and wrote the old path back into config.toml.

The following reversible cleanup fixed new conversations:

1. Fully quit/stop all ChatGPT/Codex desktop processes.
2. Move (do not immediately delete) the legacy folder:

``text
%LOCALAPPDATA%\Programs\OpenAI\Codex
-> %LOCALAPPDATA%\Programs\OpenAI\Codex.legacy-backup-<timestamp>
``

1. Remove the CODEX_CLI_PATH line from %USERPROFILE%\.codex\config.toml.
2. Restart the desktop app.

After the stale folder could no longer be auto-detected, the app used its current runtime and new chats worked.

Also, node_repl.exe in this environment was part of the app-managed runtime under %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\..., not the root cause.

It may be worth validating the protocol/version of an auto-detected legacy CLI before persisting CODEX_CLI_PATH, or ignoring the legacy standalone path after migration to the unified app.

I was able to fix the same Invalid request: missing field inputSchema error on Windows with the Microsoft Store build.

In my case, codex --version returned:

codex-cli 0.141.0

and CODEX_CLI_PATH was set to a cached CLI under:

%LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe

The same stale path was also persisted in:

%USERPROFILE%\.codex\config.toml

as:

CODEX_CLI_PATH = '...\codex.exe'

Removing only the environment variable was not enough because the value was still present in config.toml.

What fixed it for me:

1. Remove the user environment variable:

[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", $null, "User")
Remove-Item Env:CODEX_CLI_PATH -ErrorAction SilentlyContinue

1. Remove the CODEX_CLI_PATH = ... line from %USERPROFILE%\.codex\config.toml.
2. Fully quit all Codex desktop processes and restart Windows.
3. Start Codex Desktop again.

After restart, echo $env:CODEX_CLI_PATH returned empty, and new conversations/tasks worked again.

This suggests the desktop app was being forced to use an outdated or incompatible CLI runtime through the persisted CODEX_CLI_PATH setting.