You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Codex Desktop macOS: delegated Central follow-up loses selected capability roots and completes without tool dispatch #43350
Direct userMessage: 12 cua_repl.js calls. Delegated functionCallOutput via send_message_to_thread: selected_capability_root_count=0, tool items=0, no lifecycle or batch dispatch.
Expected
A supported continuation mechanism preserves required owner capabilities or documents a root-capable alternative.
Minimal reproduction
Start an owner thread with CUA capability; compare a direct userMessage continuation and a send_message_to_thread continuation; inspect delivery type, selected capability roots, and tool items.
The production workflow is blocked before any transaction. DOCSWAVE auth is separately healthy (200); active transaction is 0; lock is NONE; Registry and checkpoint were not changed.
Questions
Is there an official programmatic root/direct userMessage continuation entrypoint for the same thread?
Is loss of selected capability roots for delegated functionCallOutput intended behavior?
Is there a supported capability-selection or inheritance mechanism for delegated CUA/MCP turns?
What is the official path for continuing an existing root-capable workflow from scheduled automation?
Is selected_capability_root_count=0 a known issue in this build?
Is an automation restore ACK that renders a card without a persisted ID/readback a known issue?
Notes
No policy/server-regression assertion. Repeated delegated retries, automation restore/create retries, and local capability injection were intentionally suppressed.
Sanitized incident: DOCSWAVE-ROUTING-20260907-01. No credentials, cookies, tokens, OAuth codes, or company document contents are included.
Adding a sanitized macOS reproduction from 2026-10-06. This appears related to the delegated-capability symptom in this issue, but the shared root cause is not confirmed.
macOS 26.5 (25F71); uname -mprs: Darwin 25.5.0 arm64 arm.
App-bundled CLI: 0.160.0. Separate PATH CLI: 0.146.0. Both were inspected read-only; the PATH CLI was not used to execute the affected task.
A dot delegated browser work to its connected Mac. The user reports the Mac/browser are connected and authorized, and that ordinary local Codex sessions can use the browser. That ordinary-session comparison has not been independently reproduced in this diagnostic task.
Chrome is running, confirmed by the bundled browser plugin's documented running check.
Reproduction
From a dot, delegate a task requiring the existing browser session on the connected Mac.
The delegated task receives the installed Chrome, Browser, and Computer Use skills, can read their bundled files, and can execute ordinary shell commands on the Mac.
Follow the browser skill bootstrap, which requires the mcp__node_repl__js tool.
Inspect the full currently callable tool catalog. No node_repl or cua_repl execution tool is exposed, and no tool-search capability exists to load it. No browser runtime can therefore be initialized.
Send a follow-up to investigate the missing tool: it remains absent in this task.
Confirmed diagnostics
The app-bundled CLI's plugin listing reports:
browser@openai-bundled: installed=true, enabled=true, version 26.930.31730.
chrome@openai-bundled: installed=true, enabled=true, version 26.930.31730.
computer-use@openai-bundled: installed=true, enabled=true, version 1.0.1001365.
The app-bundled CLI reports browser_use, browser_use_external, in_app_browser, and computer_use as enabled. This is local configuration evidence, not proof of the delegated task's effective capability selection.
The browser skill and client files exist. The observed failure is before browser selection, extension communication, website navigation, or authentication.
Some mcp__codex_app__* tools are exposed, but the read-only app update check returns: App updates are only available on the local desktop host. This is another surface distinction; it does not by itself prove a bug.
Expected and actual
Expected: a supported delegated task should receive the approved browser execution capability, or clearly explain which capability is unavailable and provide a supported recovery route.
Actual: the task receives instructions for installed browser functionality but lacks the required execution tool. Working local shell access does not provide working browser access.
These identifiers were explicitly authorized for this report. No full session, raw logs, account email, browser contents, credentials, financial data, or unrelated conversation content are attached.
Remaining uncertainty
This evidence points toward task capability provisioning or routing rather than a missing browser plugin. It does not establish selected_capability_root_count=0, an intentional delegated-task limitation, or the same implementation defect as the original report. No capability injection, manual browser-server launch, permission changes, reinstalls, or unsupported browser automation were attempted.
Please confirm the supported way to give this delegated task its approved browser capability, and whether direct local task creation is currently required.
Activity
samvitjatia commentedon Oct 6, 2026
Adding a sanitized macOS reproduction from 2026-10-06. This appears related to the delegated-capability symptom in this issue, but the shared root cause is not confirmed.
Environment
com.openai.codex.uname -mprs:Darwin 25.5.0 arm64 arm.Reproduction
mcp__node_repl__jstool.node_replorcua_replexecution tool is exposed, and no tool-search capability exists to load it. No browser runtime can therefore be initialized.Confirmed diagnostics
The app-bundled CLI's plugin listing reports:
browser@openai-bundled: installed=true, enabled=true, version 26.930.31730.chrome@openai-bundled: installed=true, enabled=true, version 26.930.31730.computer-use@openai-bundled: installed=true, enabled=true, version 1.0.1001365.The app-bundled CLI reports
browser_use,browser_use_external,in_app_browser, andcomputer_useas enabled. This is local configuration evidence, not proof of the delegated task's effective capability selection.The browser skill and client files exist. The observed failure is before browser selection, extension communication, website navigation, or authentication.
Some
mcp__codex_app__*tools are exposed, but the read-only app update check returns:App updates are only available on the local desktop host.This is another surface distinction; it does not by itself prove a bug.Expected and actual
Expected: a supported delegated task should receive the approved browser execution capability, or clearly explain which capability is unavailable and provide a supported recovery route.
Actual: the task receives instructions for installed browser functionality but lacks the required execution tool. Working local shell access does not provide working browser access.
Diagnostic identifiers
01a11081-487b-7635-81be-4ff5c654907301a11081-65ec-736e-93db-fe156ba8953bThese identifiers were explicitly authorized for this report. No full session, raw logs, account email, browser contents, credentials, financial data, or unrelated conversation content are attached.
Remaining uncertainty
This evidence points toward task capability provisioning or routing rather than a missing browser plugin. It does not establish
selected_capability_root_count=0, an intentional delegated-task limitation, or the same implementation defect as the original report. No capability injection, manual browser-server launch, permission changes, reinstalls, or unsupported browser automation were attempted.Please confirm the supported way to give this delegated task its approved browser capability, and whether direct local task creation is currently required.