Repository navigation
[Windows 26.930.7945.0][Work] Local executor online, but list_threads/read_thread fail with MCP -32000 #52063
Description
Environment
- Windows notebook, hostname
zhangjun09. - Last verified installed Codex AppX version:
26.930.7945.0. A current non-elevated package query returned no data, so a subsequent version change has not been independently ruled out. - Observed October 8, 2026.
- Existing Work task attached to the notebook; normal shell execution works.
Problem
Official native chat-management calls repeatedly fail while the local executor is connected:
mcp__codex_app__list_threads({limit:10})mcp__codex_app__read_thread({threadId:<existing local Codex chat>,hostId:"local",turnLimit:5,includeOutputs:true,maxOutputCharsPerItem:5000})
Both return:
MCP error -32000: Codex app tool request failed
The local chat was previously readable through this supported interface. The user reopened the app through their existing dedicated launch entry at approximately 18:31 UTC+8 on October 8. The notebook task then successfully executed hostname, returning zhangjun09, but the subsequent official read_thread call still failed.
Minimal observed reproduction
- Use an existing Work task connected to a Windows notebook running Codex.
- Confirm basic shell execution works with
hostname. - Call the official native thread listing or read an existing local Codex chat.
- Observe the generic MCP -32000 error rather than the thread result.
- After reopening the desktop app and restoring the executor connection, repeat the read: the error persists in this setup.
This is an observed incident sequence, not a proven deterministic reproduction on a clean installation.
Narrow diagnostic evidence
From the newly created October 8 app log, UTC timestamps:
2026-10-08T10:30:52.524Z info [dynamic-app-tools-native-pipe] dynamic_app_tools_listening
2026-10-08T10:31:02.422Z info [tpp-local-executor] Local Work executor connected to rendezvous attempt=2
2026-10-08T10:52:15.222Z warning [dynamic-app-tools-native-pipe] dynamic_app_tools_request_failed errorMessage="The app tool call ended before producing a result" errorName=Error method=tools/call
The final log line has no tool name or request ID, so it cannot be conclusively correlated to the failed read_thread request. Root cause is unknown. A working executor connection does not establish that the native app-tool request path works.
Expected behavior
The supported list/read interfaces should return authorized existing-chat data, or a specific actionable diagnostic and supported recovery path.
Related and privacy
Related symptom: #50551 (macOS native listing failure); same underlying cause is not established. This report includes only minimal technical diagnostics. No full conversations, user document contents, authentication data, screenshots, or complete log packages are attached. No further restart or configuration changes were performed for this report.
Activity
johndvaison-droid commentedon Oct 14, 2026
Additional Windows observation from an assistant-assisted, read-only test on October 14, 2026, approximately 15:09–15:13 UTC.
A newly created dot-managed helper on the same computer could run PowerShell, but native project/history requests failed:
codex_app/list_projects: MCP-32000,Codex app tool request failed.codex_app/list_threads, limited to 5 results: the same error.codex_app/read_thread, targeting one known existing conversation with a 1-turn limit and tool outputs excluded: the same error.Get-Locationsucceeded in that same fresh helper.Creating a fresh helper therefore did not restore native history access in this test. The calls returned errors; this observation concerns failed invocation, rather than tools being absent from the catalog. No historical conversation content was obtained.
The account owner had separately reported that manually created tasks could work. That is earlier user-reported context, not a successful control re-tested during this window.
The installed app version/build was not checked for this test, so no version-specific claim is made. No settings, installation, or restart changes were made. This is one observed incident, not a deterministic clean-install reproduction or evidence of a shared root cause with other reports.
Expected: these supported read-only calls return authorized project/thread information, or an actionable error and supported recovery procedure. What supported diagnostic would distinguish the failing native app-tool request path when shell execution in the same fresh helper works?
Windows username, local paths, project names, private thread IDs, conversation contents, and raw logs are omitted.