When a coding agent can make changes, permission design becomes part of software engineering. A statement such as “human in the loop” is too vague: the actual policy must define what action is being approved, in what environment, for how long, and how reviewers can see what happened.
What the tool actually does
Classify actions into read-only repository inspection, source modifications, local command execution, network access, credential use and external actions such as opening pull requests or deployments. GitHub distinguishes interactive agents from delegated cloud agents; Anthropic and OpenAI describe separate technical sandbox and approval boundaries. The levels are not directly interchangeable between vendors.
A practical workflow and what to verify
Use a four-step task escalation. First, ask for a read-only diagnosis in a throwaway worktree. Second, approve a limited patch touching enumerated files. Third, allow a predefined test command in an isolated environment. Fourth, require a human change review before any PR merge or deployment. Keep an explicit record of which approval allowed each step.
Limits and failure modes
Disabling permission prompts does not establish a sandbox, and a sandbox may still permit harmful writes within its allowed path. A command that seems harmless may invoke package scripts or reveal data via logs. Working-directory restrictions alone do not necessarily control network access or secrets visible through inherited environment variables.
Data governance, approvals and security
Apply allowlists for tools, deny unexpected hosts and mount no production credentials. Independent filesystem permissions and CI checks should enforce policy even when the agent misinterprets instructions. Test the negative case by asking the agent to write outside its intended area and verifying that the environment refuses.
Who should use it—and alternatives
Select an interaction mode by task risk: autocomplete for low-blast-radius edits, approval-first IDE/CLI for focused refactors, and isolated delegated agents for known acceptance-tested tickets. Treat vendor promises of “safe commands” as a control requiring independent evaluation.
Documented scope and evidence date
This article reports the development workflow documented in the linked first-party sources accessed on 25 October 2026. It is not a hands-on product test or an independent performance claim. Client behavior, account entitlements and supported countries can differ across releases. Exact per-seat charges, quotas, trial allowances, API-model versions, and deployment guarantees are intentionally not supplied without a dated, tier-specific verification. For engineering procurement, capture the installed client version and active contract as separate evidence.
Acceptance checklist before production
- Check the exact editor, extension or CLI version in the actual installation, and the applicable sign-in or admin policy.
- Give the task a clear behavioral acceptance criterion and specify files, branches, credentials and networks outside its permitted scope.
- Use a disposable branch/worktree and preserve the baseline; do not rely on an agent summary as proof of test execution.
- Review the diff, new packages, build scripts and CI configuration, then rerun targeted and regression tests in a trusted environment.
- Require normal peer review and release approvals; keep a record of external code/context processors before using confidential repositories.
Sources & Further Reading
- https://code.claude.com/docs/en/permissions (official publisher documentation; accessed 25 October 2026)
- https://openai.com/index/running-codex-safely/ (official publisher documentation; accessed 25 October 2026)
- https://docs.github.com/en/copilot/concepts/agent-capabilities/about-agents/about-github-copilot-agents (official publisher documentation; accessed 25 October 2026)