›_ Codex Issues
Codex Issues / #33748

[Bug] Computer Use icon remains visible when no task is running

Open 💬 2 comments Opened Jul 17, 2026 by xiaohou77

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

26.707.72221

What subscription do you have?

Pro

What platform is your computer?

Mac OS

What issue are you seeing?

Description

The Computer Use icon remains visible in the Codex UI even when there is no active task running.

The icon appears to indicate that Computer Use is currently active, but there is no ongoing agent execution or computer interaction.

Screenshot

<img width="1126" height="458" alt="Image" src="https://github.com/user-attachments/assets/a29245ff-effd-43b8-ba60-9048d1b4437e" />

What steps can reproduce the bug?

  1. Open Codex.
  2. Run a task (I was building a to do list app) that uses Computer Use.
  3. Wait until the task finishes.
  4. Return to the idle state.
  5. Observe the Computer Use icon in the UI.

What is the expected behavior?

The Computer Use icon should only be displayed when:

  • A Computer Use action is actively running, or
  • The agent is currently executing a task that requires Computer Use.

The icon should disappear when Codex returns to an idle state.

Additional information

_No response_

View original on GitHub ↗

2 Comments

TyceHerrman · 1 month ago

I can reproduce this on macOS, and it is not merely a stale Codex icon.

After a Computer Use turn involving Raycast Beta completed, the cursor overlay and macOS capture indicator remained. The Computer Use menu itself reported “No Active Sessions,” while SkyComputerUseService and CUALockScreenGuardian were still running.

The helper accepted the normal turn-ended notification with the exact thread and turn IDs, but did not shut down. Restarting Raycast Beta also did not clear it.

Sending SIGTERM to those two helper processes from a normal Terminal immediately removed the cursor and capture indicator.

This appears to be a lifecycle/state mismatch: the session registry reports no active session, but the helper and capture UI are not torn down.

Possibly related: #30503.

100yenadmin · 1 month ago

Additional lifecycle evidence from ChatGPT desktop 26.721.41059 / Computer Use 1000502 on arm64 macOS:

  • CUALockScreenGuardian.app is present inside the Computer Use bundle; its executable exists and its signature validates.
  • No Guardian process was running and there was no Guardian crash report.
  • SkyComputerUseService started around 01:05, with no repeated Guardian lookup errors for roughly 100 minutes.
  • The repeating error began immediately after the ChatGPT client's XPC connection was invalidated/exited around 02:46:
Could not look up the Guardian Mach bootstrap rendezvous port.
  • The message then repeated approximately once per second for hours while IOConsoleLocked = No.
  • SkyComputerUseService remained at approximately 0.0% CPU, so this is a persistent log/retry loop rather than a CPU spin.

This does not look like ordinary screen-lock polling: it begins after client/session teardown, continues while the screen is unlocked, and was absent during the service's earlier idle period. It appears consistent with stale Computer Use lifecycle state that keeps looking for a Guardian endpoint after the initiating client is gone.

Important confounder: the initiating Computer Use attempt was rejected by the custom-CLI authentication problem tracked in #34583. That could be the trigger, so this report does not claim the Guardian retry is independently reproducible with the stock CLI.

Expected behavior would be to clear the Guardian expectation when the client/session aborts, or at least use bounded retry/backoff. Manually launching the Guardian should not be required; the service owns its lifecycle for Locked Computer Use.