[ChatGPT desktop] Agents repeatedly invoke Computer Use against the documented-prohibited ChatGPT host target

Summary

OpenAI documents that Computer Use cannot automate ChatGPT itself. This report does not challenge that safety restriction.

The defect is that agents and tasks still select and invoke Computer Use when the intended target is the protected ChatGPT host application. The same deterministic call can recur in later tasks instead of being rejected during tool-selection preflight.

In the current ChatGPT-branded desktop app, targeting the displayed application name ChatGPT resolves to bundle com.openai.codex and returns:

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

Environment

• ChatGPT desktop: 26.810.41047
• Build: 6570
• Displayed application name: ChatGPT
• Bundle identifier: com.openai.codex
• macOS: 26.6.1 (25G76)
• Architecture: arm64

Reproduction

1. Open the current ChatGPT desktop application.
2. Ask an agent to perform read-only verification of host-app state, such as the active Work view or visible model controls.
3. Observe that the agent selects Computer Use against ChatGPT.
4. Observe that the target resolves to com.openai.codex and produces the refusal above.
5. Start a separate task that again requires host-app state verification.
6. Observe that Computer Use is selected again and produces the same refusal instead of being suppressed before invocation.
7. Enable performance tracing, repeat the reproduction, and upload diagnostics through /feedback.

No UI control or setting needs to be changed for the refusal to occur.

Actual defect

The agent/tool-selection path does not consistently:

• Detect that ChatGPT, Codex, and com.openai.codex identify the protected host target.
• Suppress a Computer Use call that the product already documents as unsupported.
• Return one structured unsupported-target result.
• Prevent the same prohibited attempt from recurring in later tasks.

This produces deterministic tool errors, repeated warnings, wasted turns, and deadlocks in workflows that require directly verified Work, project, model, or reasoning-effort state.

Expected behavior

1. Normalize the intended application target before invoking Computer Use.
2. Detect the protected ChatGPT/Codex host target and suppress the tool call.
3. Return one structured unsupported-target result with the documented reason.
4. Do not retry the prohibited target in the same or a later task.
5. Use directly exposed non-Computer-Use state when available, or request user confirmation when that state is necessary.

Official documentation

OpenAI’s Computer Use safety guidance states:

“The feature can't automate terminal apps or ChatGPT itself, since automating them could bypass ChatGPT security policies.”

https://learn.chatgpt.com/docs/computer-use#safety-guidance

The cited guidance establishes the restriction. It does not describe why the agent/tool-selection layer continues to invoke Computer Use against that known-prohibited target instead of suppressing the call.

Secondary enhancement

A safe first-party read-only interface for the current Work view, attached project folders, and visible model/reasoning labels would help workflows that need those facts.

That fallback is secondary. The primary requested fix is to prevent agents from making the documented-prohibited Computer Use call.

Relation to existing issues

• #23452 reports the underlying self-target refusal. This issue treats that refusal as documented behavior and focuses on preventing repeated invocation.
• #24761 reports the routing problem in an older Codex-branded build. This issue documents its persistence in the current ChatGPT-branded unified app, including the ChatGPT to com.openai.codex resolution and Work-state verification impact.
• #30078 requests a specific first-party action for starting Codex Security scans. This issue concerns general tool-selection preflight for the protected host target.

Diagnostics

• Current reproduction and uploaded performance trace: 019ffd37-1d8e-7990-844d-db179621e63a
• Earlier related submission from #24761: 019e6834-96ee-7241-8849-243ae305b74d

The current trace was uploaded privately through /feedback. No trace, log, screenshot, private path, project identifier, account detail, or confidential material is attached publicly.