Computer Use crashes SkyComputerUseService when inspecting Outlook on macOS

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.

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.

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.

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.

@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.

Result: still broken

Current test window: 2026-05-21 15:35:09 to 15:35:39 EDT.

• Codex app: 26.519.22136, build 3003, bundle com.openai.codex
• Computer Use helper: com.openai.sky.CUAService, version 1.0, build 799
• Outlook: 16.110, build 16.110.26051718, bundle com.microsoft.Outlook

Baseline crash reports:

• Active DiagnosticReports: none found
• Retired baseline before test: three older SkyComputerUseService reports from 2026-05-17 17:52

Computer Use results:

• Finder control: succeeded; returned CUA App Version 799
• list_apps: succeeded; listed Microsoft Outlook — /Applications/Microsoft Outlook.app/ — com.microsoft.Outlook [running]
• Outlook get_app_state by display name: failed with returned text remoteConnection
• Outlook get_app_state by bundle id com.microsoft.Outlook: failed with returned text remoteConnection

Search-field test:

• Not reached. I stopped after both Outlook app-state calls failed, per instructions.

Fresh crash reports created during test:

• ~/Library/Logs/DiagnosticReports/Retired/SkyComputerUseService-2026-05-21-153532.ips
• helper build: 799
• exception type: EXC_BAD_ACCESS
• signal: SIGBUS
• crash message: Thread stack size exceeded due to excessive recursion
• termination indicator: Bus error: 10
• recursion depth: 153
• ~/Library/Logs/DiagnosticReports/Retired/SkyComputerUseService-2026-05-21-153534.ips
• helper build: 799
• exception type: EXC_BAD_ACCESS
• signal: SIGBUS
• crash message: Thread stack size exceeded due to excessive recursion
• termination indicator: Bus error: 10
• recursion depth: 153

Conclusion: still broken. Finder works as the control, but Outlook app-state inspection still crashes SkyComputerUseService build 799 with the same stack exhaustion / excessive recursion signature.

Outlook app update available. Rerun test after update. Outlook build number increased only.

Updated Outlook retest result: still broken.

Current versions:

• Codex app: 26.519.22136, build 3003
• Computer Use helper: 1.0, build 799
• Outlook: 16.110, build 16.110.26051929

Computer Use:

• Finder control: succeeded, CUA App Version 799
• list_apps: succeeded; Outlook listed as frontmost, running
• Outlook get_app_state by display name: returned remoteConnection
• Outlook get_app_state by bundle id com.microsoft.Outlook: returned remoteConnection
• Search-field test: not reached

Fresh crash reports from this updated-Outlook test:

• SkyComputerUseService-2026-05-21-154048.ips
• SkyComputerUseService-2026-05-21-154048.000.ips

Both crashes:

• helper build: 799
• exception: EXC_BAD_ACCESS
• signal: SIGBUS
• message: Thread stack size exceeded due to excessive recursion
• termination: Bus error: 10
• recursion depth: 153

Conclusion: Outlook build 16.110.26051929 did not fix the Computer Use crash.

Update from additional retesting and local AX investigation on May 27, 2026:

Current versions tested:

• Codex app: 26.519.81530, build 3178
• Computer Use helper / SkyComputerUseService: com.openai.sky.CUAService, version 1.0, build 799
• Microsoft Outlook: 16.110, build 16.110.26052514
• macOS: 26.5 (25F71)

The issue still reproduces on the current builds.

Computer Use control and Outlook results:

• get_app_state for Finder succeeds with CUA App Version 799.
• list_apps succeeds and lists Microsoft Outlook as running.
• get_app_state for Outlook by display name, bundle id, and full app path all fail the same way:
• Microsoft Outlook -> remoteConnection
• com.microsoft.Outlook -> remoteConnection
• /Applications/Microsoft Outlook.app -> remoteConnection

Each Outlook app-state attempt creates a fresh SkyComputerUseService crash report. The May 27 reports produced by these tests were:

• SkyComputerUseService-2026-05-27-082851.ips
• SkyComputerUseService-2026-05-27-082851.000.ips
• SkyComputerUseService-2026-05-27-083017.ips
• SkyComputerUseService-2026-05-27-083020.ips
• SkyComputerUseService-2026-05-27-083023.ips

The crash signature remains consistent:

• helper build: 799
• exception: EXC_BAD_ACCESS
• signal: SIGBUS
• message: Thread stack size exceeded due to excessive recursion
• termination: Bus error: 10
• recursion depth: 153

I also did a read-only local Accessibility investigation, avoiding email content and redacting local user paths. macOS Accessibility can inspect Outlook locally; this does not look like a remote app or app-name resolution issue. A direct AX probe can see the Outlook window without crashing.

The Outlook AX shape that stands out is the mailbox/folder outline subtree:

• AXSplitGroup -> AXScrollArea -> AXOutline
• The outline reports 32 children, 31 AXRows, and 31 AXVisibleRows.
• AXChildren, AXRows, and AXVisibleRows point to the same row objects.
• Rows expose relationship attributes such as AXDisclosedRows, AXDisclosedByRow, AXVisibleChildren, AXParent, and AXWindow.
• Cells expose AXTitleUIElement.
• The tree also contains many AXUnknown intermediary nodes.

My current best hypothesis is that Outlook exposes an accessibility graph with duplicate references and back-references rather than a simple tree. The Computer Use helper appears to recursively serialize or traverse those AX relationships and revisit the same objects until stack exhaustion. That would explain why Finder and other apps remain inspectable while Outlook consistently crashes the helper during app-state inspection.

The exposed Computer Use MCP API does not appear to provide a safe-mode option such as max depth, exclude attributes, PID/window targeting, or relationship-pruning, so I cannot work around this through get_app_state itself. A product-side fix likely needs cycle detection / visited-object tracking and/or treating relationship attributes like AXParent, AXWindow, AXTopLevelUIElement, AXDisclosedByRow, AXDisclosedRows, AXVisibleRows, AXVisibleChildren, and AXTitleUIElement as references instead of recursively expanding them.

Follow-up: I was able to build and verify a local workaround outside the Computer Use helper path.

I created a narrow local Swift Accessibility script that talks to Outlook directly through macOS AX APIs instead of calling SkyComputerUseService. The script is intentionally conservative:

• walks only AXChildren
• tracks visited AXUIElement objects with CFEqual
• reports repeated elements as cycle=true
• avoids recursively expanding relationship attributes such as AXParent, AXWindow, AXTopLevelUIElement, AXDisclosedByRow, AXDisclosedRows, AXVisibleRows, AXVisibleChildren, and AXTitleUIElement
• redacts user-visible values by default, so it does not dump mailbox subjects, senders, message text, or local user paths

The workaround confirms an Outlook-specific cycle/repeated-reference issue. With a shallow state dump, the search field shows up as a self-referential chain unless cycle detection is applied:

path=w1.1.1 depth=2 role=AXTextField subrole=AXSearchField id=Search Bar children=4 enabled=true focused=true
path=w1.1.1.1 depth=3 role=AXTextField cycle=true

The same script can locate and safely set the Outlook search field without using Computer Use get_app_state, without pressing Return, and without opening or modifying any messages. Test command used a harmless search string:

set-search test

Result:

set-search ok=true
search path=w1.1.1 role=AXTextField subrole=AXSearchField id=Search Bar placeholder=Search enabled=Optional(true) focused=Optional(true) valueLength=45

After running the direct AX workaround, I checked for fresh SkyComputerUseService crash reports and none were created. That is expected because the workaround bypasses the helper entirely, but it is useful evidence that Outlook itself can be inspected and controlled locally when traversal is cycle-aware.

So the local workaround is viable for narrow Outlook actions, and it further supports the product-side fix direction: SkyComputerUseService needs cycle detection / visited-node tracking and should treat AX relationship attributes as references rather than recursively expanding them as tree children.

Implementation notes for anyone reproducing the workaround:

• The local AX script needs macOS Accessibility permission for the process running it.
• To keep output privacy-safe, the workaround should avoid printing user-visible attributes such as AXValue, AXTitle, AXDescription, AXHelp, and selected text.
• The repeated search-field node is detectable by comparing AXUIElement references with CFEqual, so cycle detection should be object-identity based rather than path/depth based.
• The suspected recursion can be demonstrated from structural AX metadata alone; mailbox contents are not needed for the repro.

Update: Codex / Computer Use build 809 retest on June 4, 2026

Summary

Outlook still reproduces the Computer Use crash on helper build 809, even after updating Outlook from 16.110 to 16.111. The broader comparison set does not point to a general Computer Use failure, a general Microsoft app failure, or a general local-app inspection failure.

The current result is still Outlook-specific: get_app_state for Outlook returns only remoteConnection, and each Outlook app-state attempt creates a fresh SkyComputerUseService crash report with the same excessive-recursion signature.

Versions Tested

| Component | Version / build |
|---|---|
| Codex app | 26.602.30954, build 3575 |
| Computer Use helper / SkyComputerUseService | com.openai.sky.CUAService, version 1.0, build 809 |
| macOS | 26.5.1 (25F80), Darwin 25.5.0 arm64 |
| Microsoft Outlook before update | 16.110, build 16.110.26053117 |
| Microsoft Outlook after update | 16.111, build 16.111.26060126 |

Control / Comparison App Results

| App | Bundle / version | Build 809 Computer Use result |
|---|---|---|
| Finder | com.apple.finder | get_app_state succeeded with normal screenshot and accessibility tree. |
| Vivaldi | com.vivaldi.Vivaldi | get_app_state succeeded with normal screenshot and accessibility tree. |
| Microsoft Teams | com.microsoft.teams2, 26120.3106.4725.800 | get_app_state succeeded. |
| Microsoft Word | com.microsoft.Word, 16.111, build 16.111.26060126 | get_app_state succeeded. |
| Microsoft Excel | com.microsoft.Excel, 16.111, build 16.111.26060126 | get_app_state succeeded. |
| Microsoft PowerPoint | com.microsoft.Powerpoint, 16.111, build 16.111.26060126 | get_app_state succeeded. |
| Microsoft AutoUpdate | com.microsoft.autoupdate2, 4.83, build 4.83.26040910 | get_app_state succeeded. |
| Microsoft Outlook | com.microsoft.Outlook, 16.110 before update and 16.111 after update | get_app_state failed before and after the Outlook update; returned only remoteConnection and crashed SkyComputerUseService. |

Additional comparison notes:

• list_apps is intermittent, not consistently broken. It timed out once after 120 seconds, then later succeeded quickly and listed Microsoft Outlook as running at /Applications/Microsoft Outlook.app/ with bundle id com.microsoft.Outlook.
• Earlier issue-history controls also included Apple Calendar as a successful non-Outlook app-state comparison. I did not rerun Apple Calendar in this post-Outlook-update build-809 round.
• I am intentionally not including recent-document names, message content, account names, or other user-visible content from any comparison app.

Outlook Repro Matrix On Helper Build 809

Before the Outlook update, Outlook get_app_state returned only remoteConnection by multiple selectors:

| Selector used | Result |
|---|---|
| com.microsoft.Outlook | remoteConnection plus fresh helper crash report |
| Microsoft Outlook | remoteConnection plus fresh helper crash report |
| /Applications/Microsoft Outlook.app | remoteConnection plus fresh helper crash report |
| com.microsoft.Outlook after making Outlook frontmost | remoteConnection plus fresh helper crash report |

After updating Outlook to 16.111 / build 16.111.26060126, the same failure still reproduces:

| Selector used | Result |
|---|---|
| com.microsoft.Outlook | remoteConnection plus fresh helper crash report |

The post-update attempt generated this fresh report:

• SkyComputerUseService-2026-06-04-204913.ips

Fresh Crash Metadata From The Post-Update Retest

| Field | Value |
|---|---|
| Process | SkyComputerUseService |
| Bundle | com.openai.sky.CUAService |
| Helper build | 809 |
| Process path shape | .../Codex Computer Use.app/Contents/MacOS/SkyComputerUseService |
| Exception | EXC_BAD_ACCESS |
| Signal | SIGBUS |
| Message | Thread stack size exceeded due to excessive recursion |
| Termination | Bus error: 10 |
| Faulting thread | 2 |

Permission / Prompt Observation

Outlook-related permissions were removed before part of this retest with the expectation that Codex / Codex Computer Use would prompt again when trying to inspect Outlook.

Observed behavior:

• No permission prompt appeared.
• The active Computer Use process was confirmed to be the expected app: Codex Computer Use.app, bundle com.openai.sky.CUAService, build 809.
• Instead of surfacing a permission prompt or controlled permission error, the Outlook path returned remoteConnection and produced the same excessive-recursion crash signature.

Clarification On remoteConnection

remoteConnection is misleading in this repro. Outlook is a local application at /Applications/Microsoft Outlook.app; list_apps can see it locally, and Computer Use can inspect other local apps on the same machine.

What I checked:

• I did not find public hits for exact searches like SkyComputerUseService remoteConnection, Codex Computer Use remoteConnection, or missingRemoteProxy remoteConnection.
• Apple documents connectionInvalid = -609 as a CoreServices/OSStatus error meaning the connection is invalid, not that the target app is remote: https://developer.apple.com/documentation/coreservices/1560050-anonymous/connectioninvalid
• Apple XPC docs use terms like remoteObjectProxy for the object/process on the other side of a local IPC/XPC boundary. In that context, "remote" can mean another local helper process, not a network or cloud app: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html
• The local SkyComputerUseService binary contains missingRemoteProxy adjacent to remoteConnection, which supports the interpretation that remoteConnection is an internal helper IPC/proxy failure label being surfaced to the tool caller.
• Apple Accessibility docs describe the relevant model as a local accessibility client querying another app's local accessibility hierarchy: https://developer.apple.com/library/archive/documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXmodel.html

Conclusion

Build 809 still has the Outlook-specific app-state failure. Updating Outlook from 16.110 to 16.111 did not change the outcome.

Finder, Vivaldi, and the tested Microsoft apps Teams, Word, Excel, PowerPoint, and AutoUpdate remain inspectable. list_apps can also identify Outlook as a local running app. Outlook main-window inspection still fails and crashes SkyComputerUseService with the same excessive-recursion signature.

The remoteConnection result appears to be a misleading surfaced helper/IPC/proxy failure after the Computer Use helper crashes, not evidence that Outlook is remote. Product-side handling should probably surface a controlled helper crash / app-state traversal error instead of remoteConnection, and the underlying traversal still appears to need cycle detection / visited-object tracking for Outlook's AX graph.

Follow-up: AX recursion narrowed; Legacy Outlook comparison

After the build-809 retest, I ran redacted structural AX traces against Outlook to narrow the recursion source. The trace output was limited to AX roles, subroles, identifiers, structural paths, edge names, cycle classifications, and counts. It did not print email body, sender, subject, attachment names, account names, raw search values, or recent-document content. The direct Computer Use tree can expose message-list content, so I am intentionally not pasting that tree here.

Current relevant versions from this retest:

| Component | Version / build |
|---|---|
| Codex app | 26.602.30954, build 3575 |
| Computer Use helper | com.openai.sky.CUAService, version 1.0, build 809 |
| Microsoft Outlook | 16.111, build 16.111.26060126 |
| macOS / Darwin | 26.5.1 (25F80) / 25.5.0 arm64 |

New Outlook failure still reproduces

In New Outlook, a direct Computer Use call still failed:

| Action | Result |
|---|---|
| list_apps | Succeeded and listed Outlook as local app /Applications/Microsoft Outlook.app/, bundle com.microsoft.Outlook. |
| get_app_state({ app: "com.microsoft.Outlook" }) | Returned only remoteConnection and generated a fresh SkyComputerUseService crash report. |

Fresh crash report from that narrowed New Outlook test:

| Field | Value |
|---|---|
| Report | SkyComputerUseService-2026-06-04-210809.ips |
| Exception | EXC_BAD_ACCESS |
| Signal | SIGBUS |
| Message | Thread stack size exceeded due to excessive recursion |
| Termination | Bus error: 10 |
| Faulting thread | 9 |
| Recursion info | key recursive frame depth 153 |

New Outlook AX graph finding

The New Outlook window root was:

w1 role=AXWindow subrole=AXStandardWindow id=OutlookWindow

Its top-level children included:

w1.AXChildren[0] role=AXGroup      id=_NS:149
w1.AXChildren[1] role=AXSplitGroup id=-
w1.AXChildren[2] role=AXButton     subrole=AXCloseButton
w1.AXChildren[3] role=AXButton     subrole=AXFullScreenButton
w1.AXChildren[4] role=AXButton     subrole=AXMinimizeButton

The first concrete self-cycle appeared in the top search/header branch:

| Path | Role / subrole / id | Finding |
|---|---|---|
| w1.AXChildren[0].AXChildren[0] | AXTextField / AXSearchField / Search Bar | AXChildren[0] points back to the same element. |

The cycle appeared even in a pure AXChildren traversal:

CYCLE kind=self via=AXChildren[0]
source path=w1.AXChildren[0].AXChildren[0] role=AXTextField subrole=AXSearchField id=Search Bar
target path=w1.AXChildren[0].AXChildren[0] role=AXTextField subrole=AXSearchField id=Search Bar

Branch-level New Outlook trace results:

| Branch | Traversal | Result |
|---|---|---|
| w1.AXChildren[0] | AXChildren only | Tiny branch, reproduces the self-cycle at the search field. |
| w1.AXChildren[1] | AXChildren only | Completed successfully: visits=8879, unique=8879, cycles=0, maxDepth=10, truncated=false. |

This suggests the earliest / simplest recursion trigger in New Outlook is the search field in the top search/header branch. If Computer Use serializes AXChildren recursively without visited-object tracking, that one element is enough to stack-overflow.

There are also repeated/cyclic relationship edges elsewhere in Outlook if the serializer expands non-hierarchy AX relationships. The main content branch showed repeats/cycles through relationships such as:

AXRows
AXVisibleRows
AXVisibleChildren
AXTitleUIElement
AXDisclosedRows
AXDisclosedByRow
AXParent
AXWindow
AXTopLevelUIElement

Legacy Outlook comparison

After switching Outlook to Legacy Outlook, the same direct Computer Use call succeeded:

| Action | Result |
|---|---|
| get_app_state({ app: "com.microsoft.Outlook" }) | Succeeded with a full screenshot and accessibility tree. |
| Crash report check after the successful call | No newer SkyComputerUseService crash report appeared; latest crash remained the New Outlook report above. |

Read-only menu inspection also changed as expected: Help > Revert to Legacy Outlook disappeared after the switch, while the Outlook menu still showed the Legacy Outlook toggle.

A redacted main-window trace in Legacy Outlook found a different main-window structure:

legacy-main-trace redacted=true windows=2
root path=main role=AXWindow subrole=AXStandardWindow id=Outlook Window width=1709 height=1395
topChildren count=7

Top-level Legacy Outlook main-window children:

main.AXChildren[0] role=AXSplitGroup
main.AXChildren[1] role=AXTabGroup
main.AXChildren[2] role=AXGroup
main.AXChildren[3] role=AXToolbar
main.AXChildren[4] role=AXButton subrole=AXCloseButton
main.AXChildren[5] role=AXButton subrole=AXFullScreenButton
main.AXChildren[6] role=AXButton subrole=AXMinimizeButton

Legacy Outlook still has a search field, but it did not have the self-child problem:

| Path | Role / subrole / placeholder | Child count | Self-child? |
|---|---|---:|---:|
| main.AXChildren[3].AXChildren[0].AXChildren[5] | AXTextField / AXSearchField / Search | 2 | false |

Legacy Outlook main-window pure AXChildren traversal also completed cleanly:

childrenOnly visits=1624 unique=1624 cycles=0 maxDepth=9 truncated=false

Current interpretation

This is now strong evidence that the crash is tied to the New Outlook accessibility graph, especially the new top search/header branch, rather than to a global Computer Use outage, app discovery issue, or generic macOS permission failure.

The product-side fix still appears to be cycle detection / visited-object tracking and probably relationship pruning. Legacy Outlook working does not eliminate the need for that fix, because New Outlook exposes at least one direct AXChildren self-cycle and additional repeated/cyclic relationship edges. But Legacy Outlook gives a useful control case: same app bundle, same Computer Use helper build, same machine, but different Outlook UI mode and get_app_state succeeds.

Update after retesting with Computer Use build 810 on June 18, 2026.

I reviewed the current issue thread before drafting this. I did not see a newer maintainer request after the prior New Outlook AX graph / Legacy Outlook comparison, so this update focuses on the new Computer Use build, the current Outlook version, and a broader control-app matrix.

Current versions observed in this retest:

• Codex app: 26.611.62324 build 4028
• Computer Use plugin/helper: 1.0.810; live app-state responses report CUA App Version: 810
• SkyComputerUseService: com.openai.sky.CUAService version 1.0, build 810
• Microsoft Outlook: 16.111 build 16.111.26061710
• macOS: 27.0 build 26A5353q; Darwin 27.0.0 arm64

The Outlook version has changed since earlier comments in this issue. Earlier retests used Outlook 16.110; this run is Outlook 16.111.

Retest matrix:

| Action | Result |
| --- | --- |
| get_app_state({ app: "Finder" }) | Succeeded with a normal accessibility tree on CUA 810, including after the Outlook failure. |
| get_app_state({ app: "Vivaldi" }) | Succeeded with a normal accessibility tree on CUA 810. |
| get_app_state({ app: "Microsoft Teams" }) | Succeeded as a non-Outlook Microsoft control app. |
| get_app_state({ app: "com.microsoft.Word" }) | First cold-launch attempt timed out and produced a separate helper EXC_BREAKPOINT / SIGTRAP crash at 08:12:59 EDT; retry after Word was already running succeeded with a normal accessibility tree. |
| get_app_state({ app: "com.microsoft.Excel" }) | Succeeded with a normal accessibility tree on CUA 810. |
| get_app_state({ app: "com.microsoft.Powerpoint" }) | Succeeded with a normal accessibility tree on CUA 810. |
| Attempted Microsoft Update Assistant launch | macOS showed that Microsoft Update Assistant could not be opened, with error -609. I did not count that as a Computer Use app-state control result because it was an OS-level updater/helper launch failure, not a successful app window inspection. |
| get_app_state({ app: "com.microsoft.Outlook" }) | Returned only remoteConnection. |
| Repeat get_app_state({ app: "com.microsoft.Outlook" }) at 08:16 EDT | Again returned only remoteConnection; no additional fresh helper crash appeared from that repeat call. |
| list_apps | Timed out after 120 seconds; no additional fresh helper crash appeared during that timeout. |

Fresh Outlook crash signature from the earlier CUA 810 Outlook attempt in this same retest session:

| Field | Value |
| --- | --- |
| Helper build | 810 |
| Exception | EXC_BAD_ACCESS |
| Signal | SIGBUS |
| Message | Thread stack size exceeded due to excessive recursion |
| Termination | Bus error: 10 |
| Faulting thread | 10 |
| Timing | Fresh helper crash appeared immediately after the Outlook get_app_state attempt at 08:07:24 EDT. |

Conclusion: Computer Use build 810 does not resolve the Outlook-specific get_app_state failure. Outlook still returns only remoteConnection, and the same stack-recursion crash signature reproduced during this retest. The broader controls show this is not a global Computer Use outage: Finder, Vivaldi, Teams, Word after launch, Excel, and PowerPoint were inspectable on the same Computer Use build. Outlook also changed from 16.110 to 16.111, but the failure still reproduces on the current Outlook build.

Update after retesting with Computer Use / SkyComputerUseService build 857 on July 6, 2026.

Current versions observed:

• Codex app: 26.623.101652, build 4674
• Computer Use plugin/helper: 1.0.857; live app-state responses report CUA App Version: 857
• SkyComputerUseService: com.openai.sky.CUAService version 1.0, build 857
• Microsoft Outlook: 16.112, build 16.112.26062931
• macOS: 27.0, build 26A5368g; Darwin 27.0.0 arm64

Retest matrix:

| Action | Result |
| --- | --- |
| get_app_state({ app: "Vivaldi" }) | Succeeded with a normal accessibility tree on CUA 857. |
| get_app_state({ app: "Finder" }) | Succeeded with a normal accessibility tree on CUA 857. |
| get_app_state({ app: "Microsoft Teams" }) | Succeeded as a non-Outlook Microsoft control app. |
| get_app_state({ app: "com.microsoft.Word" }) | Succeeded with a normal accessibility tree on CUA 857. |
| get_app_state({ app: "com.microsoft.Excel" }) | Succeeded with a normal accessibility tree on CUA 857. |
| get_app_state({ app: "com.microsoft.Powerpoint" }) | Succeeded with a normal accessibility tree on CUA 857. |
| get_app_state({ app: "com.microsoft.Outlook" }) | Returned only remoteConnection instead of a usable accessibility tree. |
| Repeat get_app_state({ app: "com.microsoft.Outlook" }) | Again returned only remoteConnection. |
| get_app_state({ app: "Finder" }) after the Outlook attempts | Still succeeded. |
| list_apps | Timed out after 300 seconds. |

Fresh crash reports appeared immediately after the Outlook attempts:

• SkyComputerUseService-2026-07-06-150107.ips
• SkyComputerUseService-2026-07-06-150226.ips

Crash metadata from both fresh reports:

| Field | Value |
| --- | --- |
| Process | SkyComputerUseService |
| Bundle | com.openai.sky.CUAService |
| App version / build | 1.0 / 857 |
| OS | macOS 27.0 (26A5368g) |
| Exception | EXC_BAD_ACCESS |
| Signal | SIGBUS |
| Message | Thread stack size exceeded |
| Termination | Bus error: 10 |
| Faulting stack shape | ___chkstk_darwin followed by repeated SkyComputerUseService frames; each fresh report showed 182 frames on the faulting thread. |

Conclusion: Computer Use / SkyComputerUseService build 857 does not resolve this issue. Outlook still fails with only remoteConnection and still triggers fresh SkyComputerUseService stack-exhaustion crashes, while non-Outlook controls continue to work in the same session.

Update after retesting with the current Codex, Computer Use, Outlook, and macOS builds on July 9, 2026.

Environment

• Codex app: 26.707.30751 (build 5018)
• Codex model used for this retest: GPT-5.6
• Computer Use plugin: 1.0.1000362
• SkyComputerUseService / SkyComputerUseClient: 26.708.1000362 (build 1000362)
• Service bundle: com.openai.sky.CUAService
• Microsoft Outlook: 16.112 (build 16.112.26070718)
• Outlook mode: New Outlook (IsRunningNewOutlook = true)
• macOS: 27.0 (26A5378j); Darwin 27.0.0 arm64

Permission and helper-identity checks

Repeated macOS privacy/security prompts appeared while the helper was crashing and relaunching. However, current TCC logs show Screen Capture access as Allowed (System Set) for both Codex and com.openai.sky.CUAService. Later Listen Event checks were also allowed. A transient Listen Event authorization issue appeared earlier in the prompt sequence, but the available evidence does not establish it as the cause of the Outlook crash.

Two local copies of the Computer Use helper are present: the installed runtime copy and the plugin-cache copy. They have the same:

• bundle identifier
• version/build
• Developer ID authority and Team ID
• designated code requirement
• CDHash
• executable SHA-256
• Info.plist
• entitlements

The active service uses the plugin-cache copy. The two paths therefore do not represent different code-signing identities, and duplicate identity is not currently supported as the cause of the repeated prompts or crash.

Retest matrix

| Action | Result |
|---|---|
| get_app_state({ app: "Vivaldi" }) | Succeeded with a normal accessibility tree. |
| get_app_state({ app: "Finder" }) | Succeeded before the Outlook attempts. |
| get_app_state({ app: "Microsoft Teams" }) | Succeeded. |
| get_app_state({ app: "Calendar" }) | Succeeded. |
| get_app_state({ app: "com.microsoft.Word" }) | Succeeded. |
| get_app_state({ app: "com.microsoft.Excel" }) | Succeeded. |
| get_app_state({ app: "com.microsoft.Powerpoint" }) | Succeeded. |
| get_app_state({ app: "Microsoft Outlook" }) | Repeatedly failed with Sky Computer Use native pipe closed before response. |
| get_app_state({ app: "com.microsoft.Outlook" }) | Repeatedly failed with the same native-pipe error. |
| Immediate Finder check after one Outlook failure sequence | Returned Sky Computer Use service startup request failed while the helper was restarting. |
| list_apps after that failure sequence | Recovered and returned 23 apps in 918 ms. The previous build-857 300-second timeout did not reproduce. |

One isolated Outlook call briefly returned a windowed accessibility tree and Finder also succeeded immediately afterward. A new same-signature SkyComputerUseService crash report appeared shortly afterward. Subsequent Outlook calls returned the native-pipe error consistently.

Date-search test

The intended New Outlook search was an exact received-date query for July 1, 2026.

The search could not be executed because every final Outlook inspection crashed SkyComputerUseService before a verified search field was available. No unverified keyboard input was sent to Outlook.

Fresh crash evidence

This retest generated 11 fresh SkyComputerUseService diagnostic reports between 14:38:52 and 14:56:13. Every report identifies version 26.708.1000362, build 1000362, on macOS 27.0 (26A5378j), with the same signature:

• EXC_BAD_ACCESS
• SIGBUS
• Thread stack size exceeded
• Bus error: 10
• faulting stack begins with ___chkstk_darwin
• 146 frames on the faulting thread

First and last report filenames:

• SkyComputerUseService-2026-07-09-143852.ips
• SkyComputerUseService-2026-07-09-145613.ips

Conclusion

Build 1000362 still reproduces the Outlook-specific stack-exhaustion crash. The visible failure has changed from build 857: instead of returning only remoteConnection, most current Outlook calls end with Sky Computer Use native pipe closed before response.

The repeated permission prompts are relevant and reproducible, but current TCC evidence shows Screen Capture allowed during the failure window, and the helper copies share the same signed identity. Permission friction may be a secondary issue, but it does not currently explain the Outlook-specific recursion/stack-exhaustion crash. Non-Outlook controls continue to work on the same build.

Retested with the newer Codex / Computer Use build:

• Codex app: 26.707.41301 (build 5103)
• Computer Use plugin: 1.0.1000366
• SkyComputerUseService: 26.708.1000366 (build 1000366)
• Microsoft Outlook: 16.112 (build 16.112.26070718)
• macOS: 27.0 (26A5378j)

The issue still reproduces. Vivaldi, Finder, Teams, Calendar, Word, Excel, and PowerPoint returned normal accessibility trees. Outlook failed by both display name and bundle identifier with:

Sky Computer Use native pipe closed before response

A repeated Outlook call failed the same way. Finder recovered afterward, and list_apps returned 17 apps in 29 ms.

Two fresh crash reports were generated:

• SkyComputerUseService-2026-07-12-003806.000.ips
• SkyComputerUseService-2026-07-12-003806.ips

Both reports are build 1000366 and show the same signature as before: EXC_BAD_ACCESS, SIGBUS, Thread stack size exceeded, Bus error: 10, and 146 frames on the faulting thread beginning with ___chkstk_darwin.

Conclusion: Computer Use / SkyComputerUseService build 1000366 does not resolve the Outlook-specific stack-exhaustion crash.

The user who performed this retest also provided the following product feedback about the new Computer Use confirmation:

"absolute trash garbage and a stain on the experience for their highest paying pro users who don't need idiotic nanny software"

Retested with the updated Codex / Computer Use build:

• Codex app: 26.707.51957 (build 5175)
• Computer Use plugin: 1.0.1000387
• SkyComputerUseService: 26.710.1000387 (build 1000387)
• Microsoft Outlook: 16.112 (build 16.112.26070718)
• macOS: 27.0 (26A5378j)

The issue still reproduces. Vivaldi, Finder, Teams, Calendar, Word, Excel, and PowerPoint returned normal accessibility trees. Outlook failed by both display name and bundle identifier with:

Sky Computer Use native pipe closed before response

A repeated Outlook bundle-identifier call failed the same way. Finder recovered afterward, and list_apps returned 19 apps.

Two fresh crash reports were generated from a zero-report pretest baseline:

• SkyComputerUseService-2026-07-12-014700.0002.ips
• SkyComputerUseService-2026-07-12-0147002.ips

Both reports are build 1000387 and show EXC_BAD_ACCESS, SIGBUS, Thread stack size exceeded, and Bus error: 10. Their faulting threads contain 182 and 197 frames, respectively, both beginning with ___chkstk_darwin.

Conclusion: Computer Use / SkyComputerUseService build 1000387 does not resolve the Outlook-specific stack-exhaustion crash.

User deleted Computer Use skill language requiring approval for all actions above blowing one's nose, suggests devs never attempt to re-add stupid language.