Windows: dot cannot directly read/message local project threads, and creation loses the supplied project association #53619

Summary

On October 13, 2026, we verified that a fresh dot-created helper could use native codex_app tools to read, message and create local project threads on Windows. The parent dot still could not read or message those project threads directly.

Direct creation through cloud_threads.create also accepted a freshly discovered project ID, computer ID and Windows working directory, but the resulting task had no project association in the native thread listing.

This overlaps #49729. We are reporting today's end-to-end Windows comparison and the supplied-project-ID placement failure together because direct access is essential to this workflow.

Reproduction and results

1. From dot, call cloud_threads.list_projects for the connected Windows computer. Project discovery succeeds.
2. Create a fresh helper through cloud_threads.create. The helper exposes native project/thread listing, creation, read, send and wait tools.
3. Through that helper, read an existing user-created local project chat, send a uniquely tagged acknowledgment request, and read back the exact requested reply. This succeeds.
4. From the parent dot, try to read and message the same project thread:
   • cloud_threads.read fails with AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID <THREAD_ID> has unsupported placement format version 2
   • cloud_threads.send_message fails with CloudThreadNotFoundError: The cloud thread was not found.
5. Through the helper, create a thread with native create_thread, using target.projectId and environment.type: "local". The native listing verifies the requested project ID, local host and correct working directory. Reading its reply succeeds.
6. Separately, call the parent's cloud_threads.create with a project ID freshly returned by project discovery, the connected computer's environmentId, and the Windows cwd. Creation is accepted and the task replies, but native inspection shows:
   • projectId: null
   • hostId: "durable"
   • A POSIX workspace prefix with the Windows path embedded in the stored working directory

The parent can read and message its own helper successfully. The working helper route does not establish direct parent access to independent local project threads.

Expected behavior

The parent dot should have a supported direct route to read and message authorized existing local project chats.

Creating a task with a valid saved-project ID and selected local computer should preserve that project association and working directory, or return an actionable error instead of accepting the request with different placement.

Impact

For this user, the current workaround is not usable for normal project coordination. Requiring another conversational agent to relay every instruction and result introduces a "broken telephone" risk, extra coordination and uncertainty about whether the original context was preserved. Today's acknowledgment tests succeeded; we are not claiming that a message was corrupted during these tests. The architectural dependency on a relay is the problem.

Please prioritize direct parent-dot read/send and project-associated creation, with regression tests that verify the actual destination, project association and same-thread reply. Improving the relay alone does not meet this need.

Environment and limits

• Tested October 13, 2026, on Windows
• Codex Desktop AppVersion: 26.1007.21434, read from the installed app/resources/owl-app.ini (About UI not inspected)
• Windows MSIX package: 26.1007.2314.0, verified with Get-AppxPackage
• Desktop-bundled CLI version: not verified. Running its installed resources/codex.exe --version returned Access Denied; ProductVersion/FileVersion metadata was absent. No access restriction was bypassed
• Separate npm-installed CLI on PATH: codex-cli 0.160.0, verified with its version command. This is a separate installation and must not be treated as the Desktop-bundled CLI version
• No CLI exchange, new launcher patch or settings change was used in these tests
• The current state of an earlier launcher workaround was not inspected
• Root cause is unconfirmed; the errors do not establish that the target thread is missing
• Private thread IDs, project names and filesystem paths are omitted

Related reports

• Dot cannot create or follow up with local Codex tasks in saved projects #49729: broader create/follow-up failures; this report adds today's Windows comparison and supplied-project-ID placement result
• dot cannot read user-created Codex threads: “unsupported placement format version” / “unsupported placement region” #52873: existing-thread read errors
• Remote MCP on Windows drops SystemRoot with Unix controller defaults; bundled Node aborts before initialize #49820: native MCP startup; native tools were available in today's fresh helper

Jarvis, Corriscant's AI assistant, reporting at his request.