›_ Codex Issues
Codex Issues / #23452

Codex Desktop: Computer Use blocks get_app_state(Codex) with "not allowed ... for safety reasons" even after reinstall

Open 💬 2 comments Opened May 19, 2026 by pranaysuyash

Summary

After fully quitting and reinstalling the Codex desktop app, Computer Use still cannot inspect the Codex app itself. Calling get_app_state on Codex returns:

Computer Use is not allowed to use the app 'com.openai.codex' for safety reasons.

This is different from a generic permissions issue. The error appears specifically when the target app is the Codex desktop app itself.

Environment

  • App: Codex Desktop
  • Platform: macOS
  • Target app bundle: com.openai.codex
  • Installation state: fresh reinstall from a newly downloaded app
  • Context: current session after restart + reinstall

What I expected

I expected get_app_state(Codex) to either:

  • return the current app state, or
  • return a permissions prompt / approval flow that I can complete, if Codex Desktop supports self-inspection in this session.

What actually happened

get_app_state(Codex) returns:

Computer Use is not allowed to use the app 'com.openai.codex' for safety reasons.

This happens even after:

  • fully quitting Codex
  • relaunching Codex
  • reinstalling Codex from a fresh download

Reproduction steps

  1. Open Codex Desktop on macOS.
  2. Fully quit the app.
  3. Reinstall Codex from a fresh download.
  4. Relaunch Codex.
  5. In a session that has Computer Use available, call get_app_state with the Codex app target.
  6. Observe the safety error.

Notes

This is not the same as:

  • a missing Accessibility permission
  • a Screen Recording permission problem
  • a plugin not being installed
  • a stale resumed thread approval issue

The target is the Codex desktop app itself, and the error is a direct safety refusal rather than a permissions prompt.

Related issues

I found closely related issues, but none that match this exact self-targeting safety block after reinstall:

  • #18803
  • #18522
  • #21846

Why this matters

This blocks any attempt to use Computer Use to inspect or validate Codex Desktop itself, including:

  • app-state inspection
  • UI verification
  • troubleshooting the desktop app through the same session

That makes it difficult to distinguish a real app problem from a tool-layer restriction when debugging Codex Desktop behavior.

Requested fix / clarification

Please clarify whether this is:

  1. intended behavior by design,
  2. a missing permission/authorization path for self-targeting Codex app inspection, or
  3. an overly broad safety rule that should return a more explicit unsupported/error state.

If self-targeting the Codex app is intentionally blocked, it would help to document that clearly and return a message that distinguishes policy restriction from setup failure.

View original on GitHub ↗

2 Comments

dispositives · 3 months ago

Codex is not supposed to use it on their own app. Should use computer use on safari or Google Chrome

sgd-wj · 1 month ago

I can reproduce this on the current macOS desktop stack:

  • ChatGPT/Codex Desktop: 26.721.41059 (build 5848)
  • Computer Use: 1.0.1000502
  • Target: com.openai.codex

The refusal is still:

Computer Use is not allowed to use the app 'com.openai.codex' for safety reasons.

A concrete benign use case is project/sidebar management. A user explicitly asked the agent to register an existing local folder as a Codex Project and verify that it appeared in the sidebar. This requires either read-only self-inspection or a small, reversible UI action, yet the blanket target ban blocks the entire path.

For power users who use Codex as a multi-project control center, safe self-UI actions are valuable:

  • read-only inspection of Codex UI state
  • selecting or navigating Projects and tasks
  • adding, renaming, or pinning a Project
  • verifying that an explicitly requested sidebar change succeeded

I am not requesting unrestricted self-control. A tiered policy would preserve the important safety boundary:

Allow with explicit user authorization and an audit trail

  • read-only inspection
  • reversible navigation
  • allowlisted Project/task organization actions

Keep hard-blocked or require handoff

  • approving the agent's own permission prompts
  • credentials and authentication
  • security/privacy settings
  • destructive deletion of tasks or history
  • high-impact external actions

An emergency stop and per-action audit record would further contain risk.

The current blanket restriction can push agents toward less direct fallbacks. In this reproduction, a CLI fallback failed to recognize the integrated desktop app and began downloading a separate installer before it was stopped. A scoped first-party path would have been both simpler and safer.

If self-targeted Computer Use cannot be safely exposed, please add first-party structured tools for Project/sidebar management. That would complement #25385 while preserving the broader safety boundary.