Codex Computer Use Not Working After Permission Is Granted

If Codex Computer Use still fails after you grant permission, first record the exact error and identify whether the failure is in a website, a native app or a shell command. For a browser connection problem, try the same small, authorized task in a new chat, then restart the relevant browser or desktop app if needed. Check the plugin connection before repeatedly changing permissions.

This guide covers the desktop experience used with Codex and ChatGPT Work. Searching for “GPT computer use permissions” can also surface API tutorials; this article does not diagnose a custom Computer Use API integration.

Evidence checked September 21, 2026: official setup and troubleshooting documents, original GitHub reports and first-person community discussions. We have not independently reproduced the cited failures. A successful workaround on one machine does not establish a universal root cause or a fixed release.

Start with the error, not another permission toggle

Use this table to choose the next check. It is a diagnostic sequence, not a list of confirmed causes for every installation.

Save the first error before trying a fix. If a restart changes “browser unavailable” into an app-specific approval prompt, that is progress to a different stage, not necessarily the same failure repeating.

Why “Always allow” is not the whole permission system

OpenAI distinguishes OS permissions, app approvals and the sandbox used for files and shell commands. On macOS, Screen Recording lets Computer Use see apps, while Accessibility permits interaction. On Windows, the target app must be visible on the active desktop. Confirm the Computer Use plugin’s server and skill are enabled. These are separate checks in the official Computer Use guide.

Website access has its own controls. The desktop built-in browser also uses a profile separate from your regular browser; being signed into Chrome does not establish the same login inside it. See the desktop browser documentation.

For managed devices, an allow rule cannot install a plugin or grant an OS permission, and local settings cannot relax a managed deny. Browser origin rules can distinguish protocol, host and port. Check the actual destination after a redirect instead of assuming every subdomain shares one rule. These details are documented under managed browser and Computer Use controls.

Fix 1: compare a new chat with the failing one

OpenAI’s browser extension troubleshooting steps explicitly recommend a new chat to clear chat-specific connection state. This is especially useful when one existing task fails while the browser appears connected.

Before switching, preserve a short handoff: what is complete, what remains, the exact approved destination and the error. Keep the old conversation. In a fresh local chat, choose the same browser and request one read-only action:

Use the browser I selected to open the public page at [exact approved URL].
Report its page title. Do not sign in, upload, submit or change anything.
If access fails, report the exact tool error and stop.

This is an example diagnostic prompt, not an automated test result. If there was an intentional denial, change the decision through the appropriate user or administrator controls first. A new chat must not be used to evade that decision.

A particularly relevant September 13 GitHub report, #45237, describes a website allowed globally but blocked by a conversation-specific record after a prompt was apparently declined without visible user input. Its author reports recovery with a new conversation. The issue remained open when checked; the proposed mechanism is the reporter’s analysis, not a confirmed diagnosis for your machine.

A clean chat working while the old one fails narrows the investigation toward chat-specific state. It does not prove that permission files were corrupted. Keep both outcomes for support rather than deleting the evidence.

Fix 2: restart the component that cannot connect

First check for desktop app updates. If multiple ChatGPT or Codex desktop installations are present, identify which one you are running and update each installation you keep. Save unsaved work and stop active operations before restarting. Then change one component at a time and repeat the same read-only request:

1. For an external browser connection, fully quit and reopen that browser.
2. Confirm the extension is enabled in the browser profile you actually selected.
3. If the problem remains, fully quit and reopen the ChatGPT/Codex desktop app. Closing its window alone may leave it running.
4. Recheck the selected browser and test again before resuming the larger task.

These checks draw on the official extension guidance; the sequence here separates changes so you can compare their effects. Restarting the whole computer is a later option when a normal application restart does not clear the startup failure; it is not a requirement for every permission change.

An app restart and a fresh chat test different things. The first restarts the application; the second creates a new conversation. Reopening the old conversation after restarting is not the same experiment as starting a fresh one.

Fix 3: check the plugin and extension before reinstalling

In Settings → Computer Use, inspect the selected browser. Current official instructions use Manage to indicate the setup is connected; Install leads back through setup. The browser toggle controls whether it appears in the mention menu. Website permissions are managed separately.

Check the Computer Use plugin itself as well. If your version offers disable/enable or reload controls, use the normal UI, wait for its status to settle, and retest. Treat this as a recovery attempt, not proof of a particular cache bug.

If the browser extension still cannot connect, the official troubleshooting page recommends reinstalling it through the desktop settings. Reinstalling a browser extension is different from reinstalling the desktop application or deleting the Codex data directory. Record which action you actually took.

Do not copy internal runtime reset commands from an unrelated client into Codex. Third-party wrappers can expose similarly named tools with different startup and permission behavior.

Fix 4: follow the operating-system branch

macOS: check both visibility and control

Review System Settings → Privacy & Security → Screen Recording and Accessibility for the relevant Codex Computer Use entry. The exact label can vary with the installed version. Follow any system request to quit and reopen the affected component after changing permission.

To separate browser trouble from native app trouble, manually open Calculator, then ask Computer Use only to read its display. If that works but the selected browser does not, investigate the browser connection. If neither works, retain both errors before deciding it is an OS permission problem.

This comparison is a proposed diagnostic procedure. We did not independently reproduce these failures on a Mac.

Windows: distinguish foreground access from helper launch

Keep the intended application visible in the active, unlocked desktop session. A minimized or unavailable target is different from a helper that never starts.

Issue #37415 reports spawn EPERM before normal app interaction. One follow-up reports success with desktop build 26.803.10989.0 and plugin 26.803.81509 after resetting its runtime under managed permissions. Other reports describe different results. This is version-specific evidence to include in a support report, not a recommendation to install an old build or disable the sandbox.

Issue #25220 documents another family: bundled plugins unavailable with WindowsApps copy/install errors. Commenters report conflicting outcomes from reinstalling, including differing results after changing the Store installation drive. Reinstalling therefore cannot be presented as a confirmed universal solution.

If the error names the app server, use the separate Windows app-server troubleshooting guide. If it says resources could not load, follow the Codex resource-loading checklist rather than treating every startup failure as website permission denial.

What counts as a successful fix?

Use the same target and same read-only request after each change. Record a small matrix:

If a failed operation could already have saved, sent or published something, inspect its actual state before repeating it. A missing response does not establish that the action never happened. For connection interruptions, our stream-disconnected guide covers a related but separate symptom.

When none of these checks helps, stop repeating resets. Send a concise report through the app’s feedback flow with OS version, desktop build, plugin version, exact error, target type and the old/new-chat comparison. OpenAI’s troubleshooting reference lists log locations and explains how to share a session. Review logs for secrets and private content first.

Frequently asked questions

Is this a GPT model failure?

Not necessarily. A plugin that cannot start or a browser that cannot connect fails at a different stage from the model selecting an action. Changing the model is not a demonstrated repair for the errors covered here.

Should I switch to Full access?

Not as a default repair. Determine which permission or component failed. Broader file and command permissions do not demonstrate that a browser connection or OS permission has been fixed.

Can Ofox API access repair Computer Use permissions?

No evidence reviewed here supports that claim. API model access and the desktop application’s permission and connection state are separate concerns. Use the recovery path for the component named in the error.

Why not delete .codex and start over?

OpenAI documents session transcripts under that directory by default. Deleting it is a broad reset with consequences for stored state. Preserve evidence and use targeted, support-guided recovery instead of making it the first step.