Codex permission mode is unavailable: what to check when Send fails

When Codex says Unable to send message — Permission mode is unavailable, first check whether your message was accepted into the conversation at all. If it remains in the composer and no turn starts, investigate task configuration and the selected permission mode before troubleshooting model output or changing API credentials. Do not assume the error is an instruction to grant Full Access.

This guide covers the desktop submission problem, not a website approval prompt or a custom Computer Use API error. The evidence was checked on October 21, 2026. We reviewed official permission documentation and public reports, including a report containing the exact message. We have not independently reproduced the defect, established a universal cause or verified a release that fixes it.

Separate three failures that can look alike

The point at which a message stops is more useful than the word “permission” alone.

A queued follow-up is another possibility. If the previous turn is still running, a pending message is not by itself evidence of this fault. Wait for the turn to finish or use a normal visible stop control when appropriate; then record whether the next message can be submitted. Do not click repeatedly when the request could trigger an external action.

Use the stream-disconnection guide for accepted replies that disconnect. Use the Computer Use permission guide when a task has already started and a particular app or website is denied.

What the public evidence supports

A follow-up on issue #21167 reports the exact permission-mode message on macOS desktop build 26.814.41957. The reporter says configuration and permission RPCs could succeed while the renderer later lost the active permission state needed by the composer. This is a reporter’s interpretation of their logs, not a maintainer-confirmed root cause for all users.

The useful distinction is that a reachable configuration endpoint and an unavailable mode in one window can coexist. It is therefore premature to diagnose every occurrence as a network outage, insufficient subscription or deliberate administrator block.

A separate Windows report, issue #47216, describes a completed first turn followed by a second message that remains in the composer. Its reported runtime state includes a local-configuration loading block. The issue also discusses a permission-mode branch in the reporter’s code analysis, but its observed loading state is not proof that every instance displays the exact same error.

That Windows report concerns package 26.915.4065.0, internal app version 26.915.31945. It includes intermittent results and a proposed internal explanation. We use it to explain why “button looks clickable” is not a sufficient submission test. We do not present its process-killing or application-bundle experiments as supported recovery instructions.

Both issues were open when checked. Their age and version specificity matter: they establish that these symptoms have been reported, not that your installed release necessarily has the same defect.

Start with a harmless two-message test

Save any unsent work outside the composer first. Record app/build, operating system, local or remote execution environment, personal or managed workspace, the visible mode label and the exact error. Avoid including a private workspace name in a public report.

In the affected task, wait until no response is running. Use this text-only request:

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

If it completes, send the equivalent request for OK2. Record whether each message entered the history and whether each reply finished. If the first submission is blocked, stop there; do not manufacture a second-turn failure.

Now make one comparison in a fresh task using the same intended environment and workspace. Do not silently compare a local task with a cloud task and treat the results as equivalent. If your work uses a remote connection, note its state instead of assuming your local folder is the active environment.

A fresh task working while an old task fails narrows the investigation to a difference in task state. It does not prove that the workspace policy is wrong or that old conversations should be deleted. Preserve the affected task for diagnosis.

Check available configuration without broadening access

Inspect the normal task controls and settings exposed in your installed app. Is the intended execution environment available? Does configuration finish loading? Does the permission control show an available mode, a loading state or an explanatory restriction? Record what is actually visible rather than applying a screenshot from a different release.

The managed configuration documentation distinguishes enforced requirements from defaults that users can change. If a mode is intentionally unavailable under managed policy, a local setting cannot override that requirement. Ask the administrator to confirm the intended policy; do not treat it as a client defect simply because another workspace offers different choices.

If the normal UI offers an already-authorized mode appropriate to a harmless test, select only that intended mode and repeat the test once. Do not broaden file, network or application access merely to make the error disappear. If no appropriate mode is selectable, preserve the state and continue with restart/update diagnosis or support.

Computer Use operating-system permissions serve another purpose: allowing the tool to see or interact with a native app. A message that cannot start a turn has not yet demonstrated a Screen Recording, Accessibility or target-app problem. Repeatedly changing those controls adds variables without establishing a connection to the submission error.

Recover once, then check whether it stays recovered

After saving unsent text, fully quit and reopen the desktop app. Reopen the intended workspace, allow normal initialization to finish, and repeat the same two-message test. If the app visibly remains stuck loading, record that state; this guide does not define an arbitrary waiting time as proof of a deadlock.

Check the normal app updater. If an eligible update is installed, record old and new versions and repeat the test. We have not identified a confirmed fix version, so “update and retest” is a diagnostic step, not a promised repair. Do not replace the bundled runtime, patch an application archive or kill renderer processes based on a public issue’s experiment.

If a different explicit error appears, follow that error’s branch. Workspace settings could not load and background-server feature settings are incompatible have separate guides. Keep both messages in your record rather than assuming the second one proves the first diagnosis.

Stop repeating resets if the same submission block returns. A successful first reply followed by another blocked second message is a recurrence, not a successful fix. Avoid deleting the entire configuration directory: it can remove useful evidence and unrelated working settings without addressing the actual condition.

Prepare a useful support report

A minimal report should distinguish the submission stage from model and tool behavior:

Exact message: Unable to send message — Permission mode is unavailable
App version/build and operating system:
Date/time and timezone:
Execution environment: local / remote / cloud, as shown in the app
Workspace: personal / managed
Visible permission mode or loading state:
Was a previous turn still running?
Did the failed message appear in conversation history?
First-message result / second-message result:
New task, same environment result:
Normal restart result:
Update versions and result, if tested:
Relevant administrator restriction, if confirmed:
Redacted screenshot or short log excerpt:

Supply logs through the normal reporting mechanism available in your app version. Retain timestamps, error text and the order of events; remove tokens, cookies, private paths and unrelated conversations before sharing publicly. Do not expose debugging ports or attach remote-debugging tools just to reproduce the internal analysis in an issue.

Recovery is established for your immediate task when the intended mode accepts a message, completes its reply and accepts a subsequent message after the first turn ends. If your next step needs browser or computer control, verify one authorized read-only action separately. That action may still require its own approval even after the composer works again.