Computer Use crashes SkyComputerUseService when inspecting Outlook on macOS

[NewCoffee7477]

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

26.429.30905 (build 2345)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Codex Computer Use fails when get_app_state is called for Microsoft Outlook on macOS.

The user-visible failure is:

NSOSStatusErrorDomain Code=-609 "connectionInvalid"

Local macOS diagnostic reports show that SkyComputerUseService, bundle com.openai.sky.CUAService, build 770, crashes during the operation.

The crash signature is consistent across multiple reports:

EXC_BAD_ACCESS
SIGBUS
Bus error: 10
Thread stack size exceeded due to excessive recursion

This does not appear to be a general Computer Use outage because Computer Use can still inspect other apps successfully. It also does not appear to be a basic macOS privacy-permission failure because Accessibility and Screen Recording permissions are already granted for Codex and the Computer Use helper.

What steps can reproduce the bug?

1. Open Microsoft Outlook for macOS.
2. In Codex GUI, use Computer Use to call get_app_state for Microsoft Outlook.
3. Observe that the tool fails with NSOSStatusErrorDomain Code=-609 "connectionInvalid".
4. Check macOS diagnostic reports and observe SkyComputerUseService crashes with stack exhaustion / excessive recursion.

The same Computer Use setup can inspect Finder, Microsoft Teams, and Apple Calendar, so the failure appears specific to the Outlook app-state path.

What is the expected behavior?

get_app_state for Microsoft Outlook should return a usable accessibility tree or fail with a controlled, non-crashing error. The Computer Use helper service should not crash.

Additional information

Impact: Outlook desktop automation is blocked because Codex cannot safely inspect the Outlook UI before taking actions.

The issue was already occurring before an Outlook update/reboot that was later attempted as troubleshooting, so the Outlook update should not be treated as the initiating cause.

[NewCoffee7477]

Update after Codex app version change:

I retested this on May 6, 2026 after Codex updated from previous issue baseline 26.429.30905 build 2345 to current Codex app 26.429.61741 build 2429.

Other relevant versions are unchanged: Computer Use helper com.openai.sky.CUAService version 1.0, build 770; Microsoft Outlook 16.110, build 16.110.26042837; macOS/Darwin 25.5.0 arm64.

Result: get_app_state for Finder still succeeds with CUA App Version 770, but get_app_state for Microsoft Outlook still fails with NSOSStatusErrorDomain Code=-609 "connectionInvalid".

A fresh crash report was created during the retest: SkyComputerUseService-2026-05-06-070532.ips.

The crash signature is still the same as the original report: EXC_BAD_ACCESS, SIGBUS, Thread stack size exceeded due to excessive recursion, Bus error: 10, recursion depth 168.

So the May 5 Codex app update to 26.429.61741 build 2429 did not resolve this Outlook-specific Computer Use crash. The issue still appears isolated to Outlook app-state inspection: Finder remains inspectable through Computer Use while Outlook crashes the helper path.

[NewCoffee7477]

Update after retesting with the new Codex / Computer Use build on May 8, 2026:

Installed versions now are:

• Codex app: 26.506.31004 build 2604
• Computer Use helper / SkyComputerUseService: com.openai.sky.CUAService version 1.0, build 780
• Microsoft Outlook: 16.110, build 16.110.26050319
• macOS/Darwin: 25.5.0 arm64

This is a real Computer Use helper change from the earlier failing baseline, where SkyComputerUseService was build 770.

Retest result:

• get_app_state for Finder succeeds with CUA App Version 780.
• get_app_state for Microsoft Outlook still fails with NSOSStatusErrorDomain Code=-609 "connectionInvalid".
• The Outlook retest generated a fresh crash report: SkyComputerUseService-2026-05-08-151624.ips.

Fresh crash signature from the build 780 report:

• EXC_BAD_ACCESS
• SIGBUS
• Thread stack size exceeded due to excessive recursion
• Bus error: 10
• recursion depth: 157

Conclusion: the update to Codex 26.506.31004 / Computer Use helper build 780 did not resolve this Outlook-specific crash. The failure still appears isolated to Outlook app-state inspection because Finder remains inspectable through Computer Use while Outlook still crashes the helper path.

[NewCoffee7477]

Update after retesting on a newer Codex build:

• Codex app: 26.506.31421 build 2620
• Computer Use helper: com.openai.sky.CUAService version 1.0, build 780
• Microsoft Outlook: 16.110 build 16.110.26050319

The issue still reproduces.

Calling get_app_state for Microsoft Outlook fails with:

NSOSStatusErrorDomain Code=-609 "connectionInvalid"

Calling get_app_state by bundle id also fails the same way:

com.microsoft.Outlook -> NSOSStatusErrorDomain Code=-609 "connectionInvalid"

Computer Use is not globally broken in this session. As a control, get_app_state for Finder succeeds with CUA App Version 780.

The Outlook attempt still causes SkyComputerUseService to crash. The current crash signature remains:

• EXC_BAD_ACCESS
• SIGBUS
• Thread stack size exceeded due to excessive recursion
• Bus error: 10

So the newer Codex app build did not resolve the Outlook-specific Computer Use state-inspection failure.

[IgorGanapolsky]

The "crashes on Outlook specifically" pattern is usually not Outlook itself —
it's the AppleScript / Apple Events permission for the parent process that's
launching SkyComputerUseService. macOS tracks Automation permission by the
sending bundle, and if Codex was launched from a host (Warp, cmux, iTerm,
Zed terminal) that lacks Automation permission for Outlook, you get a crash
with no clear stderr instead of a permission prompt.

Worth confirming the parent chain:

ps -o ppid=,command= -p $$

Then: System Settings > Privacy & Security > Automation

Verify the parent terminal has Outlook checked.

Full walkthrough of this and 5 other Computer-Use-on-macOS root causes, plus a
free script that captures the parent chain + TCC posture into a redacted bundle:
https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/troubleshooting.html

If the bundle doesn't clearly show which Symptom matches, the $19 quick read
names the root cause from the captured output.

[NewCoffee7477]

@IgorGanapolsky Thank you for the feedback, that is not the issue here. Codex itself has been tracking and commenting on bug since it was found (was working, stopped working on version upgrade, see above...) I'll let Codex reply to you after testing your theory on latest version ;) -

Thanks for the suggestion. I checked the local evidence against the parent-process / Automation-permission theory, and it does not appear to fit this case.

Current local process-chain evidence:

• Codex is running as /Applications/Codex.app, with parent PID 1.
• Microsoft Outlook is running as /Applications/Microsoft Outlook.app.
• The Computer Use client processes are launched by the Codex app-server.
• SkyComputerUseService is running from the Codex Computer Use app path.
• There is no Warp, iTerm, Zed, cmux, or Terminal parent in the launch chain for this Codex/Computer Use session.

I also checked the local TCC Apple Events permissions. The relevant row already exists:

• com.openai.codex is authorized for com.microsoft.Outlook.

Computer Use is also not globally broken in this session:

• get_app_state for Finder succeeds with CUA App Version 793.
• list_apps sees Microsoft Outlook as running.
• get_app_state for Microsoft Outlook still fails before returning an accessibility tree.

The latest retest was on:

• Codex app: 26.513.31313 build 2867
• Computer Use helper / SkyComputerUseService: com.openai.sky.CUAService version 1.0, build 793
• Microsoft Outlook: 16.110 build 16.110.26051131

The Outlook failure now returns remoteConnection, and each Outlook attempt still creates a fresh SkyComputerUseService crash report. The latest crash reports have the same core signature:

• EXC_BAD_ACCESS
• SIGBUS
• Thread stack size exceeded due to excessive recursion
• Bus error: 10
• recursion depth: 153

So in this local case, the evidence does not point to a missing parent-terminal Automation permission. Codex itself already has Apple Events permission for Outlook, and Codex is not being launched from a terminal host. The failure still appears to be an Outlook-specific Computer Use app-state/accessibility traversal crash inside SkyComputerUseService.

One additional context point: Outlook Computer Use did work on previous versions in this same environment. That is why this still looks like a regression in the Computer Use / Outlook inspection path rather than an initial macOS permissions setup issue.