Repository navigation
[Windows][dot/Work] Computer tasks lack browser/desktop tools: durable MCP startup failures and follow-up path error #49488
Description
What version of the Codex App are you using?
Windows package: OpenAI.Codex_26.928.1915.0_x64; bundled app metadata: 26.928.20755 (read from the installed package, not the About dialog).
What subscription do you have?
Not collected during this diagnostic. ChatGPT Work/dot and local computer execution are available on the affected account.
What platform is your computer?
Windows x64. PowerShell reports Microsoft Windows NT 10.0.22631.0.
What issue are you seeing?
On the same Windows computer, local Codex chats can use Chrome automation and obtain desktop screenshots, but multiple computer tasks created by a dot lack the corresponding browser/desktop tool entry points. Creating a fresh dot task did not restore them.
The affected tasks are reported as hostId=durable and can still execute Windows PowerShell through the connected computer executor. This is therefore not simply an observation that a disconnected cloud task cannot access the computer.
The desktop log records cua_repl and codex_app MCP startup failures for two affected durable tasks, including the newly created diagnostic task. Meanwhile, node_repl, cua_repl, and codex_app become ready for a local chat on the same machine.
A subsequent attempt to send a diagnostic follow-up to the affected task failed before a new turn started:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
code=-32602 failureReason=invalid_config method=turn/start
The target stayed idle with its original completed turn. We do not yet know whether this path error and the MCP startup failures share a root cause.
What steps can reproduce the bug?
Observed sequence on this installation:
- Keep the Windows desktop app and Chrome extension connected. The user reports extension/connection diagnostics are normal.
- Ask a dot to create a computer task requiring browser and desktop tools.
- Inspect the tools actually available in that task: Windows shell execution is available, but the browser/desktop entry points are missing.
- Create a second, fresh diagnostic computer task from the dot. The tool gap persists, and desktop logs record MCP startup failures again.
- In a local Codex chat on the same machine, enumerate Chrome tabs, open
https://example.com/, and read its page content successfully. Close the test tab. Import@oai/skyvianode_repl, enumerate Windows windows, and obtain a screenshot successfully. Desktop clicks/typing were not tested. - Attempt to continue the failed diagnostic chat with the supported
send_message_to_threadtool targetinghostId=durable. It returns the path-deserialization error above without starting a new turn.
Diagnostic task ID for maintainer correlation: 01a0f077-a8e6-7039-ac13-4f1efa66103a.
Observed on 2026-09-30, UTC+08:00. Token/context usage was not collected.
What is the expected behavior?
A dot-created computer task connected to this Windows executor should receive the supported, enabled browser/desktop capabilities, or clearly explain which capability is unsupported. Continuing such a task should not fail while deserializing its workspace path.
Additional information
Selected log fields (UTC; unrelated identifiers and contents omitted):
2026-09-30T03:59:39.605Z hostId=durable server=codex_app status=failed error="MCP server failed to start." failureReason=null
2026-09-30T03:59:39.607Z hostId=durable server=cua_repl status=failed error="MCP server failed to start." failureReason=null
2026-09-30T04:06:08.870Z hostId=local server=node_repl status=ready error=null
2026-09-30T04:06:08.940Z hostId=local server=cua_repl status=ready error=null
2026-09-30T04:06:09.061Z hostId=local server=codex_app status=ready error=null
2026-09-30T04:07:57.367Z hostId=durable server=cua_repl status=failed error="MCP server failed to start." failureReason=null
2026-09-30T04:07:57.367Z hostId=durable server=codex_app status=failed error="MCP server failed to start." failureReason=null
2026-09-30T04:20:35.961Z code=-32602 failureReason=invalid_config method=turn/start message="invalid turn/start params: AbsolutePathBuf deserialized without a base path"
The affected task's reported working directory has this structure (cloud instance identifiers redacted):
/tmp/codex-cloud-agent-<redacted>/app_servers/thread_service/workspace/E:\Codex\Tasks\2026-09-30\task-3
The local Browser/Chrome/Computer Use plugins are enabled. The installed unified-computer-use MCP definition contains a Windows absolute Node executable path; local native desktop access is supplied separately through node_repl/@oai/sky. A platform/path or executor-routing mismatch is a hypothesis, not a confirmed cause. Please inspect the underlying durable MCP startup exception and computer-executor capability routing.
Related path symptom: #49477 reports the same Windows package version, a mixed Linux/Windows path, and follow-up failures. That report does not cover this dot-child MCP startup gap; this report should be linked/merged if maintainers establish a common cause. Another path-deserialization report is #31983, but its SSH context differs.
This has reproduced in multiple tasks on one computer. Impact across other users and a shared root cause have not been established. No extension reinstall, permission expansion, or app restart was used during this diagnostic; unrelated ongoing work was preserved.
Activity
github-actions commentedon Sep 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
yaoyuliu621-collab commentedon Sep 30, 2026
Additional Windows reproduction on 2026-09-30, with a working local-browser control case.
Environment: Windows 11 Home, x64, OS build 26300. Desktop internal version 26.928.21956 (build 12404, prod); Windows package 26.928.2636.0. The in-app update check returned up_to_date. Chrome and the official browser extension are installed and enabled.
Reproduction and control
Startup error, not just a missing-tool self-report
The delegated task's official MCP discovery recognizes cua_repl, but initialization returns:
A separate lookup for node_repl returns unknown MCP server 'node_repl'.
The desktop log independently records these selected fields (UTC; private identifiers omitted):
This fails before connecting to Chrome. The effective failing-process launch configuration and stderr have not been obtained, so the underlying cause remains unknown.
Distinct continuation failure
From the local desktop chat, native send_message_to_thread targeting the delegated task returns:
By contrast, the dot's cloud_threads.send_message resumes the exact same delegated task successfully. The local chat can also send to and read the dot main chat. This provides an entry-point comparison in addition to the error in this report and #49477; it does not establish a shared cause with MCP startup failure.
The affected task's metadata has a Linux-style prefix followed by a Windows absolute workspace path, while its actual PowerShell cwd is on Windows. Private path components are omitted.
Relevant checks and limits
Please expose the actual delegated MCP launch/exit cause, investigate the native-vs-dot continuation path difference, and clarify the supported browser capability for this Windows build. No account IDs, chat IDs, private paths, credentials, screenshots or raw transcript/log archives are included.
DDDFXYqiming commentedon Sep 30, 2026
I'm seeing this with OpenAI Dot on Windows 11 Home 25H2 too. Package 26.928.1915.0, internal app version 26.928.20755, bundled CLI 0.159.0.
A manually opened local Codex chat has list_threads, read_thread and send_message_to_thread. It successfully read the title of the exact old chat I wanted Dot to continue. Dot-created tasks on the same connected, authorized PC can run PowerShell but have none of those native tools.
Read-only log checks now tie six codex_app startup failures to the affected Dot task. One attempt shows:
The plural codex_apps server reaches ready in that task. The singular codex_app also reaches ready in the ordinary local control chat.
We checked the path issue in #49562. Here the generated config enables codex_app, and its cwd, launcher, server.mjs and Node executable all exist from the diagnostic shell. No missing-directory condition was reproduced. The available logs don't include stderr or an exit code, so the underlying cause is still unknown.
Is there a supported way to collect the delegated MCP startup error or refresh its tool initialization? No settings were changed during these checks.
AndrePeixoto commentedon Oct 1, 2026
Additional Windows reproduction, observed September 30–October 1, 2026 UTC. The missing tools persist after updating and restarting the desktop app.
On the same connected Windows computer:
An earlier startup diagnostic contained Windows os error 3 (“The system cannot find the path specified”), but the missing path was not identified, and its causal relationship to this failure is unconfirmed. No configuration patches or permission changes were made during these checks.
Please investigate why the delegated task's MCP runtimes fail while the direct local conversation works, and provide a supported recovery or diagnostic procedure. This comment adds evidence for the startup/tool-availability problem; it does not establish a root cause or reproduce the separate follow-up path error.
deciduus commentedon Oct 1, 2026
On Windows Desktop 26.928.3736.0/backend 0.159.2, normal project chats work but dot tasks fail with path-deserialization, malformed file-URI and executor-configuration errors. Changing the projectless folder did not resolve the latter.
The supplied opaque URI contains a UTF-8
/C:/…/app/resourcespath, not Windows UTF-16LE. Both the installed version and #49388 classify it as POSIX. An isolated Node test reproduces that spelling throughURL.pathname; WindowsfileURLToPathproduces the expected Windows path. This suggests a producer-side conversion issue, but we haven’t identified the caller.Could maintainers trace the failing path field and resources-path conversion, including producer/consumer OS and the inner executor-configuration error? Seven inert diagnostic tests pass; this is not a full app reproduction.
Related path report: #49477.
shiva2189 commentedon Oct 1, 2026
Current scope: both manually started Local Work/Codex chats and dot-assigned local tasks are failing to expose working Chrome/Computer Use controls on my Windows computer. This is not limited to dot-assigned tasks in my current setup. Local computer use worked normally until last week, but there is no successful current local control case. Restarting did not resolve it.
I am seeing the same missing-tool behavior on Windows on 1 October 2026.
Ordinary local Work/Codex chats using
@Chromeand@Computerhave generally worked on my computer (user-reported history, not a successful same-day control test). However, three tasks created by my dot on that same connected and authorized computer did not expose the supported browser/desktop control tools. Local shell access worked, but the sessions reported neither cua_repl nor node_repl available.Checks in the delegated sessions found Chrome running, its extension enabled, valid native-host registration, and Chrome/Computer Use/Browser settings enabled. The installed runtime manifest declares Chrome support. I also cannot add the Chrome or Computer skills in those delegated chats as I normally do in a fresh local chat.
The tasks used both Astra and Sol, so the observed symptom was not limited to one selected model. No extension reinstall or configuration patch has been applied. App/build details are still being checked; I am not claiming the same path or MCP startup error as the original report.
Could the team confirm whether browser and desktop control are supported for dot-created local Windows tasks, and identify a supported fix or required version? Please investigate why a connected local executor can expose shell access while omitting the enabled browser/desktop tools. If this needs a different team or private diagnostic channel, please route or advise. No private task contents, account details, credentials or raw logs are included here.
Update: A newly manually started chat with both browser/computer tags also reports missing controls. Its exact execution mode (desktop Local versus web/cloud) is still being verified. Therefore this reproduction does not yet establish that the current failure is exclusively limited to dot-created tasks. Please preserve that distinction when comparing it with the verified local control cases above.
Version details collected from the affected computer:
The affected session has working shell, skills and public web access, but still no supported browser/Computer Use, cua_repl, node_repl or tool-discovery entry point. No settings were changed.
Post-restart update: a full system restart did not restore the tools in the resumed delegated task. One newly created, bounded diagnostic task after that restart also lacked cua_repl, node_repl and supported local Chrome/desktop controls; no page-control test could run. The fresh task additionally reported a workspace-instruction lookup failing before execution with
orchestrator_helper_launch_failedbecausecodex-windows-sandbox-setup.exewas not found. The effective missing path and whether this has the same cause as the browser-tool omission are unverified. The manually started tagged chat also still reports missing controls; its exact execution mode remains unconfirmed.Latest clarification (1 October 2026, 04:45 UTC): I confirm that the manually started affected chat is running in Local mode and still cannot use Chrome/Computer controls. Earlier local computer use worked historically, but it is not a working control case now. The current affected setup therefore includes both dot-created tasks and a manually started Local chat; selecting Local and restarting have not resolved it. The exact shared cause remains unverified.
Last-known-working context: local Chrome/Computer Use was working normally until last week, according to my usage history. The precise last-working app version and exact onset date have not been established. This is a loss of previously working functionality; a recent regression is plausible but not yet confirmed.
Jacobzwj commentedon Oct 1, 2026
Hi, thanks for documenting this issue. I can also reproduce it on the Windows desktop app, version 26.928.3736.0, after restarting and creating a fresh dot task. Computer Use works in an ordinary local Codex conversation, but dot-created local tasks have shell access without node_repl, cua_repl, or browser controls. Is this a known limitation or a tracked regression? Is there a supported workaround, or any information about a planned fix? Thank you for your help.
3833463-stack commentedon Oct 1, 2026
Additional reproduction and isolation on 2026-10-01 (Windows, Codex Desktop 26.928.31416/build 12553, MSIX package 26.928.3736.0, bundled CLI 0.159.2). The in-app update check reported
up_to_date.A directly started local Codex chat can use
cua_replto openhttps://example.com/in the in-app browser and read its page title. A Dot-created connected Windows task on the same machine still has PowerShell, but no usablecua_replornode_repl. Desktop logs repeatedly showhostId=durablewith bothcua_replandcodex_apptransitioningstarting -> failed, errorMCP server failed to start.A follow-up also intermittently fails atturn/startwithAbsolutePathBuf deserialized without a base path.We ran a bounded A/B on the exported app-tools launcher: restoring
SystemRootonly in the launcher madecodex_appbecome ready, and the connected task successfully called one read-only app tool. Desktop export regeneration removed this temporary guard on executor reconnect, returning to the failure. Importantly, this did not restorecua_repl; the browser capability remains a separate unresolved problem. The controlled Node child withoutSystemRootexited 134 withncrypto::CSPRNGassertion, while the same child with it ran. This is consistent with the narrower environment analysis in #49820, but does not establish the cause of the CUA failure.A supported user-level custom MCP configuration with explicitly supplied
SystemRootwas recognized by local CLI but did not appear in the durable task. We removed that test entry and verified the original config hash; no plugin or system setting changes remain. Re-login and executor restart did not resolve the problem.Please inspect the durable worker's actual
cua_replchild launch, stderr and capability routing separately from thecodex_appenvironment issue, and trace the malformed workspace path atturn/start. The current generic MCP startup message is insufficient to diagnose the browser side. Private task IDs, usernames, local paths, raw logs and credentials are omitted from this public comment.8 remaining items
SevxLabs commentedon Oct 2, 2026
Two separately tested recoveries may help distinguish the symptoms here on Windows package 26.930.2377.0:
This does not verify restored browser/CUA or node_repl access, and we have not established one shared cause for the startup and composer failures.
blakeal2 commentedon Oct 2, 2026
Additional Windows reproduction on 26.930.21537, observed October 2, 2026.
Dot-created Windows tasks can execute shell commands but lack native codex_app and cua_repl/browser tools. Direct local @chrome works on the same computer. Cloud codex_apps connectors remain available. Desktop version 26.930.21537; observed MSIX package 26.930.2377.0.
On October 2, 2026, a fresh dot task logged codex_app failure after 208 ms and cua_repl failure after 237 ms. Both reported only "MCP server failed to start." with failureReason=null. The separate codex_apps connector became ready.
The generated app-tools directory, launcher, server, and Node runtime are accessible from the shell. A launcher-local SystemRoot guard, motivated by #49820, was applied with approval and verified by saved-byte comparison. The exact added line after
setlocalisif not defined SystemRoot set "SystemRoot=C:\Windows". It remains present, but tool recovery is not established. cua_repl launches Node directly, so it is not covered by that CMD-launcher patch.An isolated installed Node/server A/B failed without SystemRoot (exit 134, ncrypto::CSPRNG assertion) and initialized successfully with SystemRoot (exit 0). The patched CMD launcher itself still exited 1 without externally supplied SystemRoot, with no MCP reply or stderr; with SystemRoot supplied, it initialized. These are simulated environments, not actual dot child-process traces.
Desktop/native follow-ups fail before a turn starts with: invalid turn/start params: AbsolutePathBuf deserialized without a base path; code=-32602, failureReason=invalid_config. Existing dot-originated cloud_threads.send_message successfully continues the same child without permissions or settings changes. The child still lacks both native tool groups.
Temporary launcher logging was inconclusive and removed. A later dot-side test, reported by the user, completed one continuation but produced neither its startup log nor an exit code. No marker cannot distinguish failure before entry from failure to write the marker.
Please provide supported executor-side diagnostics for the actual attempted command/argv, cwd, selected manifest/root, process-creation result, exit code, stderr, and SystemRoot presence. Also investigate Windows paths in the desktop turn/start permission payload separately from native MCP startup. No reinstallation, permission expansion, security-control bypass, or scheduled-task changes were used.
The installed app includes an in-memory executor diagnostic buffer in feedback as local-executor.log when desktop logs are included and the buffer is nonempty. Its contents have not yet been retrieved or verified in this investigation. Private task IDs and timestamps can be supplied through OpenAI feedback for correlation.
Related: #49820, #49562, #49477. Shared causes remain unproven.
Zachariah-Jack commentedon Oct 2, 2026
Written by Aria, the user's AI assistant, at the user's request.
Adding a separate Windows reproduction of the dot-created task versus local-task browser-control gap. Our browser was Microsoft Edge, and the installed Microsoft Store desktop package was 26.928.4866.0. We have not reproduced the follow-up path-deserialization error reported above or established a shared root cause.
Observed sequence on October 2, 2026 (UTC)
Expected behavior and investigation request
A connected, eligible dot-created computer task should expose supported enabled browser/desktop controls, or clearly explain the missing capability or version requirement. In these tests, local execution remained available and the ordinary local task could list Edge tabs, while the dot-created tasks lacked direct controls.
Please investigate durable-task MCP startup and capability exposure compared with the working local-task path. The enterprise local-access guide specifies desktop version 26.929 or higher. Please clarify whether that requirement applies to this personal-account setup and how an appropriate Windows build is made available. The version difference remains a diagnostic lead, not a verified cause or fix.
The exact Windows build, Edge version, extension version, and full runtime versions were not captured. Private task IDs, machine/user names, file paths, tab titles/URLs, and account details are omitted.
badsuggestion commentedon Oct 3, 2026
Additional Windows reproduction on October 3, 2026 (UTC), with a working normal-session control case.
Environment: Windows x64; installed OpenAI.Codex package 26.930.3930.0; app diagnostic release 26.930.31730; local executor and plugin app-server both 0.160.0. Windows reports package registration Status
Okand no partial staging. The user reports no update was offered; restarting the desktop app did not restore the dot-created task capabilities.Reproduction and control
node_replentry point. The gap persists in fresh dot-created tasks and after restart.mcp__node_repl__js; a harmless1+1call succeeded with result2. That test verified runtime availability, not browser navigation.Expected: an eligible dot-created task receives the enabled connected computer capabilities, or a precise explanation of which capability cannot start. Actual: instructions are supplied without the required callable runtime.
Sanitized diagnostic evidence
At approximately 09:21 UTC, desktop breadcrumbs recorded:
cua_replandcodex_appstartup statusfailed,hostId=durable, errorMCP server failed to start,failureReason=null.unsupported app-server method: hooks/listandunsupported app-server method: mcpServerStatus/list.chatgpt_pubsub_transport_closed.Additional task-UI symptoms on this installation: an owner message remained queued with “This queued message could not be sent. Retry, edit, or delete it to continue the queue”; repeated retries failed. One selected task showed a blank transcript although backend history retrieval still returned messages. Some other task transcripts rendered normally. A local file preview failed even though the referenced file existed. Shared causes remain unproven.
A further CLI-only check found the browser plugin manifest declaring
./skills/while the installed directory contained no files; this prevented a prescribed browser-inventory test in that CLI session. It does not establish why the normal desktop browser path works or the dot path fails.Please investigate dot-task runtime provisioning/startup and client/app-server capability routing compared with the working normal-session path. No repair was verified. No cache reset, permission expansion, feature-flag change, or tool injection was performed. Account information, private task identifiers, user paths, browser contents, screenshots, and full logs are omitted.
BIG-legion commentedon Oct 3, 2026
Additional Windows diagnostic on October 3, 2026, prepared with Codex assistance at the owner's request.
The distinction between the routes matters here:
Recent inspected delegated-task history narrows the latter failure: the task explicitly reported no callable native send_message_to_thread, browser interaction, desktop-control, or Unity/Blender tools. It made no local-chat send attempt because the native entry point was absent. A later inventory also reported native list/read/send tools absent. Windows shell execution remained available. Reading local project files through PowerShell subsequently succeeded; that is separate from reading chat history.
Earlier diagnostics used Desktop 26.930.31428, Windows package 26.930.3748.0, and CLI 0.160.0. In that test, codex_app became ready and read an existing local chat, while cua_repl and codex-security failed with "MCP server failed to start." The running Windows package was later verified as 26.930.3930.0, with CLI still 0.160.0; browser functionality was not retested after that version check.
Scoped SystemRoot workarounds, motivated by #49820, passed isolated installed-server initialization tests. That confirms a startup dependency under the tested environments, not restored browser/computer control in a real delegated task. A subsequent authorized fresh-task creation returned "Mcp error: -32603: Internal error", so that functional validation did not run. No shared cause between missing tools, direct local-thread routing, and creation failure is established.
Post-update read-only inspection found that the generated app-tools launcher had reverted byte-for-byte to the earlier original and no longer contained the SystemRoot fallback. The new browser/CUA manifest neither explicitly supplies nor requests inherited SystemRoot; the security launcher still retains its fallback. This establishes that the earlier workarounds are not all present in the updated configuration, not the effective remote child environment or the deployed controller version. No delegated browser retest or new configuration change was performed for this check.
Please investigate capability exposure for Windows-executed durable tasks and provide a supported route for local-chat read/send. A cloud label alone should not be treated as proof that the task is disconnected from the computer. Related: #50574 and #49477.
Private paths, names, task/environment/device/account identifiers, browser URLs or contents, screenshots, credentials, project data, and raw transcripts/logs are omitted. No attachments are included.
ngroulx commentedon Oct 3, 2026
Additional Windows reproduction on October 3, 2026 (UTC), after updating at approximately 15:17 UTC.
Versions: desktop package 26.930.3930.0, app/runtime 26.930.31730, CLI 0.160.0.
This adds a comparison of both dot task launch routes on the same connected computer:
No configuration changes were made during these checks. The failure persists on this updated build; selecting the computer explicitly or creating a fresh dot task did not restore browser controls. The root cause remains unknown, and no delegated-task workaround was verified.
Could maintainers advise on supported diagnostics or recovery for the delegated capability/startup path? Additional sanitized diagnostic details can be provided if useful. Private identifiers, paths, screenshots, and raw logs are omitted.
aerethiel commentedon Oct 3, 2026
Independent confirmation with Microsoft Edge on Windows 11: desktop package 26.930.3930.0, bundled Codex 0.160.0, extension 1.26.901.11451. I’ve confirmed Edge control works in a directly started Local Work chat.
Dot-created tasks on the same connected, authorized PC can run shell commands and read files, but expose no browser-control or node_repl tools. Both explicit computer selection and the default attached-computer route reproduce this. Browser plugins are enabled.
3nk1dev commentedon Oct 4, 2026
I can reproduce both symptoms on Windows desktop package 26.930.3930.0 with bundled CLI 0.160.0.
On the same connected PC:
Manually sending a follow-up to a dot-created task initially failed with “invalid turn/start params: AbsolutePathBuf deserialized without a base path”. Diagnostics showed a Linux workspace prefix concatenated with a Windows path.
After I changed that task's permissions from Custom to “Approve for me”, follow-up messages were accepted, but Computer Use remained unavailable. This adds another confirmation of the partial recovery reported above, on this newer package.
A reboot and fresh task did not restore the missing tools, and the official app updater offered no update. The local window-capture control works; the dot-created task's Computer Use gap remains unresolved. These observations do not establish a shared root cause.
ultratintsouthport commentedon Oct 4, 2026
Additional read-only Windows evidence from October 4, 2026 (UTC).
Environment: Desktop Windows package 26.928.2636.0; codex-app-tools plugin 0.1.5; independent npm CLI 0.149.0 (not the Desktop-bundled CLI, whose version could not be verified in this restricted executor).
The approved plugin MCP override resolves codex_app as enabled, with disabled_reason=null and no tool allow/deny filters; approval mode remains prompt. Browser and Computer Use plugins also resolve installed/enabled. Windows shell execution works, but the actual task inventory contains 850 tools and no callable codex_app, cua_repl, node_repl, or native browser/computer entry point.
Selected startup fields only, 2026-10-04 UTC, hostId=durable:
Desktop diagnostics also record mcpServerStatus/list rejected with -32601, "unsupported app-server method: mcpServerStatus/list". Configuration resolution and historical ready logs are not evidence that tools are callable in this task.
The merged environment-filtering fix in #50129 looks relevant, but we have not established this task's root cause or whether its durable controller/executor includes that fix. Could maintainers confirm rollout to this Windows execution path, expose the underlying startup exception, and advise a supported recovery that permits list/read/send to an existing native Desktop session without duplicating its browser task or weakening approvals?
No restart, reinstall, launcher patch, manual server launch, permission expansion, or browser operation was performed. No attachments, private task/account identifiers, paths, credentials, screenshots, conversation contents, or raw logs are included.
Zachariah-Jack commentedon Oct 5, 2026
Follow-up to our October 2 report: native
codex_applist/read/send tools have continued to disappear from the dot-created Windows intermediary used to reach an existing local task. We have repeatedly recovered a working relay after a temporary, SystemRoot-only configuration experiment, including a verified post-restoration test on October 5. This is a workaround observation, not a confirmed root cause or durable repair.Environment and scope
Windows computer connected to dot; browser verification used the user's local Microsoft Edge. The latest desktop runtime recorded in our diagnostics was 26.930.31730 on October 3. We did not recapture the app/runtime versions for the October 5 experiment. The exact Windows, Edge, extension, and hosted-controller builds for that experiment are not captured.
Observed sequence, UTC
list_threads,read_thread, andsend_message_to_thread. The check stopped before resolving or contacting the local task. Restart had not restored this route.SystemRoot=C:\WINDOWSto the generatedcodex_appservice environment and created a fresh intermediary. The original configuration was restored byte-for-byte at 19:47:12; the original hash and rollback-watcher exit were verified.What this establishes, and what it does not
The recovered native relay can work after exact restoration; tool presence or message acceptance alone was not our success criterion. The recovery check covered a newly completed local tab-enumeration request and readback. It does not establish direct browser/CUA recovery in the dot-created intermediary, every messaging direction, or continued operation across future lifecycle changes.
We have not captured the actual failing MCP subprocess environment or demonstrated that the temporary value alone caused recovery. Creating a fresh intermediary and unobserved runtime state are confounding factors. No deterministic clean-install reproduction or failure rate is available.
PR #50129 merged on October 2 and preserves SYSTEMROOT, TEMP, and TMP for remote MCP servers. Deployment in our affected hosted/controller path is unverified. Our trial changed only SystemRoot; it was not a test of the full upstream change. Related environmental evidence is tracked in #49820.
Could maintainers identify the deployed remote-MCP/runtime version and correlate startup, final tool-catalog exposure, and lifecycle refresh for an affected task? Please provide a supported recovery that does not require repeatedly modifying generated configuration.
Private machine/user names, paths, task IDs, configuration contents/hashes, tab titles/URLs, and raw logs are omitted. No attachments are proposed.
Current version snapshot (collected after the incidents)
Read-only inventory on October 5, 2026, UTC:
26.930.4958.0, x64, verified at 17:50:10 from the package manifest associated with the running executable.26200.9550, x64, observed at 17:48:18.154.0.4258.53, observed at 17:47:09.These are later local-environment measurements, not verified incident-time versions or a new reproduction on these builds. They do not identify the hosted dot/controller/backend build. Active extension and bundled-agent versions remain unverified.
Written by Aria, the user's AI assistant, at the user's request.
deciduus commentedon Oct 5, 2026
Following Zachariah-Jack’s report, I ran a bounded Windows test on October 5, 2026, with Desktop package 26.930.4958.0 and bundled CLI/app-server 0.160.0.
This verifies an operational route from a cloud-backed diagnostic to a native local Codex session, including continuation after restoration. It does not prove SystemRoot caused recovery: we lack an unmodified creation baseline and a measurement of the MCP subprocess environment.
Browser verification did not run because the diagnostic action was blocked by approval review. We are not claiming browser recovery, a durable fix, or resolution of the separate HTTP 403 and AbsolutePathBuf failures.
Could maintainers confirm whether PR #50129 is deployed in this Windows durable-controller path and recommend a supported native-local delegation route that does not require editing generated configuration?
No private paths, machine names, task IDs, credentials or raw logs are included.
UtopianYoungChung commentedon Oct 7, 2026
Additional isolated reproduction for the Windows/durable follow-up failure, with a narrowly bounded candidate for discussion.
I reproduced the path-deserialization boundary using the bundled
codex-cli 0.162.0-alpha.2on native Windows and Linux, plus the installed desktop turn-builder function in a fixture. Each parser probe used a clean temporaryCODEX_HOME, a sanitized process environment, and a nonexistent test thread. No authenticated task, model inference, permission change, or installed application modification was involved.The field distinction matters:
environments[].cwd/runtimeWorkspaceRootssandboxPolicy.writableRootsorruntimeWorkspaceRootsAbsolutePathBuferror/tmp/.../C:\...path in those top-level strict fieldsAbsolutePathBuferrorcwdalone“Parses” means the probe reaches
thread not found; it does not mean a task executes. The displayed path shapes are illustrative, for exampleC:\Example Workspace\Projectand/tmp/cloud/workspace/C:\Example Workspace\Project.An unchanged Custom-policy fixture passed through the original installed turn builder produces environment-qualified Windows paths and null top-level cwd/runtime roots, but also redundantly sends the inherited Windows roots in top-level
sandboxPolicy. That generated request reproduces the Linux parser error. This isolates a possible failing field without proving that it is the field rejected in the original live request; that payload and the production durable receiver build were not captured.The matching public source explains the type difference: turn environment and start parameters and sandbox policy root types.
The candidate omits only a redundant inherited custom sandbox-policy override when the selected non-local environments and complete policy are unchanged. It does not select a different permission profile. Explicit policy/profile/root/environment/approval changes retain their existing behavior. Under the matching receiver contract, a null policy plus null profile preserves existing permission and network state; unchanged non-local-only environments preserve the fallback cwd. See environment/settings override handling and session configuration application.
There is an unresolved production prerequisite: client snapshot equality does not prove that queued settings have been acknowledged by the durable backend. Before such an omission can be shipped, it needs an authoritative settings-revision/acknowledgment condition and confirmation of the receiver contract. No such gate was established in the tool-specific live path during this investigation.
The isolated candidate passes 32 guard/integration checks and the 42-case Windows/Linux parser matrix has its expected outcomes. The eligible Linux fixture now parses; an explicit changed Windows-root policy still fails there rather than being silently discarded. The mixed-root/no-environment Windows case remains unresolved.
No production repair is claimed. The candidate is an extracted-function fixture, not a supported installed patch. The next useful maintainer check is the live
turn/startfield/receiver trace and the settings acknowledgment boundary, followed by a regression test that proves unchanged permissions and a real follow-up round trip.yaoyuliu621-collab commentedon Oct 11, 2026
Follow-up on 2026-10-11: a previously working user-created local chat → Dot main conversation messaging route now fails. This updates the successful local-to-Dot observation in my original comment. Please investigate this separately from the durable-child browser/tool gap and the AbsolutePathBuf error unless a shared cause is established.
Verified before/after
The sender is the same manually created local diagnostic chat, not a Dot-created child. Its original tool-call records show successful
mcp__codex_app__send_message_to_threadcalls to the then-current Dot main conversation on October 6 and 7. Desktop logs independently show successful message admission:turn/addUserMessageerrorCode=nullturn/addUserMessageerrorCode=nullturn/addUserMessage-32600, gRPC status 5,thread not foundCurrent Windows package:
26.1007.2314.0. Hosted/controller version is unknown.Important comparison limit: the Dot main conversation ID has changed since the successful tests. We verified the current ID from an actual Dot-to-task delegation and tried that ID as well as the old one; both failed. This is the same sender/tool/underlying method and intended local-to-Dot workflow, not proof of identical target or backend state across versions.
Current bounded test
hostId=durablefailed.hostIdso the supported tool could discover the target automatically. It failed identically.thread/readreturnederrorCode=nullat 03:55:19.658Z, followed by failedturn/addUserMessageat 03:55:20.669Z. The native reader separately returned an empty history and null title; a successful read request did not establish usable conversation contents or message delivery.6b49fcbd-a82a-4189-b26f-71c1390c78e0.Some requested entity was not found: thread not found, code-32600,grpcStatusCode=5.thread access denied, but that same symptom occurred before the successful October 7 send. It is therefore insufficient by itself to explain this failure.There is also partial browser progress: a Dot-created intermediary used native
codex_app.create_threadto create a projectless host=local task. That local task successfully controlled Chrome through example.com → IANA and closed its test tab. This does not establish browser recovery inside the original durable task or repair the local-to-Dot messaging failure.Could maintainers correlate the failed request with the successful read and prior admissions, confirm the supported local-chat-to-Dot-main-conversation route, and advise a supported recovery? Target mapping/lifecycle or admission behavior are possibilities, not confirmed causes. We have not established that the app update caused this change.
No settings, launchers, environment variables, or security controls were changed for this comparison. No private APIs or legacy bridge were used. Private chat IDs, paths, screenshots, and transcript/log archives are omitted.
yaoyuliu621-collab commentedon Oct 12, 2026
Follow-up: zh-CN native screenshot control test and Dot messaging — 2026-10-12
Following my previous routing report, we performed a bounded test in the manually opened local desktop chat. This adds evidence about native browser screenshots after obtaining the local tools; it does not establish that the earlier missing-tools, messaging, and screenshot symptoms share a cause.
Environment
zh-CN(queried locally).26.1007.21434, build13901.26.1007.2314.0.@oai/skynative component SHA-256:58fff5e2359aa09528f48ef37651b9013b204f99e2fd381f0d3d980cf9d2e88d; Authenticode status: Valid.Actual control test
@oai/skyAPI, selected the returned Task Manager window, activated it, and requestedget_window_state({include_screenshot:true, include_text:false}).Passed: actual screenshot pixels were returned and displayed, with reported dimensions 768 × 584. Native window capture is therefore not universally broken on this machine.
https://example.com/in local Chrome and read its page content.list_windows()returned the exact title Example Domain - Google Chrome, removing the previous uncertainty about which tab was active.get_window(), then calledget_window_state({include_screenshot:true, include_text:true}).Failed: Computer Use reported that it could not determine the current browser URL on Windows with enough confidence to enforce policy and stopped the turn. No browser screenshot or accessibility result was returned. We stopped as instructed.
Possible localization link — not confirmed causality
The component hash above exactly matches the binary analyzed in the ko-KR report on #25271. That report describes a localized control-type string being compared with the English literal
document.Our independently observed combination is: zh-CN environment + matching component hash + successful non-browser capture + native Chrome URL-confidence failure even after confirming the correct foreground test page.
We have not captured the actual localized UI Automation control-type value or executed branch in our failed request, and have not performed an OS-language A/B. The hash match ties our installed file to that static analysis; it does not independently reproduce the disassembly or prove localization is the sole cause.
Could maintainers trace native Document classification and URL extraction on zh-CN? If the localization hypothesis is confirmed, please use the language-independent control type (e.g.
UIA_DocumentControlTypeId) while preserving correct window/URL association and normal policy enforcement. A supported diagnostic procedure or fixed release/build would help us retest.Separate messaging retest
A native
send_message_to_threadattempt to the current Dot conversation, whose identity was checked against a recent delegated task's source, still returned:Some requested entity was not found: thread not foundNo delivery was confirmed. This is a separate observation, not evidence that localization causes messaging failures.
No OS-language changes, binary patches, system-setting changes, policy overrides, or alternate capture bypasses were made. Private chat IDs, personal paths, screenshots, and raw logs are omitted.
chiyanta3900-ai commentedon Oct 14, 2026
Additional read-path observation — 2026-10-15 (JST)
This is a bounded update to the local Codex → Dot main-conversation routing observations in this issue. It does not establish a shared cause with the Computer Use or AbsolutePathBuf failures.
Environment: Windows desktop, a user-created local Codex chat, native Codex app thread tools available. Exact current desktop build was not collected; installed-package lookup was denied, so previous report versions are not being presented as current.
Observed:
mcp__codex_app__read_threadwith that ID, limit 1 and automatic host discovery returned success, kind=codex, hostId=durable, status=idle, null title, empty preview, turns=[], hasMore=false, nextCursor=null./dots/homevisibly contained messages, including October 14 user messages and Dot replies.Important limits:
Please clarify the supported way for a local Codex chat to discover the CURRENT Dot main-conversation destination and read/send through native thread tools. If this type of destination is unsupported or stale, please return an actionable mapping/unsupported-destination result rather than a successful empty thread snapshot that cannot be distinguished from an empty conversation.
No private IDs, user paths, message contents, credentials or raw log archives are included. No permissions, security settings, sessions or operational tasks were reset.