codex - 💡(How to fix) Fix Privacy/security risk: Codex Computer Use captures wrong macOS Space/window instead of target app

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Codex Computer Use appears to have unreliable target app/window selection on macOS when multiple Desktops / Spaces are used. This is not only a workflow bug; it is also a privacy/security risk because screenshots from the wrong app, window, or Space can be uploaded as model context.

In my workflow, I often keep the Codex desktop app on one primary Desktop/Space and put the actual target app that Computer Use should operate on, such as Google Chrome or another development/browser window, on a different Desktop/Space. This is a common macOS workflow because a single desktop is not enough for many users, so multiple Spaces are used to separate Codex, browser, IDE, terminal, documentation, etc.

The problem is that Computer Use often seems to blindly capture the currently active Desktop/Space instead of first locating which Desktop/Space contains the intended target app/window. As a result, it can capture the Codex app itself or another non-target window and upload that screenshot to the model.

Error Message

For macOS Spaces / multiple Desktops, Codex should improve target app activation and Space switching, or add a clear error path when the target app/window cannot be found or is not visible. A wrong-window screenshot should be rejected locally instead of uploaded and used as context.

Root Cause

Codex Computer Use appears to have unreliable target app/window selection on macOS when multiple Desktops / Spaces are used. This is not only a workflow bug; it is also a privacy/security risk because screenshots from the wrong app, window, or Space can be uploaded as model context.

RAW_BUFFERClick to expand / collapse

Summary

Codex Computer Use appears to have unreliable target app/window selection on macOS when multiple Desktops / Spaces are used. This is not only a workflow bug; it is also a privacy/security risk because screenshots from the wrong app, window, or Space can be uploaded as model context.

In my workflow, I often keep the Codex desktop app on one primary Desktop/Space and put the actual target app that Computer Use should operate on, such as Google Chrome or another development/browser window, on a different Desktop/Space. This is a common macOS workflow because a single desktop is not enough for many users, so multiple Spaces are used to separate Codex, browser, IDE, terminal, documentation, etc.

The problem is that Computer Use often seems to blindly capture the currently active Desktop/Space instead of first locating which Desktop/Space contains the intended target app/window. As a result, it can capture the Codex app itself or another non-target window and upload that screenshot to the model.

Environment

  • App: Codex desktop app for macOS
  • Codex version: 26.506.21252 (2575)
  • macOS: Tahoe 26.4.1
  • Device: Apple Silicon MacBook Pro
  • Plan: ChatGPT Pro
  • Workflow: macOS multiple Desktops / Spaces, with Codex on one Desktop and target apps on other Desktops

Steps to reproduce

  1. Open the Codex desktop app on one macOS Desktop/Space.
  2. Open the target app, such as Google Chrome, on another Desktop/Space.
  3. Start a Codex Computer Use task that needs to inspect or operate the target app.
  4. Let Codex run its screenshot/capture step for the target app.
  5. Observe the screenshot returned to the model.

Actual behavior

Computer Use often captures the currently active Desktop/Space or the Codex app window itself instead of the intended target app/window.

For example, the task can show that it is running a screenshot command for a target app such as Google Chrome, but the screenshot that gets returned/uploaded is of the Codex app UI or the wrong Desktop/Space.

In practice, Computer Use may capture the wrong app/window several times at the beginning of a task before it gradually gets back on track. However, if automatic context compaction/compression happens in the middle of the task, it can drift away again and start capturing the wrong Desktop/window several more times before recovering. This creates repeated cycles of wrong screenshots and wasted model work.

This suggests that Computer Use is not reliably checking where the target app/window is located before taking the screenshot. It appears to capture whatever Desktop is currently active, even when that Desktop is not where the target app is.

Expected behavior

Computer Use should reliably capture only the intended target app/window.

Before taking and uploading a screenshot, Codex should identify the target app/window and the macOS Desktop/Space where that app/window is located. If the target app is on another Space, Codex should either:

  • correctly switch/focus the target app and capture it,
  • use a more reliable app/window-specific capture mechanism,
  • ask the user to bring the target window to the active Space,
  • or fail clearly with a target-window-not-found / target-window-not-visible message.

It should not silently capture Codex itself, the currently active Desktop, or unrelated windows when the requested target app/window is not actually visible there.

Impact

This causes several serious workflow and safety problems:

  1. Computer Use task failure / wrong context
    The model receives screenshots of the wrong app/window, so its reasoning and next actions are based on incorrect visual context.

  2. Large token and usage waste
    The wrong screenshots are still uploaded and processed as visual input. When Computer Use repeatedly miscaptures the wrong Desktop/window, it can waste a large amount of tokens and consume usage quota much faster than necessary. This is especially painful for Pro users because usage is limited, and these failed screenshots consume quota without producing useful work.

  3. Repeated waste after context compaction
    The issue is not always limited to the beginning of a task. After automatic context compaction/compression, Computer Use can lose track of the correct Desktop/window again, repeat the same wrong-screenshot behavior, and only later recover. This can multiply the amount of wasted usage during long-running tasks.

  4. Privacy/security risk
    In my specific case, the accidental screenshots captured the Codex app itself, so it was not a major privacy leak. But the underlying behavior is risky: uncontrolled non-target screenshots could expose other users' private content from unrelated windows or Spaces, such as messages, emails, documents, account pages, or personal files.

  5. Bad fit for normal macOS workflows
    Many Mac users use multiple Desktops / Spaces specifically to organize work across several apps. A user may reasonably keep Codex on one Space while the browser/IDE/terminal being controlled lives on another Space. Computer Use should handle this workflow instead of assuming the current Space always contains the target window.

Suggested fix

Please make Computer Use validate that the captured screenshot actually belongs to the requested target app/window before uploading it to the model.

For macOS Spaces / multiple Desktops, Codex should improve target app activation and Space switching, or add a clear error path when the target app/window cannot be found or is not visible. A wrong-window screenshot should be rejected locally instead of uploaded and used as context.

Codex should also preserve the target app/window/Desktop state across automatic context compaction/compression, so long-running Computer Use tasks do not repeatedly drift back to the wrong Space after compaction.

Screenshots

I have screenshots showing:

  1. Computer Use running a screenshot step that appears to target Google Chrome, while the captured image is the Codex app UI.
  2. The macOS Mission Control / multiple Desktop layout where Codex is on one Desktop and other target apps are on separate Desktops.

I cannot attach screenshots through this automated issue creation path, so I will add them manually after creating the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Computer Use should reliably capture only the intended target app/window.

Before taking and uploading a screenshot, Codex should identify the target app/window and the macOS Desktop/Space where that app/window is located. If the target app is on another Space, Codex should either:

  • correctly switch/focus the target app and capture it,
  • use a more reliable app/window-specific capture mechanism,
  • ask the user to bring the target window to the active Space,
  • or fail clearly with a target-window-not-found / target-window-not-visible message.

It should not silently capture Codex itself, the currently active Desktop, or unrelated windows when the requested target app/window is not actually visible there.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING