Read permission modes as effective boundaries

Understand the approach

Permission controls answer different questions: where commands may act, when an operation needs review, and who reviews eligible requests. The sandbox defines technical file and network boundaries; approval policy determines when Codex asks; the selected reviewer can route eligible requests to a person or automatic review. These layers should be explained separately instead of reduced to a single safe or unsafe label.

The source lists Claude-specific mode names. Codex app and IDE use their current permission controls, while CLI documents /permissions and flags such as --sandbox and --ask-for-approval. Available choices and managed constraints can vary. A configuration field shown in documentation is not proof that it is active in this chat. Inspect effective settings and writable locations before diagnosing a blocked action.

Task authorization remains another boundary. A request to inspect code does not authorize modifying production, even if technical access is broad. Conversely, already-authorized routine work inside a suitable boundary should not require repeated unnecessary confirmation. Choose the smallest access that meets the actual task. If a check fails, identify the precise operation and missing capability rather than turning off restrictions globally.

Document the exception, not a permanent broadening

If an authorized task genuinely needs another directory, identify that directory and the minimum action before choosing a supported scoped mechanism. Record whether the exception is once, for a session, or persistent. A future task may not need it. Keep the validation evidence with the project so a later operator knows why access was required and does not mistake an old exception for a standing instruction to use every available resource.

Try it step by step

1. In the app select Ask for approval using the control below the composer; CLI users inspect /permissions and IDE users inspect their composer control.
2. Perform a small project-local edit in a generated project and inspect actual file/tool evidence under that selected environment.
3. For the deliberate OS boundary test launch a separate read-only CLI with never approval. Request a tiny scratch file and inspect actual denial or startup failure plus file absence.
4. Compare the result with workspace-write/on-request. Explain why never removes prompting and does not grant permission, and why a model refusal alone is not enforcement evidence.
5. End the probe and restore the app’s original mode. Keep technical boundaries distinct from the hook’s narrower lexical path policy.

A useful starting example

Illustration · adapt before use.

codex --sandbox read-only --ask-for-approval never

# In that session:
# Create permission-probe.txt in this scratch project; report the actual tool result.
# Do not escalate or substitute a different tool.

Check your result

• The client control/CLI flags describe the actually selected environment.
• An observed tool denial or unavailable sandbox is separated from an assistant refusal and expected policy.
• No broad-access workaround is used; the original mode is restored and scratch files are inspected.

Common mistakes

• Equating approval_policy never with read-only or treating no prompt as approval of the task.
• Changing global permissions to solve a path or runtime error that did not require broader access.