Codex network permission was revoked: diagnose a task that will not start

If Codex displays Fatal error: application network permission was revoked, first establish whether the message appears before a task starts or after a specific website or application action. A failed first reply in a new task needs a different investigation from a denied website request inside a running task. Record the exact message, preserve your unsent prompt and compare one harmless request in a new task and an existing task before changing settings.

There is no universal repair established by the sources reviewed for this article. This is a diagnostic guide for the desktop experience used with Codex and ChatGPT Work, checked on October 21, 2026. It is not a guide to bypassing an intentional network restriction or debugging a custom Computer Use API implementation. We reviewed official documentation and public reports; we did not reproduce the Windows defect or verify a fixed release.

What the reported failure actually looks like

In OpenAI repository issue #54726, a Windows user reports the exact error after updating to desktop version 26.1013.3656.0. A new conversation in Work or Codex mode repeatedly reconnects when given a short greeting. The same report says ordinary chat, browser chat/work and existing Work conversations can still respond. Those are the reporter’s observations on that installation, not a compatibility guarantee for every account.

A second report, issue #54495, describes desktop version 26.1007.71326 becoming slow or unresponsive and records the same error in an earlier conversation. That reporter explicitly does not establish whether the error explains the later delays. Moving to another conversation, restarting and rebooting did not provide lasting recovery in that report.

Both issues were open when checked. An automated duplicate suggestion between them is not a maintainer-confirmed diagnosis. Together they justify checking the task lifecycle; they do not prove that a VPN, DNS setting, subscription tier or browser extension causes the failure.

Preserve the failure before retrying

Copy the unsent text into a local note. Record the app version from its About screen, operating system, task mode, selected workspace and time with timezone. Keep the exact error text, not just “network problem.” Note whether the message appeared in the conversation history, whether a reply began, and whether a tool had already run.

This matters when the original request could send a message, save a file or submit a form. A missing response is not proof that the action did not happen. Inspect its actual destination before rerunning it. For diagnosis, use a text-only request such as:

Reply only with OK. Do not use tools, browse websites, read files,
change settings, or send anything outside this conversation.

This request tests basic submission and response. It does not validate browser control, file access or a production workflow. Keep those tests separate so you know which stage recovered.

Compare four paths with the same small request

Run the comparison only in environments you already have access to. Do not create another account, change organizations or disable a restriction to make the results match.

1. In the affected task, submit the harmless request once if it is safe to do so. Record the result rather than repeatedly clicking Send.
2. Open one new task with the same intended mode and workspace. Use the same request.
3. If an existing task in that workspace is available, test it without resuming any unfinished external action.
4. If ordinary chat or the browser version is already available to you, use the same text-only request there and record it as a separate environment.

Use this worksheet:

If only new tasks fail, report that specific split. If every path fails, the comparison has not isolated a task-start problem: check the normal service/network situation and retain each error. If only one website fails after a task has started, use the Computer Use permission guide instead of treating it as this startup failure.

Check the permission layer that matches the evidence

The official Computer Use guide distinguishes operating-system access from permission to operate a target app. On macOS, Screen Recording and Accessibility relate to seeing and interacting with native applications. Toggling them is not a demonstrated repair for a Windows task that cannot answer a text greeting.

The managed configuration documentation also distinguishes policy-controlled capabilities and network rules. If your device or workspace is managed, ask its administrator whether the relevant action is intentionally restricted and provide the exact time and target. A local allow setting cannot relax a managed denial.

For a personal installation, inspect the normal app settings that are actually available in your build. Record a disabled control or explanatory message; do not infer that a missing control means you need a different paid plan. Avoid copying another user’s internal permission files. The same visible symptom can occur under different policy and session states.

A working browser connection is useful evidence, but it does not authorize or validate a separate desktop task. Conversely, a website denial should not be “fixed” by moving the same blocked action to another tool.

Try a bounded recovery sequence

After preserving work and evidence, fully quit and reopen the desktop application once. Retest the same harmless request in the same intended workspace, then compare a new task. Record whether recovery survives another task rather than calling one successful reply a permanent fix.

Check for an update through the application’s normal update mechanism. If an update is offered and installed, record both versions and repeat the same comparison. This is a reasonable recovery check, not evidence that any particular current release fixes these reports. Do not install an older build from an unofficial source or change several settings simultaneously.

If a sign-in or workspace error appears instead, follow that specific branch. Our workspace-settings troubleshooting article covers failures loading workspace settings. A reply that starts and then disconnects belongs to the stream-disconnection investigation. Keep the first and subsequent errors together; a changed message can identify a different failure stage.

Stop after one controlled restart/update comparison if the same error returns. Repeated reinstalls, deleting the configuration directory, editing app approval records or disabling security controls are not supported fixes established here. The second public report is a reminder that repeated restarts can consume time without providing durable recovery.

Send a report that preserves the useful differences

Use the application’s normal support/reporting path available in your version. Keep private identifiers in the appropriate private support channel, not in a public issue. A useful report can be short:

App version and build:
Operating system:
Observed date/time and timezone:
Mode and workspace type (personal/managed; no private workspace name):
Exact error: Fatal error: application network permission was revoked
Failure stage: before first reply / after reply starts / after tool action
New task result:
Existing task result:
Ordinary chat or browser result:
Restart result and whether the problem recurred:
Update before/after versions, if applicable:
Any intentional administrator restriction confirmed:
Redacted screenshot or short log excerpt, if available:

Remove API keys, cookies, authorization headers, private file paths and unrelated conversation content. Preserve error names, app versions, timestamps and the order of events. Those details help distinguish task initialization from general slowness without exposing your work.

A successful recovery means the original task mode accepts a new harmless message and completes a reply. Only then test one authorized, read-only tool action if your work needs Computer Use. A normal chat response is not proof that tool access recovered. If that second test fails, keep it as a separate result and use the matching permission or connection guide.