Multi-Monitor Computer Use Audit

Bottom line

Keep the four-monitor setup. The high-value improvement is operational: assign the agent one target application window, keep it maximized on the primary display for a task, and refresh its observation after every action. Do not change monitor count to chase token savings.

Quality risk: conditional, not automaticMixed DPI is a real Windows coordinate-space concern for legacy or global-coordinate harnesses. It is not evidence that extra monitors alone cause Codex clicks to drift.
Cost claim: unsupported for this runtimeWindow capture means unused monitors are not carried into the screenshot. The actual cost driver is the number and detail of observations, not the virtual desktop width.
Speed: indirect effect onlyModel inference is not inherently slowed by monitor count. Bad capture framing, state changes, or retries can make a task take longer.

01 / Claim audit

What holds up—and what does not.

Each conclusion distinguishes a generic full-screen computer-use harness from the current Codex Windows integration. That distinction changes the recommendation.

Claim	Generic full-desktop harness	Codex Windows runtime	Audit finding
More monitors cause coordinate drift	Plausible Global coordinates plus mixed-DPI windows can be mis-translated.	Not inherent The runtime selects a target window, then uses coordinates from that current window screenshot.	Use target-window capture and a fresh observation; do not infer drift from monitor count.
A wide desktop wastes image tokens	Plausible Only if the harness sends a full virtual-desktop image.	Not supported The runtime documents window screenshots, not a monitor-spanning canvas.	Measure screenshot count and target-window size before considering display changes.
More monitors slow model processing	Indirect Larger images or retries may lengthen task completion.	No direct mechanism Unselected monitors are outside the captured window.	Retries, animation, modal windows, and stale observations are the practical latency risks.

02 / Why this changes

The capture boundary matters more than the desktop boundary.

OpenAI’s Computer Use API has the harness declare its display dimensions and return screenshots after actions. Windows Graphics Capture can capture either a display or a specific application window. Codex’s bundled Windows guidance explicitly uses a selected target window and fresh screenshots whose coordinates are valid only for that observation.

Target window, not global desktop

Codex window selection and capture isolate the task surface. This directly removes the user’s claimed “wasted canvas” mechanism for this runtime.

DPI is a real integration seam

Windows does expose different coordinate spaces for DPI-unaware, system-aware, and per-monitor-aware applications. A legacy application or poorly built external harness can still render or report coordinates inconsistently when moved between displays.

Observation freshness is the guardrail

After a click, resize, modal, focus change, or move across displays, previous coordinates are stale. The reliable loop is observe → one action → immediately refresh.

03 / Local risk map

Your layout is good for people; make it predictable for agents.

The configuration has mixed resolutions and a non-rectangular virtual desktop. That matters only if an agent or third-party harness reaches for screen-wide pixels instead of an explicitly selected window.

Primary: 2560×1440Best default home for an agent’s target application.

Three secondary 1920×1080Useful for human monitoring; do not include them in a capture unless required.

Top display at y = −1080Creates a non-rectangular virtual desktop; avoid global coordinate assumptions.

32-bit color throughoutNo color-depth inconsistency detected in the display audit.

04 / Recommended changes

Three changes, in priority order.

These are procedural changes; no monitor purchase, cabling change, or Windows scaling edit is justified by the evidence gathered here.

01 / Do now

Standardize the agent workspace

For any computer-use task, put the active application on the 2560×1440 primary display, maximize it, and keep unrelated windows off the task surface. Prefer window targeting over a whole-screen screenshot.

02 / Do now

Use an explicit observe–act loop

Require a new target-window observation before every coordinate action and immediately after every input. Never reuse coordinates, element indexes, or screenshot IDs after a layout or focus change.

03 / Audit before changing

Test DPI only if symptoms appear

If clicks miss only after moving a window between displays, first keep that window on one display for the task. Then inspect the target app and harness DPI awareness; harmonize scaling only if a reproducible defect remains.

05 / Verification

How to prove a future setup change helps.

Use the same short interaction sequence on the same application window, then compare outcomes—not impressions.

Metric	Baseline	Pass condition
Click accuracy	20 repeated actions in a fixed window position	20/20 correct with no manual correction
Observation count	Record screenshots/observations per completed task	No increase after a configuration change
Retry rate	Record re-observations caused by focus, modal, or missed action	Lower than baseline; categorize cause
Task time	Wall-clock time for the same deterministic script	Improves without lowering click accuracy

Multi-monitor is not the root problem.