[macOS] New prompts hang before `turn/start` while Remote Control device-key calls occupy all libuv workers

What version of the Codex App are you using (From “About Codex” dialog)?

The live hang was captured on ChatGPT/Codex Desktop 26.707.72221 (CFBundleVersion 5307) with bundled codex-cli 0.144.2.

After restarting, the app updated to 26.707.91948 (CFBundleVersion 5440) with bundled codex-cli 0.144.5. The newer build is currently healthy, but the same Remote Control device-key calls are still present and there is not yet enough runtime evidence to say the failure mode is fixed.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

Darwin 24.6.0 arm64 arm
macOS 15.7.1 (24G231)
Apple Silicon

What issue are you seeing?

Summary

Codex Desktop intermittently enters a state where every newly submitted prompt spins forever in the composer, while turns that were submitted before the failure continue running normally in the background. Force-quitting and relaunching the app temporarily restores sending; a full macOS restart also cleared the captured failure state.

A live macOS sample taken before restarting shows a specific immediate failure mechanism: all four observed libuv-worker threads in the desktop main process were blocked for the entire 10-second sample inside synchronous Security.framework / CryptoTokenKit calls initiated by remote-control-device-key.node.

One worker was blocked while signing:

Napi::AsyncWorker::OnExecute
  (anonymous namespace)::SignDeviceKeyWorker::Execute
    SecKeyCreateSignature
      -[TKSEPClientTokenObject operation:data:algorithms:parameters:error:]
        -[TKRemoteSEPKey signDigest:error:]
          -[TKCTKDConnection withError:invoke:]

The other three workers were blocked while loading the public key:

Napi::AsyncWorker::OnExecute
  (anonymous namespace)::GetDeviceKeyPublicWorker::Execute
    (anonymous namespace)::CopyPrivateKey
      SecItemCopyMatching
        -[TKSEPClientTokenSession objectForObjectID:error:]
          -[TKRemoteSEPKey _initWithObjectID:authContext:forceSystemSession:error:]
            -[TKCTKDConnection withError:invoke:]

Each stack remained unchanged across all 7,446 captured samples for its worker. The UI displayed the send spinner, but the blocked prompt never produced an app-server turn/start event. At the same time, already-running turns continued, and the current app-server remained alive.

This strongly suggests that the prompt is blocked in the desktop main process before submission to app-server. Saturation of the shared libuv worker pool by Remote Control device-key work is the leading explanation for the send failure, although the exact dependency between prompt submission and that pool requires confirmation from the implementation.

Important boundary: trigger vs. product resilience

The original stall may be triggered by a macOS secd / ctkd / CryptoTokenKit / Secure Enclave failure. Temporally correlated system logs contained Security responsiveness warnings and secd / trustd errors, although those logs do not identify which component initiated the stall. I therefore cannot claim Codex created the underlying OS-level stall.

However, an OS security-service call becoming slow or stuck should not permanently disable all local prompt submission. Whatever safeguards currently exist were not sufficient to bound these calls, prevent concurrent device-key work from occupying the full shared pool, or degrade Remote Control without affecting local prompt submission.

What steps can reproduce the bug?

The failure is intermittent; I do not currently have a deterministic way to force the underlying macOS security-service stall.

Observed sequence:

1. Use Codex Desktop on Apple Silicon macOS with Remote Control connections enabled.
2. Continue normal use while existing agent turns are running.
3. Eventually submit a new prompt.
4. The composer send button spins indefinitely.
5. Additional new prompts cannot be submitted, but previously submitted agent turns continue working.
6. Before restarting, run:

``bash
sample "$(pgrep -nx ChatGPT)" 10 -file ~/Desktop/ChatGPT-hang.txt
``

1. Inspect the main-process worker threads. In the captured incident, all four libuv-worker threads were continuously blocked in the device-key stacks shown above.
2. Inspect desktop logs. The blocked prompt has no turn/start; after restart, a new prompt reaches turn/start normally.

The problem reproduced even after orphaned desktop app-server processes had been removed. During the captured recurrence, there was exactly one current desktop app-server, so multiple app-server instances are not required for this failure.

What is the expected behavior?

Local prompt submission should remain available even if Remote Control device-key access or a macOS security service is stalled.

At minimum, Codex Desktop should:

• isolate device-key operations from the shared worker pool used by unrelated desktop tasks;
• bound the caller-visible wait and ensure timed-out native calls cannot continue consuming shared worker capacity; if the underlying APIs cannot be cancelled, isolate them in a dedicated helper or restartable process;
• deduplicate concurrent public-key loads and signing/refresh requests;
• avoid making local prompt submission wait on Remote Control refresh or authentication maintenance;
• degrade or temporarily disable Remote Control with a visible error instead of leaving the composer spinning forever;
• expose enough structured logging to correlate a pending send with worker-pool starvation.

Additional information

Healthy-state comparison after macOS restart

A same-method 5-second sample after reboot showed the opposite pattern:

• all four libuv workers were idle for approximately 3,927–3,937 / 3,938 samples each;
• the same remote-control-device-key.node signing/public-key paths appeared only briefly (approximately 5–10 samples) and returned;
• new prompts reached app-server turn/start in approximately 1–12 ms;
• there was one desktop main process and one current child app-server, with no orphaned desktop app-server.

This working-vs-hung comparison is why I believe the captured device-key worker saturation is strongly implicated in the failure rather than incidental background activity.

What this report does and does not claim

Confirmed from the live capture:

• the send UI was stuck indefinitely;
• already-running turns continued;
• the blocked prompt did not reach app-server turn/start;
• all four shared libuv workers were blocked for the full sample in remote-control-device-key.node calls into CryptoTokenKit / Secure Enclave;
• restart/reboot cleared the state, and the same calls returned quickly in the healthy sample.

Not yet confirmed:

• whether macOS, Codex, or their interaction creates the initial Secure Enclave/CryptoTokenKit stall;
• whether the four calls accumulated over time or were launched together;
• whether 26.707.91948 contains any mitigation (the issue has not yet recurred long enough to establish that).

Related reports

• #26235: Codex Desktop hangs after sending a prompt on macOS
• #18264 and #18378: send spinner / UI stalls after Send on macOS
• #23289 and #30075: Remote Control device-key / Secure Enclave integration failures
• #25719: Codex Desktop interaction with macOS security services (syspolicyd / trustd)
• #11090: UI freezes with orphaned app-server processes (ruled out as a necessary condition in this recurrence)

I intentionally did not attach the full process listing because it contains unrelated local paths and process arguments. I can provide a further-redacted full sample capture privately if an OpenAI engineer needs it.