What to Do When the 2026 Codex App Can't See Mac Research Software Windows?

OpenAI’s computer-use guide says desktop interaction may require screen and audio recording and accessibility permissions, depending on the task. Those are separate checks, not proof that the feature is available or allowed in your workspace. This week, confirm the Codex app has computer-operation access, check the relevant macOS permissions and workspace policy, then test with a non-sensitive window. A missing or unreadable window alone does not establish that your research software is incompatible. (OpenAI computer-use guide; Apple screen and system audio recording settings; Apple accessibility settings)

Who this is for: Graduate students and researchers using Codex to inspect or operate Mac research software can locate the likely failure layer.
Mac administrators can check permissions and organization policy without trying to bypass them.
Developers validating research software can separate a visible window from a successful workflow test.

Last updated November 6, 2026. Checked against OpenAI’s Codex and computer-use documentation, its workspace policy guidance, and Apple’s macOS privacy and security documentation. Recheck these sources before following interface-specific steps, since feature availability and setting labels can change.

What does “can’t see the window” mean?

Treat “can’t see it” as a symptom, not a diagnosis. It can mean that computer operation is unavailable in the current client or workspace, that macOS has not authorized the app to access the relevant context, or that the feature is available but cannot identify or interact with this particular window. These cases need different fixes.

Separate the issue into four observable states:

No computer-operation option: You cannot start the relevant capability in your current Codex app or workspace.
The option exists, but the window is absent: The session does not show the target app or its contents.
The window appears, but its contents are not usable: The software is visible, but the Codex app cannot interpret the relevant controls or information.
The window is readable, but input does not work: The app can identify the interface, but clicks or typing do not produce the expected result.

Record what happens before changing settings. Use a blank, ordinary desktop window that contains no research data, credentials, or personal information. Note the client you opened, the target window, the visible response, and the specific action that failed. That gives you a safe reproduction case and prevents you from confusing an app-specific problem with a feature or policy restriction.

Why can’t the Codex app see research software that is already open on my Mac? The window being open only establishes that macOS is displaying it to you. It does not establish that the Codex app has computer-operation access, that its process has the necessary permissions, or that the feature can interpret that interface.

OpenAI’s product and help materials describe computer interaction and the relevant desktop-app context; they do not establish universal support for every research application or every window. Check the current computer-use guide and desktop app information for the client and capability you are actually using. Do not infer that a research app is unsupported until the more basic availability, permission, and policy checks are complete.

If the computer-operation option is missing

Start with availability, not macOS settings. A system privacy permission cannot add a feature that the current client does not offer or that your account or organization has not enabled.

Check these points in order:

Confirm which desktop client you launched and whether it is the client described by the current OpenAI documentation. Do not assume that instructions for one desktop app automatically describe another.
Look for the computer-operation entry in the current interface. If it is absent, compare your client and account context with OpenAI’s current desktop app migration guidance and information about ChatGPT Work and Codex.
If you use an organization-managed workspace, ask its administrator whether computer operation is available and permitted there. Do not try to work around a control that the organization has set.
Capture the client name, the account or workspace context, and what you see in the interface. Share those details with the administrator or support channel instead of changing unrelated privacy settings.

Can a workspace administrator turn off Codex desktop operation? OpenAI documents workspace controls for browser and computer use in enterprise environments. That means an absent option or blocked action may be a policy choice, not a macOS fault. Ask the administrator to verify the applicable workspace computer-use policy. If the policy does not allow the feature, stop there; a local permission change cannot override an organization’s decision.

If your client or workspace does not provide the capability, record that as the result of the check. Reinstalling unrelated software or granting broad system access will not establish availability.

When the window exists but its contents cannot be read

Once you have confirmed that computer operation is available and allowed, inspect macOS privacy permissions. Screen content access and accessibility access serve different purposes. Do not treat one as a substitute for the other, and do not grant access to an app just because its name resembles the client you use.

Open System Settings and go to Privacy & Security.
Review Screen & System Audio Recording for the desktop app you are using. Apple’s instructions describe where this permission is managed; the exact label can vary with the macOS version. See Apple’s screen and system audio recording guidance.
Review Accessibility separately. Check whether the relevant app is listed and whether access is enabled. Apple explains this authorization in its accessibility settings guide.
Confirm the permission belongs to the app you actually launched. If you use more than one desktop client, do not assume authorization for one applies to another.
If a permission was missing, follow the macOS prompt or the relevant official instructions, then retry your harmless test. If macOS asks you to quit and reopen an app, follow that prompt rather than assuming a settings change has taken effect immediately.

Permission changes can make more desktop information accessible to an application. Grant only what the feature requires, only to the intended app, and only when permitted by your institution. If a setting is managed or unavailable, ask the Mac administrator; do not attempt to remove management controls.

Permission check: Seeing an app listed in a privacy panel does not prove that the current Codex session can read a particular window. Confirm the client, the session, the workspace policy, and the result of a controlled test separately.

Where should you check macOS screen and accessibility access? Start in System Settings → Privacy & Security, then review screen and system audio recording and accessibility as separate entries. Use Apple’s current instructions for your macOS version. If the client is missing from a list, or a control is locked by management, document that state and ask the responsible administrator before changing anything.

When the window is visible but clicks or typing fail

A window can be visible without being interactable. Treat these as separate results: seeing the window does not prove that the Codex app can issue input, that the particular control can be identified, or that workspace policy permits the action.

Use a reversible test. On a blank document or an isolated, non-sensitive screen, ask for a simple action that you can undo, such as selecting a harmless control or entering temporary text that you then remove. Do not test by editing a real data set, submitting a form, overwriting a project file, or running an operation that changes research results.

If there is no response:

Check whether the attempted action is allowed by your workspace’s computer-use policy. If you cannot confirm that, ask the administrator.
Confirm that you tested the window currently in focus and that the interaction request refers to the intended control.
Try a different harmless window. If it works there but not in the research app, preserve that distinction; it points to an app- or interface-specific issue, not a general permission conclusion.
Record whether the window was visible, whether its contents were readable, which action you tried, and what happened. Avoid recording sensitive screen contents in a troubleshooting report.

What if the window can be read but not clicked? Check policy and interaction separately from screen access. If policy allows the action, reproduce it with an undoable test and compare the result in a blank window. A readable interface with ineffective input does not by itself prove that more macOS permissions are needed.

When only one research application fails

If a harmless window works but a particular research app does not, keep the conclusion narrow: you have reproduced a problem with that app or window state, not demonstrated general incompatibility across macOS. OpenAI’s documentation does not guarantee that every research tool, custom interface, or control will be recognized.

Before escalating, capture enough information for someone else to reproduce the failure:

The research application and the specific window or screen involved.
The macOS version and the desktop client version shown by the relevant app’s own information panel.
Whether the computer-operation entry was available and whether the workspace permitted it.
Which permissions were checked and whether the app appeared in the relevant lists.
Whether the test window was visible, readable, and responsive to the harmless action.
The shortest sequence of actions that reproduces the issue, without including research data or credentials.

Also check the state of the target window. For example, test a standard, unobstructed screen rather than a transient dialog, a minimized window, or a view that has not finished loading. This is a diagnostic comparison, not a claim that any one window state is universally unsupported. If the issue happens only in one interface, report it that way and ask the software’s maintainer or your institution’s support team whether that interface is expected to work.

Do not classify the research tool as incompatible based on a single test. Likewise, do not tell colleagues that it is supported because one window was visible once. Keep the tested app, version, window state, and action attached to the conclusion.

Use a safe checklist before accepting a research workflow

A window test is only the beginning of GUI acceptance. A research workflow needs its own acceptance criteria, and those criteria should be checked in an isolated project area with non-sensitive or synthetic input.

[ ] Confirm the current client exposes computer operation in the account and workspace you will use.
[ ] Confirm the workspace policy permits the planned interaction; ask an administrator if its status is unclear.
[ ] Check screen and system audio recording and accessibility permissions separately for the correct desktop app.
[ ] Reproduce window visibility and content reading with a harmless, ordinary window.
[ ] Test a reversible interaction without editing a real research file.
[ ] Use an isolated project area to verify only the intended workflow steps, such as opening a test file, carrying out a reversible action, and checking the resulting output.
[ ] Have a person review the output against the project’s own validation criteria before treating it as accepted.
[ ] Keep separate records for interface visibility, successful interaction, workflow completion, result validity, and institutional approval.

A successful GUI interaction establishes only that a particular action worked in that tested context. It does not validate the scientific method, confirm that the output is correct, or show that the data handling meets your institution’s requirements. Those decisions need independent checks by the people responsible for the research and its governance.

For a broader, isolated testing plan, see OSXFlow’s Mac workflow examples and Mac guides. Use them as planning references, not as evidence that a specific Codex feature, research application, or institutional policy is supported.

Choosing a Mac environment for the next test

If you have a suitable local Mac and your institution permits the workflow, local testing may be simplest: you control the physical environment and can coordinate directly with your lab’s support staff. But buying a Mac solely to diagnose one blocked window can be a poor fit if your budget is limited, the task is temporary, or your institution already provides an approved machine.

A remote Mac may be worth evaluating when you lack access to a Mac and need a temporary macOS environment for interactive acceptance. It does not solve a missing Codex feature, override workspace rules, or guarantee that the research app’s interface will be recognized. You still need to verify the actual service’s access method, environment, data-handling terms, and suitability for your institution before moving any project material. Do not assume that remote access makes research data compliant or that a successful window test validates results.

Compared with a suitable local Mac, relying only on a Linux or Windows lab machine can leave you without the macOS interface needed for this particular GUI check, may require an institution-approved alternative environment, and can make it harder to reproduce the same desktop state. But remote access introduces its own constraints: network dependence, a separate environment to verify, and institutional rules about where data may be processed. For long-running work that needs stable physical access or specialized peripherals, renting may be less suitable than using an approved lab machine or owning the required hardware.

If you have completed the local permission and policy checks but lack a Mac for a non-sensitive acceptance test, review OSXFlow’s current Mac rental options and verify the real service details against your task before choosing. If the workflow involves restricted data, needs physical lab hardware, or requires an institutional approval you do not have, pause and use an approved environment instead.