[Bug]: macOS missing Automation entitlement prevents Codex Computer Use cleanup#21282

Independent reproduction and verification on a stock, unmodified, OpenAI-signed Computer Use installation, plus window-server evidence showing why the cursor even survives stopping screen sharing from the macOS menu bar.

Environment (100% stock helper signature verified)

• T3 Code Nightly: 0.1.1-nightly.20261019.3373 (commit 300a35670abc0f73662e17c9ce909bcc106be70f)
• macOS: 27.2 (26B118, Apple Silicon)
• Codex CLI (T3 host): 0.163.0 (nested bundled CLI: 0.162.0-alpha.17.2)
• ChatGPT Desktop: 26.1007.71326 (build 20398)
• Computer Use Helper (SkyComputerUseService / com.openai.sky.CUAService): 26.1005.1001425 (build 1001425) — stock OpenAI signature verified (codesign --verify passes; executable is byte-identical to the copy inside /Applications/ChatGPT.app)
• Packages: @oai/sky 0.7.7, @oai/cua-repl 0.1.0, unified-computer-use plugin 26.1007.71326

What we verified

1. Stock helper reproduces the exact tccd Apple Events entitlement denial & SkyComputerUseClient transport failure:

   • Inspection of the installed T3 Code (Nightly).app signature and Info.plist confirms both com.apple.security.automation.apple-events (scripts/build-desktop-artifact.ts:1373) and NSAppleEventsUsageDescription are absent.
   • Unified logs on this machine record the same tccd denial with responsible: com.t3tools.t3code accessing com.openai.sky.CUAService.cli, followed by SkyComputerUseClient failing ~5 seconds after invocation at turn end:
     text

     1	tccd: kTCCServiceAppleEvents requires entitlement com.apple.security.automation.apple-events but it is missing
     2	responsible: com.t3tools.t3code
     3	accessing: com.openai.sky.CUAService.cli
     4
     5	20:00:24 SkyComputerUseClient (PID 7834): Error Domain=ComputerUseClient.ComputerUseIPCXPCTransport.Error Code=2
     6	20:27:04 SkyComputerUseClient (PID 23163): Error Domain=ComputerUseClient.ComputerUseIPCXPCTransport.Error Code=2
     7	20:27:51 SkyComputerUseClient (PID 23626): Error Domain=ComputerUseClient.ComputerUseIPCXPCTransport.Error Code=2

2. Why cua_repl.turn_ended alone doesn't clear the macOS cursor:

   • Although @oai/cua-repl maps Stop, Interrupt, and SubagentStop in .codex-plugin/plugin.json to the hidden cua_repl.turn_ended tool and forwards it to trusted-worker.js, the macOS @oai/sky JS client only registers handlers for browser/app/screenshot/action/audio calls and does not register a turn_ended handler or send ComputerUseIPCCodexTurnEndedRequest.
   • Instead, macOS native cursor teardown relies on Codex's notify = [<SkyComputerUseClient>, "turn-ended"] hook—which is the exact path blocked by T3's missing com.apple.security.automation.apple-events entitlement.

3. Window-server state (CGWindowListCopyWindowInfo) & why stopping macOS screen sharing via the menu bar doesn't remove the arrow:

   • Even after manually stopping screen sharing from the macOS menu-bar icon, CGWindowListCopyWindowInfo showed SkyComputerUseService (PID 4214, parented by ChatGPT.app) still displaying the cursor overlay window on full-screen spaces:
     text

     1	PID=4214 Owner="ChatGPT Computer Use" Name="Software Cursor" Layer=102 Onscreen=1 Bounds=["X": 1119, "Width": 126, "Height": 126, "Y": 899]
     2	PID=4214 Owner="ChatGPT Computer Use" Name="Record & Replay Recording Controls" Layer=3 Onscreen=0 Bounds=["X": 0, "Width": 155, "Height": 56, "Y": 1273]

   • Stopping screen sharing in the macOS menu bar revokes the ScreenCaptureKit capture stream (moving Record & Replay Recording Controls to Onscreen=0), but SkyComputerUseService keeps its separate Software Cursor (CGWindowLayer = 102) window visible because the turn-ended notification from T3 failed.
   • Note also that because SkyComputerUseService is parented by ChatGPT.app (not T3's codex app-server), even quitting T3 or killing codex app-server will not necessarily remove the Software Cursor window once turn-ended has been dropped; SkyComputerUseService itself must receive turn-ended or be terminated.

Cross-referencing #11875 (original symptom report) and #21354 (subagent thread/MCP retention).

Verified via T3 Code orchestration with GPT-6.1-Sol (xhigh), GPT-6-Astra (xhigh), and Gemini 4 Argon High.

Checked current main 8acbefefc5: the generated macOS signing plist still omits com.apple.security.automation.apple-events, and the app Info.plist configuration omits NSAppleEventsUsageDescription. No matching open packaging fix was found. This triage host is Linux; the macOS app, codesign, and TCC runtime are unavailable here, so the reported signed-app cleanup sequence could not be repeated on this host.

Further reproduction: this also blocks Codex Computer History MCP, beyond the cursor-cleanup symptom. Verified on 22 October 2026 with a current OpenAI-signed client and recorder.

Environment

• T3 Code (Beta) 0.1.1, official signed macOS desktop app.
• macOS 27.0.1 (26A434), Apple Silicon (arm64).
• T3-hosted Codex CLI 0.163.0.
• OpenAI Computer Use client and recorder 26.1015.1001540. Both passed strict code-signature verification; the recorder is signed by OpenAI OpCo, LLC (2DC432GLL2). Neither OpenAI app was re-signed during this investigation.
• Computer History plugin 1.0.1001540.

Computer History reproduction

1. Enable the Computer History plugin for a Codex provider hosted by T3, with the local recorder already running.
2. Call computer_history_status in a T3 thread.
3. The call returns isError: true with the text bootstrapTimedOut after approximately five seconds.

This reproduced in separate T3 threads. A fresh SkyComputerUseClient computer-history mcp subprocess successfully completed MCP initialize and tools/list, but its status call still failed after 5.015 seconds. This rules out stale helper processes as the sole explanation. The recorder continued writing new events during the check.

T3's Device Control and Data Access permission was explicitly enabled in System Settings and verified ON before the fresh-client test. The failure persisted.

Matching macOS runtime evidence

At 08:17:36 BST, tccd explicitly rejected the fresh helper's bootstrap. The following excerpts are shortened to remove local paths and process metadata:

Independent signature inspection of the installed T3 app confirms Hardened Runtime is enabled and com.apple.security.automation.apple-events is absent. Its top-level Info.plist also lacks NSAppleEventsUsageDescription.

Latest nightly artifact also inspected

I downloaded the official Apple Silicon desktop ZIP from v0.1.2-nightly.20261022.3512, commit 3b95e7831b11b17627dff16843bc087bfca397ec, and inspected the signed main executable and top-level Info.plist without installing or launching it.

• Asset: T3-Code-0.1.2-nightly.20261022.3512-arm64.zip.
• SHA-256: 940788b022e5e7aed8be4034a92a8165b12000b2441893828422330311e2c5e1, matching the GitHub release API digest.
• The signed executable identifies T3 Tools, Inc. (ARK85ZXQ4Z), com.t3tools.t3code, with Hardened Runtime enabled.
• Both the Apple Events entitlement and the usage-description key are still absent.

This is artifact inspection only; I have not run that nightly end to end. The published artifact therefore still omits these signing declarations.

Impact and requested fix

Computer History MCP status is unusable from the affected T3-hosted Codex sessions even while the recorder itself remains active. Please include this history-access failure in the scope of the macOS signing fix, and retest computer_history_status as well as turn-ended after rebuilding.

No service restart, observation-setting change, permission-database edit or local app re-signing was used as a workaround. No working runtime workaround is established here.

Apple's entitlement documentation describes the required capability.

Still reproduces on the latest Nightly, with a stock (unmodified, OpenAI-signed) Computer Use install.

Environment

• T3 Code Nightly 0.1.4-nightly.20261028.3824
• macOS 15.7.9 (24G830), Apple Silicon
• Codex CLI 0.165.0 (T3 host)
• ChatGPT desktop 26.1023.51421
• Computer Use helper (com.openai.sky.CUAService) 26.1022.1001641
• unified-computer-use@openai-bundled 26.1023.51421

What I verified

1. The entitlement is still missing. codesign -d --entitlements :- "/Applications/T3 Code (Nightly).app" has no com.apple.security.automation.apple-events.
2. Codex calls notify correctly under T3. I wrapped the notify command in a logging script. At the end of each turn, codex app-server called it once with a correct agent-turn-complete payload (thread-id, turn-id, client). So the failure happens after Codex runs the cleanup client, which fits the Apple Events denial described above. I couldn't capture the tccd log line on this machine.
3. The cursor stays until the Codex process exits. I sampled CGWindowListCopyWindowInfo every second. The cursor window appeared on the first click. It stayed for the full 90 s after turn/completed and disappeared within a second of the app-server exiting. T3 keeps the app-server alive between turns, so the cursor lingers indefinitely.
4. It's worse when ChatGPT desktop started the helper. If the helper was launched by ChatGPT desktop (parent process ChatGPT.app), cursors from T3-hosted turns survive even after the Codex process exits. They pile up until the helper is quit.
5. The plugin's own turn_ended hook isn't a workaround. unified-computer-use declares Stop/Interrupt hooks that call cua_repl.turn_ended, but hooks/list on the T3-hosted app-server returns no plugin hooks. I added the same hook to ~/.codex/[config.toml](https://github.com/Users/bt/.codex/config.toml) and trusted it. It fired on Stop and completed, but the cursor stayed.

Workaround

Quitting "ChatGPT Computer Use" (com.openai.sky.CUAService) clears all leftover cursors. The helper relaunches on the next Computer Use action.

Additional reproduction on macOS 26.6.2, Apple Silicon, with T3 Code Nightly 0.1.4-nightly.20261029.3853 and Codex Computer Use helper 26.1022.1001641.

Both list_apps and get_app_state through the configured native Computer Use MCP return bootstrapTimedOut. Accessibility is enabled for both T3 Code (Nightly) and Codex Computer Use.

The macOS unified log attributes the blocked bootstrap to T3. This excerpt omits local paths and process IDs:

Independent inspection of the installed nightly confirms that both com.apple.security.automation.apple-events in its signing entitlements and NSAppleEventsUsageDescription in its top-level Info.plist are absent.

I also downloaded the official stable v0.1.5 release, asset T3-Code-0.1.5-arm64.zip, and inspected the extracted T3 Code (Beta).app without installing or launching it:

• Version: 0.1.5; bundle identifier: com.t3tools.t3code.
• codesign --verify --deep --strict passes.
• The Apple Events entitlement and usage-description key are both still absent.

The runtime failure above is from the installed nightly. The stable result is artifact inspection only, not an end-to-end reproduction. No app signatures or macOS permissions were modified during these checks.

Additional affected workflow on T3 Code Desktop 0.1.6: REA's Hopper launcher is blocked by the same missing Apple Events entitlement.

Environment: macOS 26.6.1 (25G76), Apple Silicon; signed T3 Code (Alpha) app 0.1.6, bundle ID com.t3tools.t3code; Hopper 6.6.1; REA 6.5.0 in the original reproduction. Only one Hopper installation remains active. The installed T3 app passes codesign --verify --strict.

Fresh reproduction on 1 November 2026, without REA or MCP involved:

1. In a T3-hosted agent shell, compile a tiny Mach-O executable: printf 'int main(void) { return 0; }\n' > probe.c; cc -O0 probe.c -o probe
2. Run: "/Applications/Hopper Disassembler.app/Contents/MacOS/hopper" --analysis --executable "$PWD/probe"
3. The launcher exits with code 2:

Cannot launch Hopper! Not authorized to send Apple events to Hopper Disassembler.

At the same time, tccd identifies accessing=hopper and responsible=com.t3tools.t3code, reports the missing com.apple.security.automation.apple-events entitlement, and logs:

Policy disallows prompt for com.t3tools.t3code; access to kTCCServiceAppleEvents denied

Independent inspection confirms that the installed T3 app lacks both that entitlement and NSAppleEventsUsageDescription. The v0.1.6 packaging source and current main 37d7615a91d880c3776d575e1152b9c955104de2 omit both declarations too. PR #23254 remains open and adds both.

Please include this Hopper launcher case in the signed-build validation for #23254. A separate osascript query of Hopper's version succeeds here, so that query alone is not an adequate regression check. No fixed signed build or Terminal-hosted workaround was tested. No installed app, permission setting, or configuration was modified.

Investigated by GPT-6.1-Sol through Codex in T3 Code.

Additional reproduction on 2026-11-03, Mac Studio (Apple Silicon), fresh Codex thread in T3 Code:

Environment

• T3 Code (Beta) 0.1.6 (signed/notarized desktop app, bundle ID com.t3tools.t3code, TeamIdentifier ARK85ZXQ4Z, hardened runtime flags 0x10000(runtime))
• macOS 26.6.2 (25G83), arm64
• Codex CLI (hosted by T3) codex-cli 0.166.0-alpha.5.1
• Codex Computer Use helper 26.1022.1001641 (stock OpenAI install at ~/.codex/computer-use/Codex Computer Use.app)

Steps / observed

1. Fresh Codex thread in T3; all 10 computer-use MCP tools are exposed (list_apps, get_app_state, click, type_text, press_key, scroll, drag, set_value, select_text, perform_secondary_action).
2. Called list_apps → verbatim error: bootstrapTimedOut. No app state could be read.
3. The chain itself loads: SkyComputerUseService is running, and T3's codex app-server spawns the SkyComputerUseClient mcp subprocess for the thread. The failure is at bootstrap/handshake, before any app interaction.

Entitlement verification (same as the maintainer's check on main)

• codesign -d --entitlements - on the installed app: com.apple.security.automation.apple-events is not present (present keys include allow-jit, allow-unsigned-executable-memory, disable-library-validation, device.audio-input, device.camera, associated-domains, keychain-access-groups — no automation entitlement).
• Info.plist: NSAppleEventsUsageDescription does not exist.

So on the current stable desktop build this isn't limited to the post-turn cursor cleanup — the first Computer Use call in a T3-hosted Codex thread times out at bootstrap.

Another affected case, unrelated to Computer Use: any tool run from a T3 Code session that sends Apple Events to a third-party app is silently blocked, and T3 Code never appears under System Settings → Privacy & Security → Automation.

Environment

• T3 Code (Beta) 0.1.6, official signed build (Team ID ARK85ZXQ4Z, hardened runtime)
• macOS 27.2, Apple Silicon
• Target app: Hopper Disassembler (scriptable, NSAppleScriptEnabled), driven by a reverse-engineering MCP server started from a T3 Code session

What I saw

1. The tool reported that macOS denied permission to control Hopper and told me to enable it under Automation.
2. T3 Code was not listed in the Automation pane, so there was nothing to toggle.
3. codesign -d --entitlements - on the app shows no com.apple.security.automation.apple-events, and Info.plist has no NSAppleEventsUsageDescription. This matches the findings above.

With the hardened runtime and no Apple Events entitlement, the system refuses the events without showing a consent prompt. No prompt means no Automation entry, so users can't fix it from Settings.

Workaround that confirmed the cause I made a local copy of the app, added com.apple.security.automation.apple-events and NSAppleEventsUsageDescription, and re-signed it ad hoc. With that build, macOS showed the Automation consent prompt on first use. After I allowed it, T3 Code appeared in the Automation list and the tool could control Hopper. Nothing else changed, so the missing entitlement is the cause.

Side effect of the ad-hoc re-sign: it drops the team-restricted entitlements (application identifier, associated domains, keychain group), so this is a local workaround only.

This looks like the same root cause that #23254 addresses. It affects any scriptable target app, not only the Computer Use helper, so it may be worth mentioning in that PR's description.

Confirmed on the stock, official T3 Code 0.1.8 macOS build at bf469bb.

The signed app still lacks com.apple.security.automation.apple-events, and its Info.plist lacks NSAppleEventsUsageDescription. macOS logs:

A fresh diagnostic identity without the entitlement receives the same denial. An authorized test launched through the bundled signed Codex app-server, using the same native turn-ended path as T3, removed the visible Software Cursor window. The helper returns exit code 0 even when transport fails, so I checked service contact, native errors, and the actual window state.

PR #2796 proposed the missing declarations, but it was closed as fixed by #2745. #2745 changed Tailscale and filesystem TCC behavior. It did not add these macOS declarations. The current stable 0.1.8 app still reproduces the original entitlement denial and transport error.

I prepared a focused fix on current main with the entitlement, usage text, and focused assertions. The focused packaging checks pass and the change adds no runtime workflow.