CodexDockTilePlugin infinite recursion crash in setDockTile:

Resolved 💬 4 comments Opened Jun 15, 2026 by jasony009 Closed Aug 6, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Bug Report: CodexDockTilePlugin infinite recursion crash

Summary

CodexDockTilePlugin crashes immediately on load due to infinite recursion in setDockTile:, taking down the macOS Dock's com.apple.dock.external.extra.arm64 XPC process.

Environment

Codex Version: 26.609.41114 (Build 3888)
macOS: 26.5.1 (25F80)
Hardware: MacBookPro18,2 (M1 Max, 64GB RAM)
SIP: Enabled

Crash Details

Process: com.apple.dock.external.extra.arm64
Plugin: CodexDockTilePlugin.plugin (com.openai.codex.dock-tile-plugin)
Crash Type: Stack overflow (recursion level 37,331)
Time to Crash: ~206ms after launch

Stack Trace

0  libobjc.A.dylib             objc_storeStrong + 4
1  CodexDockTilePlugin         -[CodexDockTilePlugin_com_openai_codex setDockTile:] + 40
2  CodexDockTilePlugin         -[CodexDockTilePlugin_com_openai_codex setDockTile:] + 224
-------- RECURSION LEVEL 37331 --------

Root Cause Analysis (from disassembly)

In -[CodexDockTilePlugin_com_openai_codex setDockTile:], at offset 0x0bc4, the method calls itself directly:

0x0bc0: ldur x0, [x29, #-0x8]    ; x0 = self
0x0bc4: bl   objc_msgSend$setDockTile:  ; [self setDockTile:self.dockTile] ← BUG

The pseudo-code logic:

- (void)setDockTile:(NSDockTile *)dockTile {
    self.dockTile = dockTile;
    
    if (self.preferenceObserver) {
        [[NSNotificationCenter defaultCenter] removeObserver:self.preferenceObserver];
        self.preferenceObserver = nil;
    }
    
    // ⚠️ BUG: calls itself, causing infinite recursion
    [self setDockTile:self.dockTile];
    
    // The following never executes:
    // - Register new notification observer
    // - Call updateDockTile
}

Trigger Conditions

macOS wake from sleep
External display connect/disconnect
Any Dock restart

Workaround

Renaming CodexDockTilePlugin.plugin to disable it stops the crash.

Crash Report

Incident Identifier: B2956515-0C0C-4249-95C2-F5BBCC1FDCD3

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#27776
#27694
#28004
#27969
#27888

Powered by Codex Action

guuguo · 2 months ago

I can reproduce this on the current notarized/signed Codex Desktop build as well, and the impact is severe enough to make the Mac nearly unusable.

Environment:

Codex Desktop: 26.616.51431, build 4212
macOS: 26.5.1 (25F80)
Hardware: MacBookPro18,3, Apple Silicon, 32 GB RAM
/Applications/Codex.app is official/notarized: spctl --assess --type execute -vv /Applications/Codex.app returns accepted, origin Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
Info.plist still contains NSDockTilePlugIn=CodexDockTilePlugin.plugin

Fresh crash from ~/Library/Logs/DiagnosticReports/com.apple.dock.external.extra.arm64-2026-06-22-150118.ips:

app_name: com.apple.dock.external.extra.arm64
os_version: macOS 26.5.1 (25F80)
captureTime: 2026-06-22 15:01:15 +0800
consecutiveCrashCount: 17
exception: EXC_BAD_ACCESS / SIGSEGV / KERN_PROTECTION_FAILURE
termination: Segmentation fault: 11
faultingThread: 0

frames:
objc_storeStrong
-[CodexDockTilePlugin_com_openai_codex setDockTile:]
-[CodexDockTilePlugin_com_openai_codex setDockTile:]
-[CodexDockTilePlugin_com_openai_codex setDockTile:]
...

recursionInfoArray:
depth: 37331
keyFrame: -[CodexDockTilePlugin_com_openai_codex setDockTile:]
originalLength: 37357

usedImages includes:
/Applications/Codex.app/Contents/PlugIns/CodexDockTilePlugin.plugin/Contents/MacOS/CodexDockTilePlugin
CFBundleIdentifier: com.openai.codex.dock-tile-plugin

Observed system impact while this is happening:

WindowServer around 70-90% CPU
system load around 13-15
mouse movement becomes extremely slow or disappears intermittently
UI can freeze for minutes, requiring forced reboot
quitting/killing user apps does not reliably recover the system once it is in this state

I also tried the known local workaround of removing/disabling the Dock tile plugin entry. It stops this specific Dock crash, but it modifies the app bundle/signature and can lead to macOS Gatekeeper showing “Codex is damaged and can’t be opened” after restart or reinstall/quarantine changes. So this does not feel like a safe workaround for normal users.

After reinstalling/overwriting with the official Codex.app, the app opens again and passes Gatekeeper, but the NSDockTilePlugIn entry is restored and the Dock external extra crash returns immediately. A temporary official build/setting that disables this Dock tile plugin, or a signed hotfix removing/fixing setDockTile:, would be very helpful.

guuguo · 2 months ago

Additional severe datapoint: the same machine just hit a full WindowServer userspace watchdog timeout while Codex was running and the Dock tile plugin issue was present.

WindowServer report:

File: /Library/Logs/DiagnosticReports/WindowServer_2026-06-22-164514_MacBook-Pro-8.userspace_watchdog_timeout.spin
Time: 2026-06-22 16:44:57 +0800 to 16:45:03 +0800
macOS: 26.5.1 (25F80)
Hardware: MacBookPro18,3, 32 GB RAM
Reason:

(1 monitored services unresponsive): checkin with service: WindowServer returned not alive
unresponsive work processor(s): WindowServer main thread
40 seconds since last successful checkin

WindowServer details from the spin report:

Process: WindowServer [197]
Event: service process watchdog
Footprint: 1365.30 MB
Thread name: ws_main_thread

The main thread stack is stuck deeply inside SkyLight repeating the same frame pattern:

SkyLight + 3420796
SkyLight + 3420796
SkyLight + 3420796
...

User-visible impact at the time:

the whole desktop froze
mouse/cursor became unusable
system was effectively non-interactive until WindowServer was killed/restarted by watchdog

Immediately after recovery, the system was still under extreme load:

load averages: 259.35 246.96 117.78
syspolicyd: ~101% CPU
trustd: ~44% CPU
WindowServer: ~42% CPU
Codex Renderer: ~31% CPU

There is also a nearby Codex diagnostic report:

/Library/Logs/DiagnosticReports/Codex_2026-06-22-144640_MacBook-Pro-8.diag
Codex 26.611.62324 (4028)
Event: disk writes
Writes: 2147.57 MB over 1026 seconds

I am not claiming the WindowServer stack alone proves causality, but this is the observed escalation on the same system: Codex Dock tile plugin recursive crashes + syspolicyd/trustd load + WindowServer high CPU eventually progressed to a full WindowServer watchdog timeout and several minutes of desktop unusability. This is now beyond “high CPU”; it can make the macOS UI non-interactive.

guuguo · 2 months ago

One more fresh signal from immediately after the WindowServer watchdog recovery on the same official build (26.616.51431 / 4212):

$ spctl --assess --type execute -vv /Applications/Codex.app
/Applications/Codex.app: Too many open files

At the same time:

syspolicyd: ~37% CPU
trustd: ~18% CPU
WindowServer: ~27% CPU
load averages: 70.79 188.86 107.79

So this also matches the syspolicyd / Gatekeeper FD exhaustion pattern reported in related issues.