Codex Desktop 26.609.30741 crashes Dock external extra via CodexDockTilePlugin setDockTile recursion on macOS

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

• #27662
• #26341
• #26117

Powered by Codex Action

Additional local diagnostics from a later recurrence on the same machine.

Environment:

• Codex.app (non-Beta) 26.609.30741 / build 3808, bundle id com.openai.codex
• macOS 15.7.4 (24G517)
• Crash reports identify the machine model as Mac16,6

Observed on 2026-06-12, local timezone CEST:

• ~/Library/Logs/DiagnosticReports now contains 55 com.apple.dock.external.extra.arm64-2026-06-12-*.ips reports from 12:18 through 15:08.
• All 55 parsed reports have EXC_BAD_ACCESS / SIGSEGV.
• All 55 include the Codex Dock tile plugin image:
• /Applications/Codex.app/Contents/PlugIns/CodexDockTilePlugin.plugin/Contents/MacOS/CodexDockTilePlugin
• bundle id com.openai.codex.dock-tile-plugin, version 1.0 (1)
• All 55 have the same top crash pattern on the triggered thread:
• objc_storeStrong
• repeated -[CodexDockTilePlugin_com_openai_codex setDockTile:]

Representative latest report:

• timestamp 2026-06-12 15:08:48 +0200
• process com.apple.dock.external.extra.arm64, pid 94191
• exception EXC_BAD_ACCESS / SIGSEGV, subtype KERN_PROTECTION_FAILURE
• termination SIGNAL, code 11, indicator Segmentation fault: 11
• triggered thread starts with objc_storeStrong followed by repeated -[CodexDockTilePlugin_com_openai_codex setDockTile:]

Possible related system impact, not claiming root cause:

• The same machine also produced WindowServer watchdog diagnostics at 13:01, 13:03, 14:26, and 14:45.
• last shows a reboot at 14:41; after that reboot, another WindowServer watchdog occurred at 14:45.
• The WindowServer reports consistently show unresponsive work processor(s): WindowServer main thread with 40 seconds since last successful checkin.
• The WindowServer .ips/.spin files show the main thread in TCC preflight queues, including com.apple.tcc.preflight.kTCCServiceListenEvent and once com.apple.tcc.preflight.kTCCServiceScreenCapture.
• One spin report also noted Launchd throttled processes and syspolicyd reaching dispatch thread soft limit.

Happy to provide the full .ips / WindowServer .spin diagnostics through a non-public channel if useful; they contain local machine details, so I am not attaching them here.

Post-reboot follow-up from the same machine:

• User disabled the non-Beta Codex helper in macOS Settings and rebooted.
• Fresh boot: 2026-06-12 16:46:43 +0200 on macOS 15.7.4 (24G517).
• Another forced logout occurred shortly after login at 2026-06-12 16:48:44 +0200.
• This was again loginwindow reacting to WindowServer exit, not idle logout:
• Window Server exited, closing down the session immediately
• directLogoutReason:WindowServerExited
• New report: /Library/Logs/DiagnosticReports/WindowServer-2026-06-12-164844.ips
• bug_type: 409
• incident id 63AA04B4-9B48-44C8-8B05-6CB8F580EA8A
• termination namespace WATCHDOG, indicator monitoring timed out for service
• details include unresponsive work processor(s): WindowServer main thread and 40 seconds since last successful checkin
• Matching spin: /Library/Logs/DiagnosticReports/WindowServer_2026-06-12-164856_Tintagel.userspace_watchdog_timeout.spin
• WindowServer main thread is on dispatch queue com.apple.tcc.preflight.kTCCServiceScreenCapture
• also has com.apple.tcc.preflight.kTCCServiceListenEvent
• Processes reached dispatch thread soft limit (80): syspolicyd [496]
• includes replayd, tccd, syspolicyd, Codex processes, and bare-modifier-monitor
• TCC logs immediately before the watchdog include preflights for Codex Beta paths:
• com.openai.codex.beta ScreenCapture/ListenEvent preflights around 16:47:45-16:47:46
• com.openai.codex.helper under Codex Beta checked by WindowServer at 16:47:46.531
• bare-modifier-monitor under Codex Beta checked by WindowServer at 16:47:47.228 and 16:47:53.299
• Other screen/event-monitoring apps also appear in the same TCC window, especially Teams and Claude, so this does not conclusively isolate Codex as the only participant. However, disabling the non-Beta helper did not prevent the same WindowServer/TCC ScreenCapture watchdog path, and Codex Beta/Computer Use related processes were present in the stackshot/process tree.

Local versions at the time:

• Stable /Applications/Codex.app: 26.609.30741 (3808), bundle id com.openai.codex, still has NSDockTilePlugIn = CodexDockTilePlugin.plugin.
• Beta /Applications/Codex (Beta).app: 26.527.60818 (3436), bundle id com.openai.codex.beta, no NSDockTilePlugIn in its Info.plist.

Current working hypothesis: the remaining lockouts are on the TCC ScreenCapture/ListenEvent path, likely involving Codex Beta/Computer Use/bare-modifier-monitor and/or interaction with other screen-capture apps. This appears separate from the earlier non-Beta Dock tile plug-in crash.

Confirming this is NOT fixed in 26.609.41114 — and it also reproduces on macOS 27.0 beta.

Adding two data points not yet in this thread:

1. The bug persists in 26.609.41114. My machine auto-updated twice (03:09 → 26.609.30741, then 04:43 → 26.609.41114 on 2026-06-13). Both versions produce the identical crash loop in com.apple.dock.external.extra.arm64, roughly every 5–10 minutes while the plugin is present.

2. Also reproduces on macOS 27.0 beta (26A5353q), Mac mini Mac16,10 (arm64) — so this isn't specific to macOS 26.x.

Crash signature from DiagnosticReports (26.609.41114, 2026-06-13):

exception: EXC_BAD_ACCESS (SIGSEGV), KERN_PROTECTION_FAILURE
message:   Could not determine thread index for stack guard region
process:   com.apple.dock.external.extra.arm64

  0 libobjc.A.dylib       objc_storeStrong + 4
  1 CodexDockTilePlugin   -[CodexDockTilePlugin_com_openai_codex setDockTile:] + 40
  2 CodexDockTilePlugin   -[CodexDockTilePlugin_com_openai_codex setDockTile:] + 224
  3 CodexDockTilePlugin   -[CodexDockTilePlugin_com_openai_codex setDockTile:] + 224
     ... (frame at +224 repeats until the stack guard page is hit)
  8 com.apple.dock.external.extra.arm64 + 8192
  9 libdispatch.dylib     _dispatch_call_block_and_release + 32

setDockTile: re-enters itself at offset +224 — looks like the setter calls itself (or triggers the same code path) instead of writing the ivar, recursing until stack overflow.

Workaround (until a fixed build ships): move Codex.app/Contents/PlugIns/CodexDockTilePlugin.plugin out of the bundle and killall Dock. Codex itself works fine without it; only the Dock-tile badge is lost. Note that every Sparkle auto-update restores the plugin, so the workaround has to be re-applied after each update — which is how I can confirm 41114 is still affected.

I can confirm a very similar issue on macOS 26.5.1 with Codex Desktop 26.609.30741.

Environment

• macOS: 26.5.1
• Build: 25F80
• Hardware: Apple Silicon MacBook Pro
• Codex App version: 26.609.30741
• Bundle ID: com.openai.codex
• Code signing: Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
• Notarization ticket: stapled
• Quarantine xattr: not present/readable on /Applications/Codex.app

Observed behavior

While Codex Desktop is open and active, macOS repeatedly drives high CPU in:

• /usr/libexec/syspolicyd
• /usr/libexec/trustd

This causes sustained heat/fan noise. Low Power Mode makes the machine quieter, but does not appear to remove the underlying loop.

Live process evidence

During a read-only sudo diagnostic run:

syspolicyd_pid=56063 cpu=312.1
trustd_pid=434 cpu=97.1
Later, the issue was still present:
syspolicyd ~322% CPU
trustd ~100% CPU
No macOS thermal/performance warning was reported:
No thermal warning level has been recorded
No performance warning level has been recorded
vm.swapusage: total = 0.00M used = 0.00M
Strong filesystem evidence
I ran a short sudo read-only diagnostic using sample, lsof, and fs_usage against only the syspolicyd and high-CPU trustd PIDs.
In an 8-second fs_usage sample, syspolicyd repeatedly touched Codex paths:
73208 /Applications/Codex.app/Contents/MacOS/Codex
56798 /Applications/Codex.app
28399 /Applications/Codex.app/Contents
24350 /Applications/Codex.app/Contents/Info.plist
 4057 /Applications/Codex.app/Contents/_CodeSignature/CodeRequirements-1
lsof also showed many open references from syspolicyd to the Codex main executable:
1122 /Applications/Codex.app/Contents/MacOS/Codex
Stack sample evidence
The syspolicyd sample was dominated by code-signing and trust evaluation frames, including:
SecCodeCopySigningInformation
Security::CodeSigning::SecStaticCode
SecTrust
SecCertificate
CMSDecoder / SecCms
The trustd sample was dominated by certificate/trust-chain work, including:
SecCertificateIsSignedBy
SecTrust
OCSP-related frames
Interpretation
This looks like Codex Desktop repeatedly triggering macOS Gatekeeper/SystemPolicy/code-signing validation for:
/Applications/Codex.app/Contents/MacOS/Codex
The app appears properly signed and notarized, so this does not look like a local malware/quarantine issue. It looks consistent with the existing reports about syspolicyd / trustd runaway behavior around Codex Desktop on recent macOS builds.
What I did not do
Did not kill syspolicyd or trustd
Did not reset Gatekeeper/SystemPolicy caches
Did not run spctl --reset-default
Did not delete or modify Codex files
Did not change macOS security settings
The diagnostics were read-only except for writing local diagnostic output under /tmp.

Not fixed

Still reproduces on a newer build than the one originally reported here — so this is not fixed yet.

Environment

• Codex app: 26.609.41114 (original reports here & #27776 were on 26.609.30741)
• macOS 26.5.1 (25F80), Mac17,3, arm64

Symptoms (identical stack to the original report)

• Crashing process: com.apple.dock.external.extra.arm64 (the XPC helper Dock uses to host third-party Dock tile plugins)
• EXC_BAD_ACCESS (SIGSEGV), KERN_PROTECTION_FAILURE — "Could not determine thread index for stack guard region" → classic stack overflow
• Faulting thread shows CodexDockTilePlugin calling itself recursively (same imageOffset repeated 6–7 frames deep) before blowing the stack, exactly matching -[CodexDockTilePlugin_com_openai_codex setDockTile:]

Frequency

• 34 crash reports collected. One tight loop of ~15 crashes within ~12 minutes right after the app started, then steady-state roughly every 20 min – 2 h.

So the recursion in the Dock tile plugin is still present in 26.609.41114. Happy to attach a full .ips if useful.

Adding another data point: I am seeing the same CodexDockTilePlugin / setDockTile: recursion crash on a different app, OS, and hardware combination.

Codex app:

• Version: 26.609.41114
• Bundle version: 3888
• Installed path: /Applications/Codex.app
• Plugin path: /Applications/Codex.app/Contents/PlugIns/CodexDockTilePlugin.plugin
• Plugin identifier: com.openai.codex.dock-tile-plugin
• Plugin principal class: CodexDockTilePlugin_com_openai_codex

System:

• macOS: 15.7.7 (24G720)
• Hardware: MacBookPro15,1
• CPU/arch: Intel x86_64

Crash report:

• Date/time: 2026-06-14 17:46:29.7419 +0800
• Process: com.apple.dock.external.extra.x86_64
• Exception Type: EXC_BAD_ACCESS (SIGSEGV)
• Exception Codes: KERN_PROTECTION_FAILURE
• Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
• Crashed Thread: 0, dispatch queue com.apple.main-thread
• Fault address was inside the STACK GUARD region, which is consistent with stack exhaustion
• The crashing stack repeatedly shows:

-[CodexDockTilePlugin_com_openai_codex setDockTile:]

Local inspection of the installed plugin also shows an Objective-C property named dockTile with backing ivar _dockTile, alongside the lifecycle method setDockTile:. That lines up with the apparent recursive setter/lifecycle-method collision described here.

I am not attaching the full crash report because it includes unrelated machine inventory, but I can provide a redacted .ips excerpt if useful. The key signature matches this issue while extending it to Intel x86_64, macOS 15.7.7, and Codex app 26.609.41114.

Adding another data point to the existing main tracking issue. I am not opening a new issue because this is a duplicate of this thread.

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

Codex app: 26.609.41114
Bundle/build: 3888
Bundled CLI: codex-cli 0.140.0-alpha.2

What subscription do you have?

Not included here; this appears to be a native macOS Dock Tile plugin crash and not subscription-dependent.

What platform is your computer?

Darwin 25.5.0 arm64 arm
macOS: 26.5.1 (25F80)
Architecture: arm64

What issue are you seeing?

After reboot, com.apple.dock.external.extra.arm64 continued crashing repeatedly over roughly 20 minutes while Codex 26.609.41114 was installed.

Crash reports show:

• Exception: EXC_BAD_ACCESS / SIGSEGV
• Message: Thread stack size exceeded due to excessive recursion
• Repeated frames include -[CodexDockTilePlugin_com_openai_codex setDockTile:]

The installed app is the official signed app:

• Install/update source: official production appcast / Homebrew cask codex-app
• App signature: Developer ID Application: OpenAI OpCo, LLC, Team ID 2DC432GLL2
• codesign --verify --deep --strict /Applications/Codex.app passes

The app declares:

NSDockTilePlugIn = CodexDockTilePlugin.plugin

The installed plugin is:

/Applications/Codex.app/Contents/PlugIns/CodexDockTilePlugin.plugin

Relevant disassembly from the installed official binary:

-[CodexDockTilePlugin_com_openai_codex setDockTile:]:
0000000000000bb8  ldr  x1, [sp, #0x58]
0000000000000bbc  ldur x2, [x29, #-0x18]
0000000000000bc0  ldur x0, [x29, #-0x8]
0000000000000bc4  bl   "_objc_msgSend$setDockTile:"
0000000000000bc8  ldur x8, [x29, #-0x18]

This appears to recursively call setDockTile: from inside setDockTile:, matching the stack-overflow crash.

What steps can reproduce the bug?

1. Install or auto-update to Codex app 26.609.41114 / build 3888 on macOS.
2. Launch Codex.
3. Reboot or allow Dock to reload the app's Dock Tile plugin.
4. Observe repeated DiagnosticReports for com.apple.dock.external.extra.arm64.
5. Crash reports point to CodexDockTilePlugin_com_openai_codex setDockTile: and show excessive recursion / stack exhaustion.

No code snippet, session id, token limit, or context window usage applies. This is a native macOS app/Dock plugin crash.

What is the expected behavior?

Codex should not crash the macOS Dock external plugin host. The Dock Tile plugin should store/update the NSDockTile without recursively re-entering setDockTile:.

Additional information

I checked the official production appcast today. The latest macOS arm64 item is still 26.609.41114 / build 3888, so there is no newer production build available through the appcast yet.

As a workaround, I downloaded the previous official production appcast version 26.608.12217 / build 3722 and verified its signature with codesign --verify --deep --strict. That version does not contain NSDockTilePlugIn in Info.plist and does not include CodexDockTilePlugin.plugin, so rollback to 26.608.12217 avoids this Dock Tile plugin crash path.

I am intentionally not attaching full crash logs here because they may contain local machine details, but the stack signature matches this issue.

Update: still reproducible on Codex Desktop 26.609.71450, now correlated with WindowServer watchdog reboots

I am seeing the same Dock tile plugin recursion crash on the current Codex Desktop build after reinstalling/updating:

• Codex app: com.openai.codex
• Codex Desktop version: 26.609.71450
• Codex Desktop build: 3965
• Codex CLI: codex-cli 0.140.0-alpha.2
• Dock tile plugin bundle: com.openai.codex.dock-tile-plugin
• Dock tile plugin version: 1.0
• macOS: 15.7.3 (24G419)
• Hardware: MacBookPro16,2

This is no longer only a Dock XPC crash. On this machine, multiple full GUI freezes / automatic restarts on 2026-06-16 are strongly correlated with the same Codex Dock tile plugin crash loop.

What happened

The machine froze/restarted multiple times on 2026-06-16. The immediate process killed by macOS was WindowServer via userspace watchdog:

• WindowServer-2026-06-16-115103.ips
• WindowServer-2026-06-16-134241.ips
• WindowServer-2026-06-16-135347.ips

All three reports show:

• termination.namespace: WATCHDOG
• termination.indicator: monitoring timed out for service
• Display 69734272 not ready: DisplayID: 0x4280f80
• Surface transactions stuck in [Waiting]

The corresponding WindowServer watchdog spindumps all explicitly include:

Launchd throttled processes: dock.external.extra.x86_64 throttled after SIGSEGV

Affected spindumps:

• WindowServer_2026-06-16-115121_HarveyMac.userspace_watchdog_timeout.spin
• WindowServer_2026-06-16-134255_HarveyMac.userspace_watchdog_timeout.spin
• WindowServer_2026-06-16-135359_HarveyMac.userspace_watchdog_timeout.spin

Dock XPC crash evidence

There are multiple com.apple.dock.external.extra.x86_64 crash reports on the same day:

• com.apple.dock.external.extra.x86_64-2026-06-16-115317.ips
• com.apple.dock.external.extra.x86_64-2026-06-16-115352.ips
• com.apple.dock.external.extra.x86_64-2026-06-16-134550.ips
• com.apple.dock.external.extra.x86_64-2026-06-16-134550.000.ips
• com.apple.dock.external.extra.x86_64-2026-06-16-135441.ips
• com.apple.dock.external.extra.x86_64-2026-06-16-141641.ips

Every parsed report has the same shape:

• Process: com.apple.dock.external.extra.x86_64
• Exception: EXC_BAD_ACCESS
• Signal: SIGSEGV
• Subtype: KERN_PROTECTION_FAILURE
• Faulting thread: 0
• Repeated top frames:

-[CodexDockTilePlugin_com_openai_codex setDockTile:]
-[CodexDockTilePlugin_com_openai_codex setDockTile:]
-[CodexDockTilePlugin_com_openai_codex setDockTile:]
...

The used image includes:

/Applications/Codex.app/Contents/PlugIns/CodexDockTilePlugin.plugin/Contents/MacOS/CodexDockTilePlugin

One crash observed during live verification at 2026-06-16 14:16:41 +0800 reached:

consecutiveCrashCount: 17

This suggests the issue persists after reinstall/update and is still active on 26.609.71450.

Why I think this is causing the reboots/freezes

The system-level chain in the diagnostics is:

Codex Dock tile plugin setDockTile recursion
-> com.apple.dock.external.extra.x86_64 SIGSEGV crash loop
-> launchd throttles dock.external.extra.x86_64
-> WindowServer reports Display 69734272 not ready and stuck surface transactions
-> userspace watchdog terminates WindowServer
-> GUI freeze / automatic restart

There are also Codex disk-write diagnostics showing repeated ~2.15 GB writes, but those look like a separate/high-load issue. The WindowServer spindumps directly mention the Dock external-extra SIGSEGV, so the Dock tile plugin path is the stronger causal evidence for the freezes/restarts.

Requested fix / mitigation

Could the Codex Desktop team please investigate CodexDockTilePlugin_com_openai_codex setDockTile: for recursive setDockTile: calls or re-entrant Dock tile update behavior?

A user-accessible mitigation would also help, such as:

• a setting to disable the Codex Dock tile plugin/status icon updates, or
• shipping the app without NSDockTilePlugIn until this is fixed, or
• making Dock tile updates resilient to re-entrant setDockTile: calls.

I can provide the .ips, .spin, and Codex disk-write diagnostic files privately if needed. I am avoiding uploading raw diagnostics directly to this public issue because they may contain local paths/process metadata.

Adding another confirmation for the current Codex Desktop build, with an uploaded in-app feedback ID.

Environment

• Codex app: 26.609.71450
• Codex build: 3965
• Bundle ID: com.openai.codex
• Dock tile plugin: com.openai.codex.dock-tile-plugin, version 1.0 (1)
• macOS: 26.5.1 (25F80)
• Architecture: Apple Silicon / arm64
• App path: /Applications/Codex.app
• Feedback ID from Codex app: 019ecf23-44bc-7891-b30e-a6d7bc248cce

Observed behavior

After reinstalling Codex.app, macOS Dock / WindowServer became sluggish. Multiple apps would bounce in the Dock but appear slow or fail to open normally.

DiagnosticReports show repeated crashes for:

com.apple.dock.external.extra.arm64

The crashing stack matches this issue exactly:

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

One local report shows:

Exception: EXC_BAD_ACCESS / SIGSEGV / KERN_PROTECTION_FAILURE
recursionInfoArray depth: 37331
Plugin path: /Applications/Codex.app/Contents/PlugIns/CodexDockTilePlugin.plugin/Contents/MacOS/CodexDockTilePlugin

Local checks / mitigations attempted

• codesign --verify --deep --strict --verbose=2 /Applications/Codex.app passed.
• spctl --assess --type execute --verbose=4 /Applications/Codex.app returned accepted.
• Restarted Dock.
• Restarted lsd.
• Cleared Codex preferences:
• DockIconPreference
• DockIconResourceName
• Verified regular app launching still works by opening and quitting TextEdit.
• Codex was pinned in the Dock, which may make Dock load the Dock Tile plugin more readily.

I am not attaching full .ips files publicly because they contain local machine paths and process metadata, but the full diagnostics were uploaded through the Codex in-app feedback flow under the Feedback ID above.

Workaround (verified): disable the Dock Tile plugin — note it needs macOS "App Management" permission

Same crash here — Codex 26.609.71450 (build 3965), macOS 26.5 (25F71), Mac Studio M4 Max, dual display (one external). DiagnosticReports show com.apple.dock.external.extra.arm64 crashing repeatedly (storms ~every 10 s right after login, then ~every 20 min), all EXC_BAD_ACCESS / SIGSEGV in the recursive -[CodexDockTilePlugin_com_openai_codex setDockTile:] stack. It also tripped WindowServer userspace_watchdog_timeout → full GUI freeze → forced power-off, twice.

Key detail: the crash fires even when Codex.app is not running, as long as Codex is pinned in the Dock — so it's the Dock loading the plugin, not the app.

Heads-up: renaming/removing the plugin fails with Operation not permitted — even with sudo — because Codex.app is notarized and macOS App Management protects its bundle. You first have to grant your terminal App Management (System Settings → Privacy & Security → App Management), then quit & reopen it. After that, no sudo is needed:

mv "/Applications/Codex.app/Contents/PlugIns/CodexDockTilePlugin.plugin" \
   "/Applications/Codex.app/Contents/PlugIns/CodexDockTilePlugin.plugin.disabled"
killall Dock

Revert after an official fix:

mv "/Applications/Codex.app/Contents/PlugIns/CodexDockTilePlugin.plugin.disabled" \
   "/Applications/Codex.app/Contents/PlugIns/CodexDockTilePlugin.plugin"
killall Dock

Verified on my machine: after disabling, com.apple.dock.external.extra stays up with zero new crashes (previously it crash-looped within ~10 s of every Dock restart). Only the Dock tile's right-click menu / badge updates are lost — core Codex (app, agent, CLI) is unaffected. Caveat: this invalidates the bundle's code signature and is restored on the next Codex update, so re-apply if the bug is still present.

No-permission alternatives (don't touch the bundle):

• Unpin Codex from the Dock — stops the idle crash loop while Codex isn't running.
• Turn off "Displays have separate Spaces" (defaults write com.apple.spaces spans-displays -bool true, then log out) — drops the secondary-display Dock that's the one crashing.

Diagnosed and workaround verified with Claude Opus 4.8 (1M context) via Claude Code.

Adding another current-build data point from a Mac16,10 Apple Silicon machine.

Environment

• macOS: 26.5.1 (25F80)
• Hardware model: Mac16,10
• Architecture: arm64
• Codex app versions observed:
• 26.611.61049 / build 3996
• reinstalled from the official production DMG and still reproduces on 26.611.61753 / build 4008
• ChromiumBaseBundleVersion: 7827.115
• NSDockTilePlugIn = CodexDockTilePlugin.plugin

What happened

Codex.app initially launched but the window became unresponsive / exited shortly after launch. The strongest local evidence is the same Dock tile plugin recursion reported in this thread:

• Crash report process: com.apple.dock.external.extra.arm64
• Crash report includes the Codex plugin image:
• /Applications/Codex.app/Contents/PlugIns/CodexDockTilePlugin.plugin/Contents/MacOS/CodexDockTilePlugin
• Faulting stack repeats:
• objc_storeStrong
• -[CodexDockTilePlugin_com_openai_codex setDockTile:]
• Local crash report showed recursion depth around 37331 frames before EXC_BAD_ACCESS / SIGSEGV at the stack guard.

Additional system impact

This also drove syspolicyd into a high-CPU validation loop after Codex/Dock retries:

UNIX error exception: 24
Failed to generate SecStaticCode error: 100024
Unable to initialize qtn_proc: 3
dispatch_mig_server returned 268435459

A short fs_usage sample while syspolicyd was hot showed repeated activity against Codex paths, especially:

/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app
/Applications/Codex.app/Contents/MacOS/Codex/Wrapper

The app signature itself looked clean:

codesign --verify --deep --strict --verbose=2 /Applications/Codex.app
# /Applications/Codex.app: valid on disk
# /Applications/Codex.app: satisfies its Designated Requirement

I also downloaded the official production DMG from https://persistent.oaistatic.com/codex-app-prod/Codex.dmg on 2026-06-17. The mounted app was 26.611.61753 / build 4008, and codesign --verify --deep --strict passed before installation. After replacing /Applications/Codex.app with that official build, launching Codex still produced a new com.apple.dock.external.extra.arm64 diagnostic report and the app did not remain open.

Workaround observations

• Moving/removing CodexDockTilePlugin.plugin stopped new Dock external-extra crashes in local testing, but this invalidates the official bundle/signature and is not a good user workaround.
• Reinstalling the latest official DMG did not resolve it.
• Disabling Codex automatic updates avoids the app bundle being replaced mid-session, but does not fix the plugin recursion.

I am not attaching raw .ips files publicly because they include local process/path metadata, but the crash signature matches the recursive CodexDockTilePlugin_com_openai_codex setDockTile: issue exactly.

I can reproduce the same issue on a newer Codex Desktop build.

Environment:

• macOS: 26.5.1 (25F80)
• Hardware: MacBook Pro, Apple M2 Max
• Codex Desktop: 26.611.61753
• Bundle ID: com.openai.codex
• App path: /Applications/Codex.app

Observed behavior:

• Repeated crash reports for com.apple.dock.external.extra.arm64
• Crash points to:

/Applications/Codex.app/Contents/PlugIns/CodexDockTilePlugin.plugin

• Faulting stack includes:

CodexDockTilePlugin_com_openai_codex setDockTile:

• Crash reason:

Thread stack size exceeded due to excessive recursion

I also removed Codex from persistent Dock apps and restarted Dock. That did not stop the crashes while Codex Desktop was still running, so the plugin appears to be loaded for the running app itself, not only for a pinned Dock item.

codesign --verify --deep --strict --verbose=2 /Applications/Codex.app succeeds, and Gatekeeper accepts the app as Notarized Developer ID.

Additional syspolicyd observation:

A 20-second fs_usage capture while syspolicyd was active showed repeated checks around Codex Desktop:

15839 /Applications/Codex.app/Contents/MacOS/Codex
11336 /Applications/Codex.app
6104  /Applications/Codex.app/Contents
5232  /Applications/Codex.app/Contents/Info.plist
872   /Applications/Codex.app/Contents/_CodeSignature/CodeRequirements-1
1728  /private/var/db/SystemPolicyConfiguration/XProtect.bundle/Contents/Resources/gk.db-wal
1728  /private/var/db/SystemPolicyConfiguration/XProtect.bundle/Contents/Resources/gk.db-journal

So this still reproduces on 26.611.61753, and appears to trigger repeated Dock extra crashes plus repeated Gatekeeper/XProtect checks for /Applications/Codex.app.

Still reproduces on 26.611.61753 (2026-06-17) — the update re-installs the identical broken plugin.

Following up on my earlier comment. Codex auto-updated 26.609.71450 → 26.611.61753, and the update overwrote my disabled plugin with a fresh active one. The plugin binary is the same size as before (73648 bytes, plugin bundle version still 1.0) — i.e., the Dock tile plugin itself appears unchanged.

Confirmed it's the same crash: force-loading the new plugin with killall Dock produced 13 com.apple.dock.external.extra.arm64 crashes in ~100 s (~every 10 s). Signature is identical:

EXC_BAD_ACCESS (SIGSEGV), "Could not determine thread index for stack guard region"
libobjc.A.dylib  objc_storeStrong
CodexDockTilePlugin  -[CodexDockTilePlugin_com_openai_codex setDockTile:]
CodexDockTilePlugin  -[CodexDockTilePlugin_com_openai_codex setDockTile:]   (recursive)
...

Re-disabling the plugin stops it again immediately (0 crashes, external Dock XPC stays up).

Environment: macOS 26.5.1 (25F80), Mac Studio M4 Max (Mac16,9), dual display (one external).

Practical note for anyone applying the workaround: it has to be re-applied after every Codex update, because each update reinstalls the active plugin.

Confirmed with Claude Opus 4.8 (1M context) via Claude Code.

I can confirm a safe local workaround for this class of crashes without modifying the signed app bundle.

Environment:

• Codex Desktop: 26.616.31447
• macOS: 26.5.1 (25F80)
• Dock helper process: com.apple.dock.external.extra.arm64

Before the workaround, the crash reports still reproduced on 2026-06-19. The latest local report had:

• consecutiveCrashCount: 51
• EXC_BAD_ACCESS / SIGSEGV
• repeated frames in -[CodexDockTilePlugin_com_openai_codex setDockTile:]
• recursion depth around 37k
• plugin path under /Applications/Codex.app/Contents/PlugIns/CodexDockTilePlugin.plugin/...

The current app bundle still declares:

NSDockTilePlugIn = CodexDockTilePlugin.plugin

Workaround that stopped the crashes locally:

1. Open macOS System Settings.
2. Go to General -> Login Items & Extensions -> Extensions.
3. Open Codex Extensions.
4. Disable the Dock Tile extension. On Chinese macOS this item is shown as 程序坞版块.
5. Restart the Dock with killall Dock, or reboot.

This does not change files inside /Applications/Codex.app, so it avoids breaking the app signature.

Verification after disabling the extension and rebooting:

• Boot time: 2026-06-19 14:57:39 CST
• 5 checks every 2 minutes from 15:02:16 to 15:10:16 CST: 0 new com.apple.dock.external.extra.arm64*.ips reports since boot
• Follow-up check at 16:01:20 CST: still 0 reports since boot and 0 since the earlier monitoring baseline

For comparison, before disabling the extension, local reports on the same day appeared at about 10:54:47, 11:34:47, and 11:54:48 CST, so the post-workaround clean window is meaningful for this machine.

Core Codex functionality appeared unaffected after disabling the Dock Tile extension; this only seems to remove Dock tile integration such as custom Dock tile state/badges/menus.

It may be worth documenting this as the safest temporary workaround until the recursive setDockTile crash is fixed, or disabling/shielding the Dock Tile extension by default when it fails repeatedly.

@loccen
Good job, this workaround fixed it for me as well.

Environment:

• Codex Desktop: 26.616.32156
• macOS: macOS 27.0
• Dock helper process: com.apple.dock.external.extra.arm64

I disabled the Codex Dock Tile extension via:

System Settings -> General -> Login Items & Extensions -> Extensions -> Codex Extensions -> Dock Tile

After restarting Dock, Codex’s Info.plist still declares:

NSDockTilePlugIn = CodexDockTilePlugin.plugin