macOS: timed-out Computer Use list_apps() call leaks PreventUserIdleDisplaySleep assertion for 34 hours

What version of the Codex app are you running?

26.803.61601 (build 6396)

The bundled Computer Use plugin/runtime cache version was 1.0.1000633.

What subscription do you have?

ChatGPT Pro ($200/month, 20x usage tier)

What platform is your computer?

Darwin 25.6.0 arm64 arm

macOS 26.6.1 (build 25G76), Apple silicon.

What issue are you seeing?

A Computer Use call timed out and reset its JavaScript kernel. The call's SkyComputerUseService process then retained a macOS PreventUserIdleDisplaySleep power assertion named Codex Computer Use interaction for 34 hours, 3 minutes, and 4 seconds.

The assertion prevented normal display-idle sleep while the Mac was on battery. It remained active until after the Mac entered low-power hibernation at 1% battery and later woke when AC power was connected.

This was not a general service crash. Later Computer Use calls succeeded and released their own assertions. Only the assertion created for the timed-out call remained active.

The assertion materially contributed to battery drain. Other independent power assertions existed during part of the interval, so I cannot claim that it was the only source of battery use.

What steps can reproduce the bug?

This section describes the observed incident. One controlled client-timeout test on the current build did not reproduce the leak. That test did not recreate the original natural 30-second list_apps() hang, so it does not show that the original failure path is fixed.

1. Start a Computer Use JavaScript call on macOS that calls sky.list_apps().
2. Let the call exceed its 30-second execution timeout so that the JavaScript kernel resets.
3. After the timeout, inspect macOS power assertions with pmset -g assertions or the unified log.
4. Observe that SkyComputerUseService still owns a PreventUserIdleDisplaySleep assertion named Codex Computer Use interaction.
5. Make another Computer Use call. It can complete normally and release its own new assertion, while the assertion from the timed-out call remains.

The call that failed was:

const r = await tools.mcp__node_repl__js({
  title: "Identify Codex app build",
  timeout_ms: 30000,
  code: `var appsNow = await sky.list_apps();
  nodeRepl.write(JSON.stringify(appsNow.filter(a => /chatgpt|codex/i.test((a.displayName||"")+" "+(a.id||"")))));`
});

The tool first reported:

Script running with cell ID 14

The subsequent wait failed with:

js execution timed out; kernel reset, rerun your request

The Codex session ID was:

019ff765-98ff-7ad3-b06d-43bdd0956eb9

The user aborted the task after the timeout. The assertion was created before the abort and was already leaked when the timeout occurred.

What is the expected behavior?

Computer Use must release every call-scoped power assertion after the call finishes, fails, times out, is cancelled, loses its client, or resets its JavaScript kernel.

After a timeout, pmset -g assertions should return to its pre-call Computer Use assertion state within a short, bounded interval.

Additional information

Correlated timeline

Times below are in America/Los_Angeles.

| Time | Event |
| --- | --- |
| 2026-08-12 12:16:34 | The list_apps() call started. SkyComputerUseService PID 66184 created UserIsActive assertion 0x0x90000985d and PreventUserIdleDisplaySleep assertion 0x0x50000985e, both named Codex Computer Use interaction. |
| 2026-08-12 12:17:04 | The tool reported js execution timed out; kernel reset, rerun your request. |
| 2026-08-12 12:17:09 | A later Computer Use call created and released a different display-sleep assertion, 0x0x500009865, in less than one second. Later calls also released their own assertions normally. |
| 2026-08-12 12:17:34 | The original UserIsActive assertion expired normally after 59 seconds. The original PreventUserIdleDisplaySleep assertion remained active. |
| 2026-08-13 21:21:29 | The leaked display-sleep assertion was still active, with an age of 33:04:55. |
| 2026-08-13 21:21:30 | The Mac entered low-power sleep at 1% battery. |
| 2026-08-13 22:18:36 | The Mac woke from hibernation after AC attachment and user activity. |
| 2026-08-13 22:19:38 | The original display-sleep assertion was released at age 34:03:04. The service process remained alive. |

Relevant sanitized log excerpts

Assertion creation:

2026-08-12 12:16:34 -0700 Assertions
Created PreventUserIdleDisplaySleep "Codex Computer Use interaction"
process=SkyComputerUseService pid=66184 id=0x0x50000985e

Still active after more than 33 hours:

2026-08-13 21:21:29 -0700
SkyComputerUseService pid 66184: PreventUserIdleDisplaySleep
named: "Codex Computer Use interaction"
age: 33:04:55
id: 0x0x50000985e

Final release:

2026-08-13 22:19:38 -0700 Assertions
Released PreventUserIdleDisplaySleep "Codex Computer Use interaction"
process=SkyComputerUseService pid=66184 id=0x0x50000985e
age=34:03:04

The exact unified-log wording can vary by macOS release. I can attach a narrow, sanitized log export if maintainers request it.

Controls and exclusions

• Battery power settings allowed automatic sleep: sleep=1 and displaysleep=2.
• Standard Screen Sharing did not own a sleep-prevention assertion during this incident.
• Amphetamine stopped its assertion as configured near 15% battery.
• Computer Use calls immediately after the failure created and released separate assertions normally.
• The leaked assertion remained attributed to SkyComputerUseService and retained the same assertion ID for its full lifetime.
• No other retained power log showed another long-running Computer Use assertion. This is one confirmed incident, not yet a deterministic reproduction.

Root-cause hypothesis

The timeout/kernel-reset path appears to skip cleanup for the display-sleep assertion acquired for the call. The fact that the service remained usable and released later call-specific assertions suggests that the leak belongs to the failed request lifecycle, not to a fully hung service.

The release shortly after wake suggests that a later lifecycle event cleaned up stale state. That point is an inference from timing, not a confirmed implementation detail.

Suggested safeguards

• Release the assertion in every success, error, timeout, cancellation, client-disconnect, and kernel-reset path.
• Give the service-owned assertion a bounded lease or watchdog. Client-side cleanup alone cannot run after a client kernel reset.
• Reconcile stale request assertions when a client reconnects, a new interaction starts, or the Mac wakes.
• Add a regression test that forces a list_apps() timeout and verifies that the IOPM assertion state returns to its baseline within a bounded interval.

Current status

The current installed app is 26.810.41047 (build 6570) with Computer Use helper 26.812.1000717 (build 1000717). There is currently no stuck Computer Use power assertion.

Controlled current-build retest

On 2026-08-14, I ran one bounded test while the Mac was connected to AC power:

1. Confirmed that SkyComputerUseService PID 42519 owned no power assertion.
2. Ran a normal sky.list_apps() call. It returned 58 apps in 47 ms and released cleanly.
3. Ran the same call with a 10 ms JavaScript execution limit. The tool returned js execution timed out; kernel reset, rerun your request.
4. Checked immediately after the timeout and again more than one minute later. PID 42519 owned no Codex Computer Use interaction assertion.
5. Ran a normal post-reset sky.list_apps() call. It returned 58 apps in 33 ms and released cleanly.

Result: a forced client-side timeout did not reproduce the leak on the current build. The helper stayed alive and usable. This is useful negative evidence, but it is not equivalent to the original incident, where list_apps() itself remained pending for approximately 30 seconds before the kernel reset.

Related issues searched

I searched existing Codex issues on 2026-08-14 before preparing this report. I did not find an exact report for a Computer Use timeout leaking PreventUserIdleDisplaySleep on macOS.

• #35659 reports a different macOS Computer Use resource-lifecycle leak: a ScreenCaptureKit stream that continues after an interaction ends.
• #36958 reports Computer Use and Buzz processes continuing after Codex closes. It concerns process shutdown and unwanted app control, not a timeout leaking a power assertion.
• #29157 reports leaked SkyComputerUseClient turn-ended helper processes.
• #37686 documents another Computer Use defect in app build 26.803.61601 and provides a useful example of environment, timing, control, and retest evidence. It does not report a power-assertion leak.