Computer Use crashes SkyComputerUseService when inspecting Outlook on macOS

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?

Open Microsoft Outlook for macOS.
In Codex GUI, use Computer Use to call get_app_state for Microsoft Outlook.
Observe that the tool fails with NSOSStatusErrorDomain Code=-609 "connectionInvalid".
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.

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

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

Retested on July 21, 2026 with the current ChatGPT desktop app / Computer Use helper.

Environment

ChatGPT desktop app: 26.715.61943 (build 5628)
Computer Use plugin/helper: 1.0.1000451 / 26.715.1000451 (build 1000451)
Microsoft Outlook: 16.111 (build 16.111.26071325)
macOS: 26.5.2 (25F84), Apple Silicon

Retest result

Before targeting Outlook, read-only get_app_state checks succeeded for:

Finder
Spotify
Microsoft PowerPoint
System Settings

A read-only get_app_state({ app: "Microsoft Outlook" }) then hung for more than 40 seconds and had to be terminated. An immediate Finder state check also hung, showing that the Outlook attempt wedged the shared Computer Use helper for subsequent applications.

Restarting only SkyComputerUseService restored normal operation:

Finder succeeded in 905 ms
Spotify succeeded in 1,964 ms

Outlook and the ChatGPT desktop app did not need to be restarted.

Crash evidence

The preserved native crash signature remains the same:

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

A live service sample also shows repeated accessibility traversal involving:

Sequence.compactMap
AXUIElementCopyMultipleAttributeValues

The local history contains crashes from both helper builds 1000387 and 1000451. macOS Accessibility permission is allowed, and non-Outlook apps work normally until Outlook inspection wedges the service.

Conclusion: helper build 1000451 still does not resolve the Outlook-specific accessibility traversal / stack-exhaustion failure. The current visible symptom is a persistent helper hang that affects later app calls until SkyComputerUseService is restarted.

Retested on July 24, 2026 with the current Codex desktop app / Computer Use helper.

Environment

Codex desktop app: 26.721.30844 (build 5813)
Computer Use plugin/helper: 1.0.1000502 / 26.721.1000502 (build 1000502)
Microsoft Outlook: 16.112 (build 16.112.26071919)
macOS: 27.0 (26A5388g), Apple Silicon

Retest result

A read-only get_app_state({ app: "Finder" }) control check succeeded before targeting Outlook.

A read-only get_app_state({ app: "Microsoft Outlook" }) then ran for about 40 seconds and failed with:

Sky Computer Use native pipe closed before response

list_apps() continued to work and returned Outlook as com.microsoft.Outlook. Repeating the state request by bundle identifier ran for about 38 seconds and failed with the same message.

Unlike the previous build, the helper recovered after each Outlook failure without a manual service restart. Finder returned a normal accessibility tree immediately after both failures. A 90-second diagnostic watch found no new .ips or .crash report, and the Computer Use service remained running.

Conclusion

Computer Use helper build 1000502 still does not resolve the Outlook-specific state-inspection failure previously reproduced on builds 1000387 and 1000451. Recovery behavior is improved because subsequent app-state calls continue to work without manually restarting the helper, but Outlook itself remains inaccessible through Computer Use.

Temporary workaround: switching from the new Outlook for Mac to Outlook Classic works perfectly in my testing. Computer Use can interact with Outlook Classic without the SkyComputerUseService recursion/crash/post-Outlook helper hang seen in the new Outlook.

This appears to be a usable workaround while this issue is investigated, not a fix for the new Outlook regression.

Computer Use crashes SkyComputerUseService when inspecting Outlook on macOS #20683

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

NewCoffee7477 commented on May 6, 2026

NewCoffee7477 commented on May 8, 2026

NewCoffee7477 commented on May 12, 2026

IgorGanapolsky commented on May 14, 2026

Then: System Settings > Privacy & Security > Automation

Verify the parent terminal has Outlook checked.

NewCoffee7477 commented on May 17, 2026

NewCoffee7477 commented on May 21, 2026

NewCoffee7477 commented on May 21, 2026

NewCoffee7477 commented on May 27, 2026

NewCoffee7477 commented on May 27, 2026

NewCoffee7477 commented on Jun 5, 2026

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

Summary

Versions Tested

Control / Comparison App Results

Outlook Repro Matrix On Helper Build 809

Fresh Crash Metadata From The Post-Update Retest

Permission / Prompt Observation

Clarification On remoteConnection

Conclusion

NewCoffee7477 commented on Jun 5, 2026

Follow-up: AX recursion narrowed; Legacy Outlook comparison

New Outlook failure still reproduces

New Outlook AX graph finding

Legacy Outlook comparison

Current interpretation

NewCoffee7477 commented on Jun 18, 2026

NewCoffee7477 commented on Jul 6, 2026

NewCoffee7477 commented on Jul 9, 2026

Environment

Permission and helper-identity checks

Retest matrix

Date-search test

Fresh crash evidence

Conclusion

NewCoffee7477 commented on Jul 12, 2026

NewCoffee7477 commented on Jul 12, 2026

rjamali88 commented on Jul 21, 2026

Environment

Retest result

Crash evidence

NewCoffee7477 commented on Jul 24, 2026

Environment

Retest result

Conclusion

rjamali88 commented on Aug 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Clarification On `remoteConnection`