Repository navigation
macOS dot: delegated task passes text/file checks, but native Computer Use getApp hangs then returns Transport closed #49662
Description
What version of the Codex App are you using (From “About Codex” dialog)?
ChatGPT/Codex desktop 26.928.21956, build 12404, prod channel. The last in-app update check returned up_to_date.
Bundled CLI: 0.159.2. Computer Use helper: 26.924.1001281, build 1001281.
What subscription do you have?
Personal account space, not an enterprise/team workspace. Exact subscription tier not supplied.
What platform is your computer?
MacBook, macOS 26.4 (25E246), arm64. Google Chrome 154.0.8037.58.
What issue are you seeing?
A dot can create a task on the connected, authorized Mac, receive a unique marker reply, and have that same task create a small local file and independently read it back. However, the next turn requesting native Computer Use waits without a result, then returns Transport closed. The screenshot step is never reached.
The controlled acceptance sequence on September 30, 2026 was:
| Step | Result |
|---|---|
| A: Dot dispatches a unique marker; task replies with that marker | Passed |
| B: Same task creates a uniquely named small file and independently reads it back | Passed |
| C: New Computer Use session selects the existing Chrome app, then captures it without navigation or clicks | Failed before screenshot |
C began around 15:14 UTC. The requested first call was:
await cua.getApp("com.google.Chrome");Tool: mcp__cua_repl.js. Only after a successful app selection was the task to call getScreenshot() separately. It was instructed not to use getState(), navigate, or click.
The final reported error was:
Transport closed
The tool reported waiting approximately 20 minutes 21 seconds. No screenshot was produced. The error was delivered after the connection closed; it does not identify why the original call stalled or prove where it first blocked. No request ID was supplied in the returned error.
An earlier, separate attempt at await cua.getState(); returned at 14:33:33 UTC:
js execution timed out; kernel reset, rerun your request
The user manually quit and reopened the desktop app at approximately 14:57 UTC, before the A/B/C sequence above. Errors from old sessions after that restart are not being treated as proof that fresh connections failed.
What steps can reproduce the bug?
- Connect and authorize the Mac to the dot; leave the desktop app running.
- Have the dot create a fresh task and request a unique text marker. Confirm the actual reply.
- In the same task, request creation of a small test file and independent readback. Confirm both.
- Request a fresh Computer Use session to select existing Chrome with
cua.getApp("com.google.Chrome"), followed by a screenshot only on success. Do not navigate or click. - Observe that the app-selection tool call does not return promptly and eventually reports the transport error above.
This is the recorded acceptance sequence, not a claim of deterministic reproduction across every installation. Further repeated screenshot attempts have been stopped.
What is the expected behavior?
The dot-created task should return the selected app state and screenshot, or fail promptly with an actionable error and correlation ID indicating whether dispatch, local policy/approval, native control, or result delivery failed.
Please help trace the first Computer Use call across cloud orchestration, local executor, native tool transport, and result return. A successful task creation, online status, or successful screenshot from a separate local chat should not substitute for dot-to-local end-to-end verification.
Additional information
Read-only local diagnosis after the restart found:
- The local executor logged connection to rendezvous at 14:57:22.071 UTC.
- The Computer Use helper and Chrome were running.
- Local permissions inspection recorded allowed ScreenCapture and Accessibility entries for ChatGPT and the Computer Use helper. This does not establish that every policy/approval path succeeded.
- A search of the inspected local desktop logs did not find the exact C task/turn IDs. Native helper log filtering around 15:14 also did not expose the corresponding request. Absence of these entries does not prove the request was never dispatched.
- Desktop
hostId=durableWebSocket attempts separately continued reportingopen_timeout, close code1006, andinitialized=false, including 15:14:25.700, 15:29:36.019, and 15:31:55.955 UTC. - With the existing loopback system proxy, an unauthenticated endpoint check could complete proxy CONNECT and TLS; direct connectivity timed out/reset. An HTTP 403 from that check is not authenticated WebSocket initialization.
- A causal dependency between the failing durable connection and native
getApphas not been established. A/B succeeded despite the observed durable errors. - The user reports that separate local Codex browser operations have succeeded. We have not established that those used the identical tool session, route, or caller context.
No proxy, DNS, permissions, application package, or internal conversation database was changed as a diagnostic workaround. No security validation was bypassed. The existing VPN has no exposed TUN setting; we are seeking a supported remedy, not a presumed TUN requirement.
Related reports reviewed:
- macOS: cua_repl does not respawn after launch.mjs/node_repl exit; createBrowserTab returns Transport closed in ~1ms #44518 concerns a stale/dead Computer Use MCP child and immediate
Transport closedin another setup. The long wait here is different; no shared cause is asserted. - Improve discovery and wrong-route diagnostics for dot continuation of local Codex chats #49482 tracks local-chat discovery/wrong-route diagnostics. In this setup, a cloud-thread send to an existing local chat separately returned
CloudThreadNotFoundError. That lookup failure is distinct from the fresh task that passed A/B here. - Windows desktop: dot fails to start local tasks with DesktopTaskWorkspaceUnavailableError #49423 fails before local task creation on Windows; our Mac can create and execute basic tasks, so this is not a reproduction of its primary failure.
The official personal dot documentation describes working with local tasks: https://learn.chatgpt.com/docs/dots/tasks-and-memory . We have not established that the 26.929 requirement in the enterprise guide applies to this personal account.
Private task/turn IDs, environment IDs, device names, usernames, local file paths, credentials, screenshots, and unfiltered logs are intentionally omitted from this public report. Private correlation details can be supplied through an appropriate support channel if requested. Prepared with AI assistance and submitted at the affected user's explicit request.
Activity
JRo1016 commentedon Oct 6, 2026
I'm seeing the same symptom on a Mac mini: native Computer Use app selection hangs and eventually returns
Transport closed. Adding these details and an in-app feedback reference for correlation. I haven't established whether the underlying cause is the same.Feedback reference:
no-active-thread-01a11102-9264-73f1-8729-92798e0ffb77Observed behavior:
await cua.getApp('com.apple.MobileSMS');call returnedTransport closedafter roughly 27 minutes, despite a requested 5-second tool timeout. The screenshot step was not reached.Reproduction on this setup:
await cua.getApp('com.apple.MobileSMS');.Transport closed.Expected: return the app state, or fail within the requested timeout with an actionable error.
Troubleshooting and environment:
No root cause has been established.
sethlfowler commentedon Oct 6, 2026
I'm seeing a similar native-app control hang on my Mac.
On October 5, 2026, local file and browser tasks worked, but trying to control Messages hung for about 20 minutes and then returned "Transport closed." Restarting Messages did not resolve it. I haven't established whether this has the same underlying cause as the original report.
The macOS version and desktop app build were not captured for this report.
Expected behavior: native app control should return a result or fail promptly with an actionable error, rather than leave the task waiting for around 20 minutes. Is there a known fix, or a supported diagnostic procedure to capture what is failing? Please point me to a private support route if correlation details are needed.
WilliamSung82 commentedon Oct 8, 2026
I'm seeing a similar symptom on a Mac mini with ChatGPT desktop 26.1002.52244 (build 13536).
Dot-created local tasks can run terminal commands, but built-in Computer Use calls, including cua.getApp for WeChat and a reset attempt, fail with "Transport closed". Restarting the desktop app did not fix it.
Separate native macOS screen-capture and Accessibility checks subsequently worked with the existing permissions, without any settings changes. This does not establish the root cause or confirm recovery of the built-in Computer Use path.
Is there a supported recovery procedure or a known fix for this symptom?
linerking commentedon Oct 9, 2026
Adding a similar observed incident from October 9, 2026 (dot-created local task on macOS). The native app-selection timeout is independently evidenced; a shared root cause with this issue is not established.
Environment
Read-only diagnostic results
exec_command(cmd: "pwd", login: false)returned promptly, exit code 0.cua.getState()returned in approximately 1.2 seconds and showed Chrome running.cua.getApp("com.google.Chrome")failed after 120.469 seconds with:Sky Computer Use request timed outThe user continued seeing a spinner and initially perceived the task as stuck at the directory-listing step. During connection interruptions/reconnections, a subsequent turn remained reported as
inProgressacross several checks without fresh visible actions. We cannot establish whether this reflects blocked execution, delayed results, or stale UI/status. Archiving the task at the user's request did successfully stop it; we are not reproducing the Stop/archive failure in #50785.Important exclusion
A separate operation displayed as
HTTPS Downloadfailed after 281.959 seconds. The destination website subsequently showed account verification pending when the user clicked manually. Therefore the download failure is not being reported as a confirmed Codex download bug. An earlier agent statement that website verification had passed was an incorrect inference from the available download button, not diagnostic evidence.Expected
Selecting a running application should return app state or a bounded, actionable error. After tool failure or reconnection, the task should clearly distinguish active work, a pending tool response, approval, disconnection, and failure, and expose a supported recovery/cancellation path.
The controlled contrast here is responsive shell/app inventory versus failing Chrome app selection. Further repetitive browser/download attempts have stopped. No permissions, network configuration, or browser settings were changed as a workaround.
No private task IDs, device names, local paths, account/profile details, screenshots, credentials, or raw logs are included. Prepared with AI assistance and posted at the affected user's request.