I would explain an agent’s permissions before praising its autonomy. If a task is supposed to fix one report, you should be able to point to the folder it can change and the services it can contact.
The useful mental model is a work area and a permission desk. The work area defines what is accessible; the desk defines which actions require a decision. They answer different questions.
Separate access from approval
A sandbox defines boundaries around operations such as filesystem writes and command execution. Approval policy determines when the agent can request or perform an action under the configured rules. The two interact, but they are not interchangeable.
For a fictional campaign report, read access to the source and write access to an output folder may be enough. A request to alter a system directory or contact a new service should have a concrete explanation tied to the task. The task itself does not become clearer merely because the environment becomes less restricted.
I would start by describing the required operations in ordinary language. Read this fixture. Create this report. Run this local check. That list gives you something useful to compare with the active permissions.
TipList needed operations before choosing a broader permission setting.
Inspect the effective session
In the Codex CLI, /status and /permissions help inspect the session and available controls. Check the working directory, sandbox or profile settings and relevant approval behavior. Managed workspace policy can limit which choices are available.
Do this in the environment where the task will actually run. A local session, a cloud environment and an unattended script can have different controls. A screenshot or remembered setting from last week is not evidence of the current run’s effective access.
For Cedar Metrics, confirm that the source file is in the intended project and that generated output stays in the agreed location. If a tool reports a permission error, read the operation and target path before deciding what to change.
TipCheck the target path in a blocked operation; an unexpected path can reveal a mistaken working directory.
Keep writes close to the task
A read-only inspection is a useful first step in an unfamiliar project. When the change is understood, a workspace-write setting can allow edits in the project while retaining boundaries elsewhere, subject to the environment’s effective policy.
For a report generator, that should support changing the implementation and creating an output artifact without touching unrelated folders. Ask the agent to preserve the source fixture and existing user changes. Instructions describe the intended behavior; the runtime boundary provides an additional control.
A broad filesystem grant is rarely the first fix for a path error. Check whether the project was opened correctly, whether the output path is appropriate and whether the required operation can stay inside the workspace. Often the smaller correction also makes the workflow easier to reproduce.
TipUse a new output path rather than overwriting the only copy of a source export.
Understand the separate network paths
Command-level network access governs traffic from executed commands in the relevant environment. Built-in web search and MCP or app connections are separate capabilities with their own configuration and permissions. Disabling one path does not automatically describe the state of every other path.
For example, a task may be able to search documentation while a shell command cannot download a package. A connected CRM tool may use its authenticated service connection rather than the same path as a local command. Diagnose the actual tool involved instead of assuming all internet access is one switch.
Current permission-profile documentation also distinguishes enabling network access from enabling a filtering proxy. Domain rules depend on the documented proxy configuration or managed setup; listing domains in a file should not be treated as proof that all traffic is filtered.
TipName the tool and destination when asking why network access failed or succeeded.
Use current configuration as a complete system
Codex configuration is evolving. The current documentation describes permission profiles with default_permissions and a permissions table, alongside older sandbox_mode settings and command flags. These systems have precedence and compatibility rules; copying fragments from different generations can produce a policy you did not intend.
For a beginner, I would use the supported permission controls in the client and inspect the resulting session. If you need configuration-as-code, follow one current official example for your environment and verify its effective behavior. Avoid assembling a policy from unrelated blog snippets.
The important check is operational: can the run read and write the intended paths, and does it handle a disallowed operation as expected? A syntactically valid configuration file is only the first step toward that answer.
TipWhen migrating configuration, remove obsolete assumptions and verify effective access in a fresh session.
Evaluate an approval request concretely
A useful approval request explains the operation, why the task needs it and what scope it affects. Read the proposed command or action and its destination. If it is unclear, ask for a narrower or better-explained operation before granting broader access.
For Cedar Metrics, installing a missing Python dependency might be relevant if the report requires it. Reading unrelated account folders would not follow from the same task. The decision should be tied to the deliverable, not to the assistant’s general confidence.
You can often resolve a block by changing the approach. A plain Markdown report may avoid an unnecessary document-generation dependency. A local fixture may support the first test without connecting a production service. Choose the smallest workable path that still produces the requested result.
TipAsk what specific part of the task cannot be completed under the current boundary.
Treat unattended execution as its own design
A scheduled run may have no person present to answer a prompt. Decide in advance which actions it may complete and what happens when it reaches an operation requiring approval. Do not assume the same interactive flow will simply work in the background.
For recurring reports, a useful first design creates a draft and reports missing access. External messages and record updates need explicit scope, destination and duplicate handling. Depending on the configured policy, authorized actions can run without another confirmation, so the stored task and controls deserve inspection.
I would test the unattended version with harmless inputs and review its logs before relying on it. A manual success proves the procedure under one set of conditions; it does not establish the behavior of a different execution environment.
TipTest the failure path where a required source or permission is unavailable.
Where permission decisions go wrong
The first mistake is treating every block as friction to remove. Sometimes it exposes the wrong folder, an unnecessary dependency or an unexpectedly broad task. The second is assuming prose instructions enforce a technical boundary. Use instructions and runtime controls for their respective jobs.
A third mistake is trusting an old configuration example after the policy system changes. Keep a link to the current documentation with any maintained configuration and recheck effective behavior after significant upgrades or workspace policy changes.
A good permission setup is one you can explain alongside the task. For the campaign report, that explanation should fit in a few sentences. What is the narrowest set of files and actions your next workflow actually needs?
How to set it up
List required operations
Identify source reads, output writes, commands and external services for the task.
Inspect the session
Use supported status and permission controls to confirm the environment, working directory and effective policy.
Run a bounded exercise
Generate a report from the fictional fixture and inspect any blocked operation before expanding access.
Verify failure behavior
Test missing access or an unavailable source and confirm that the task reports the limitation clearly.
Frequently asked questions
Are sandbox and approvals the same?
No. The sandbox defines access boundaries; approval policy controls when decisions are required under the configured rules.
Should I disable restrictions when a command fails?
First inspect the command, target path and task requirement. A narrower correction may solve the problem.
Does blocking shell networking disable web search?
Not necessarily. Command networking, web search and connected tools have separate controls.
Do domain rules automatically filter all traffic?
No. Filtering depends on the documented proxy or managed configuration and does not describe every tool access path.
Can I mix old sandbox settings with new profiles?
Follow current precedence and compatibility guidance. Do not assume fragments from both systems compose as intended.
Does AGENTS.md enforce permissions?
No. It provides instructions; runtime access controls are separate.
Will an unattended task always ask before a write?
No universal guarantee applies. Inspect its effective policy and define permitted actions before scheduling.
What is the first thing to check after an error?
The actual operation, target path, environment and active policy.
Sources & further reading
ChatGPT and Codex change quickly. This page was last reviewed September 22, 2026; verify time-sensitive details against the official docs above before relying on them.