Permissions, sandbox, network and keys

Back to the Codex learning hub

Goal and preparation

Complete CLI basics and configuration. Your request expresses intent, the sandbox limits technical capability and approval policy determines when further confirmation is required. Read them together: no prompts does not imply unrestricted writes, and read-only can still execute read operations.

Step 1: Create a minimal permission lab

Create codex-permissions-lab with note.txt and request.txt containing the separate samples below. These are fictional markers; no API keys, authentication files or production project are needed. In the integrated terminal, use PowerShell Get-Location or macOS/Linux pwd to confirm this folder before assessing the sandbox.

PERMISSION-LAB
Revision: 1

Only note.txt may be changed during the authorized write exercise.
Target revision: 2

Preserve original note.txt for restoration. Launch CLI with the command below for this session without changing account-wide defaults. Inspect /status and, if needed, the mode shown by /permissions. If your organization enforces different restrictions, retain the error summary and follow those rules instead of bypassing them.

codex --cd . --sandbox read-only --ask-for-approval on-request

Step 2: Read first, then inspect write restrictions

Send the read-only request below. Expect PERMISSION-LAB, Revision: 1 and request.txt's scope. Allowed reads need not prompt every time under on-request. Compare the actual reported directory and editor contents. Merely repeating the prompt without reading is not a successful check.

Read note.txt and request.txt in the current lab. Report the actual working directory and exact revision. Do not change files, access unrelated folders or use the network.

Next request the lab edit without escalation. Under these restrictions, expect no completed write: a limitation report or approval request may appear. Deny or cancel any prompt for this exercise, then verify note.txt remains 1 in your editor. A model saying it cannot write is not proof that an OS command was actually denied; record those separately.

Try to change only note.txt from Revision: 1 to Revision: 2 using currently available permissions. Do not request broader access, disable protections or retry through another path. If the current sandbox prevents the write, report that and stop. This is a controlled permission exercise.

If the file unexpectedly becomes 2, stop and inspect actual launch flags, mode and any approval that widened access before declaring sandbox failure. Restore 1 manually and retain minimal relevant evidence. A desktop task may use another host or worktree; check execution location before comparing files.

Step 3: Allow the required workspace edit

Use /exit to return to the shell, confirm the lab and launch a new session below. This permits workspace writes. Send the explicit edit request, expecting note.txt revision 2 with its first line and request.txt unchanged. No network or outside-workspace write is needed; inspect the reason for any additional request.

codex --cd . --sandbox workspace-write --ask-for-approval on-request

Read note.txt and request.txt. Change only the revision line in note.txt from 1 to 2. Keep all other contents and files unchanged. No network or outside-workspace access is needed. After editing, read both files again and report the actual result.

Recheck both files in the editor and record before/after values, scope, prompts and actual outcome. This exercise uses ordinary files, not protected .git, .agents or .codex paths. Workspace write does not imply every child path is writable. Follow feature-specific setup for skills or configuration instead of relocating protected paths to evade restrictions.

Distinguish refusal, enforcement and successful writing

Keep three outcomes separate: refusal before a tool call is no attempt; an enforced restriction reported by the tool with an unchanged file is evidence for that blocked attempt; a success message with Revision: 1 still on disk requires checking the path and result. Record only this ordinary-file exercise, not a guarantee for every tool, host or OS.

Requested action: [read / controlled write / scoped authorized write]
Observed host and absolute file path: [actual values]
Permission mode and approval policy: [observed / unavailable]
Tool attempt: [not attempted / command and actual result]
Approval event: [none / allowed / denied / cancelled / automatic review result]
Before and after: [actual note.txt revision and request.txt comparison]
Conclusion: [what this evidence establishes and what remains unverified]
Restoration: [actual result / not performed]

Network, credentials and approval are distinct

Built-in search, shell networking, MCP tools and account connections can have separate controls. Disabling web_search does not prove every tool is offline; opening a page does not prove npm install can reach a package registry. Identify the failing tool, host and domain before changing that layer. The lab file operations require no external connections.

Read the requested action and target path: reading a fixture, installing a chosen dependency and writing to an external service differ. One approval is not universal consent. If automatic review is active, record its decision and reason; no human dialog does not mean no review. never disables interactive approval requests, not the sandbox, so restricted actions may still fail.

For credentialed tools, use their official sign-in or secret configuration mechanism. Do not put keys in prompts, AGENTS.md, Git or screenshots. Check presence and authentication status without dumping all environment variables. If a real key was exposed, revoke and replace it at the issuing service, then remove exposed copies; deleting chat text alone does not invalidate the key.

Common failures, restoration and acceptance

Official guidance retires approval_policy = "untrusted". Do not copy it from older tutorials. It differs from trust_level in projects; do not globally replace both. Use configuration troubleshooting to identify the source, preserve the specific setting and choose a supported policy from current guidance.

Finish by explaining the two launches, recording the real revision 1-to-2 result and confirming request.txt is unchanged. Exit the write session, manually restore note.txt to 1 and inspect permissions in future tasks; exit does not undo files. Diagram 1 establishes scope, 2 observes execution, 3 verifies restoration. Platform sandbox behavior is documentation-checked, not claimed tested on all three OSes or executed for the reader.

Back to the Codex learning hub

Read the full description

Request to Permission to Action

• AI tools
• Tutorials
• Codex