AI Coding Agent Approval Workflows: What, Where and Who Approves

An approval workflow for an AI coding agent decides which actions need a human yes, where that yes happens and who gives it. Most teams settle on three checkpoints: risky actions approved in the session, the diff approved in review by someone other than the person who asked, and automated checks at the merge gate.

This guide breaks that down. It sorts agent actions by risk, maps where approvals can live, suggests who should own each one, and lists what Claude Code, Codex, GitHub Copilot cloud agent, Gemini CLI, Cline, goose and Qwen Code say in their own docs. Then it shows how Safeguard handles approvals in the CLI, in Search on your computer and in the browser extension.

If you are thinking of switching tools, you do not have to give up what you already pay for. Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. You can also connect Claude or ChatGPT to the Safeguard MCP server and use Safeguard from the chat you already use.

What to approve: sort agent actions by risk

Asking a human about every small agent action wears people down, and tired people approve without reading. Sort actions by what they can break and spend attention where it counts.

Three principles sit behind that table.

Reversibility. A file edit inside a git repository can be undone. A package published, a message sent or a form submitted cannot. The less reversible the action, the closer to a human it belongs.

Reach. An edit to one file touches one project. A command run with your credentials reaches everything they can. Wider reach means more approval.

Supply chain. A one line manifest change can pull in dozens of transitive packages. The diff will not tell you whether any carry a known vulnerability. A scan will.

Where approvals happen

Approvals can live in several places. Use more than one, because each catches different problems.

In the session

The prompt in the terminal, IDE or browser before the agent acts. It is the only checkpoint that stops an action before it happens, and it depends entirely on the attention of the person at the keyboard.

In the configuration

Most agents let you write rules ahead of time: allow this command, deny that one, keep network access off. Rules do not get tired, but they cannot judge context. Use them for what you never want and the routine things you always allow.

In isolation

A container, VM or sandbox limits what an action can reach. Isolation does not replace approval; it limits the cost of a bad one.

In review

The pull request is where a second person, who neither asked for the change nor watched it being written, sees it.

At the merge gate

Automated checks run on every pull request whatever produced it: tests, vulnerability scans, licence checks, policies. Put the rules you cannot afford to skip here, because they apply whatever mode the agent ran in.

After the fact

Logs and audit trails prevent nothing, but they tell you what happened.

Who approves

The person who asked the agent to do something is the worst placed to be its only reviewer. They know what they wanted, so they see what they expected. GitHub built this into Copilot cloud agent: its docs say the feature "prevents the user who asked Copilot cloud agent to create a pull request from approving it." The same idea works for any agent.

Two rules make this work. The developer says in the pull request which agent and mode produced the change, so the reviewer knows how much was seen before it was written. And policy exceptions go to a named owner, not whoever is online.

How common coding agents handle approvals

Every fact below comes from the tool's own docs or repository, linked in Sources. The goal is to show the range of designs, not to rank them.

Claude Code

Anthropic's docs list six permission modes: Manual (config value default, where only reads run without asking), acceptEdits, plan, auto (where a second model, the classifier, reviews actions instead of you), dontAsk (only pre-approved tools run; anything that would prompt is denied) and bypassPermissions, which the docs mark "Isolated containers and VMs only." With v2.1.283 or later, auto is the starting mode for interactive terminal and VS Code sessions. Deny rules block in every mode, including bypassPermissions, and an organisation can block bypass mode with permissions.disableBypassPermissionsMode in managed settings. For CI, the docs show an exact allowlist:

claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"

OpenAI Codex

Codex is Apache-2.0 and its repository describes it as a "lightweight coding agent that runs in your terminal." You sign in with ChatGPT on a Plus, Pro, Business, Edu or Enterprise plan, or with an API key. Approvals combine a sandbox mode (read-only, workspace-write, danger-full-access) with an approval policy (on-request, never or granular). Version-controlled folders get the Auto preset, which is workspace-write with on-request. The docs say "By default, the agent runs with network access turned off," and that destructive app or MCP tool calls always require approval when the tool carries a destructive annotation. Managed configuration lets admins restrict settings such as allowed_approval_policies.

GitHub Copilot cloud agent

Copilot cloud agent works on GitHub rather than your machine, so its approvals sit in the repository. The docs say only users with write access can trigger it, it can only push to its own copilot/ branch, and it "cannot mark its pull requests as Ready for review and cannot approve or merge a pull request." The requester cannot approve the pull request it creates. By default, workflows do not run until "a user with write access to the repository clicks the Approve and run workflows button." The docs also describe CodeQL, Advisory Database and secret scanning checks on generated code, and a firewall that restricts the agent's internet access.

Gemini CLI

Gemini CLI is Apache-2.0. Its configuration reference says "default prompts for approval, auto_edit auto-approves edit tools, and plan is read-only mode," with default as the default. YOLO "can only be enabled via command line," and security.disableYoloMode disables it even if a flag asks for it. Folder trust can be turned on, and GEMINI_CLI_TRUST_WORKSPACE bypasses the check for a session. The repository notes that for unpaid tier and Google One users, Gemini CLI was replaced by Antigravity CLI on 18 June 2026.

Cline

Cline is Apache 2.0 and runs as an SDK, IDE extension or CLI. Without Auto Approve, it prompts before each action. Its docs split auto-approval into categories (read project files, read all files, edit project files, edit all files, safe commands, all commands, browser, MCP) and recommend enabling only "Read project files" and leaving the rest off "until you have a specific reason." YOLO Mode approves everything, and the docs warn it "disables all safety checks."

goose

goose is Apache-2.0. Its docs list four modes: Completely Autonomous, Manual Approval, Smart Approval (auto-approves low-risk actions and flags others) and Chat Only. The docs say Autonomous mode is applied by default, so set the mode before the first task.

Qwen Code

Qwen Code is Apache-2.0. Its approval modes run from Plan (read-only) through Ask Permissions, Auto-Edit and Auto (an LLM classifier evaluates shell commands, network calls and out-of-workspace edits) to YOLO. Shift+Tab cycles them, and tools.approvalMode in .qwen/settings.json sets a project default. The docs page names both Auto and Ask Permissions as the starting mode, so check the mode bar on first run.

Side by side

Every tool has a careful mode, a middle mode and an approve-everything mode, and the vendors that publish guidance tie the permissive mode to isolation. The controls that cannot be talked out of live in configuration, review and the merge gate.

Safeguard's approach: the CLI, Search on your computer and the browser

The Safeguard CLI and the browser extension use the same three approval modes: Ask, Auto and Yolo. Ask prompts before every action. Auto approves known actions and asks about anything new, and it is the default. Yolo approves everything. Policies and gates are evaluated in the platform, not the client.

In the CLI

The Safeguard CLI scans code, container images and SBOMs on your own machine, sends only the results to the platform, and includes an assistant that writes code and fixes what it finds. The assistant has tools for your local files and for your Safeguard data. It can find and read files, edit code and run commands, with your approval. The docs say: "Some tools change things: writing a file, editing code, running a command. Those ask before they act. /permissions chooses how often." The current mode is always shown in the bar under the input.

Install it on macOS and Linux:

curl -fsSL https://cli.safeguard.sh/install | bash

On Windows, in PowerShell:

irm https://cli.safeguard.sh/install.ps1 | iex

It is a single static binary with no Node, Python or JVM needed, on x86_64 or arm64 (Windows is x86_64 only). Then start a session:

safeguard
/login
/permissions          # choose Ask, Auto or Yolo
/scan .
fix the lodash CVE in this repo

Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. /model shows or switches the model; see the CLI docs for connecting one. @ attaches a file from the folder you started in, and /resume picks up the last session there.

For CI, safeguard exec runs one non-interactive assistant turn:

safeguard exec "summarise the critical findings in this repository"

No one is at the keyboard in CI, so give exec prompts that read and report, and keep code changes in sessions a person can approve. Pair it with a scan:

safeguard scan --dir .

That builds an SBOM and matches it against vulnerability databases, writing vuln.json, license.json and other files under ./output. When the local runner runs platform scan jobs, your source code never leaves the machine; only SBOMs and findings are uploaded. Our post on checking what a coding agent changed walks through a before and after scan.

In Search on your computer

You can also start the work from Safeguard Search and have it carried out by the CLI on your machine. This demo shows it: attach a computer running the Safeguard CLI and a folder, ask for a fix, review the diff and approve the command before it runs. The demo notes that computer work from Search is available and expanding.

Click through it at your own pace, or open it full screen.

In the browser extension

Browser actions have the hardest side effects to undo, so this is where approvals matter most. With the Safeguard Chrome extension, Search works in a browser tab you hand it, step by step. You set Ask, Auto or Yolo. It stops and asks before a risky step such as submitting a form, with Allow once or Don't allow, and every step is kept on record. Browser control must be enabled for the workspace, so an admin decides whether it is available at all.

Click through it at your own pace, or open it full screen.

The extension, version 1.0.4 on the download page, installs from the Chrome Web Store for Chrome, Brave, Arc, Vivaldi, Opera and Edge, from Firefox Add-ons, and in Safari on iPhone and iPad inside the iOS app. Safari on Mac is in Apple review.

In the platform

Policies and gates, reachability analysis, SBOM and dependency scanning and MCP Guardrail run in the Safeguard platform. Autonomous remediation can open fix PRs; it is off by default, and its PRs go through normal review. That gives you a merge gate that applies whatever mode anyone chose.

The same platform also runs in the desktop app for Windows, macOS and Linux, the iOS and Android apps, IDE extensions and cloud options such as a cloud sandbox tenant, free for seven days with no card. See the download page.

Design your team's workflow, step by step

A sequence you can run in an afternoon:

1. List the agents in use, including IDE extensions and browser agents.
2. Take a baseline. Run safeguard scan --dir . on your main repositories and keep the vuln.json files. You now know your starting risk.
3. Write the action table. Start from the table at the top of this guide and adjust it for your systems. Mark which actions are always allowed, always asked and never allowed from an agent.
4. Set modes by repository tier. Production, payments, auth and infrastructure repositories use the most careful mode (Ask in Safeguard, Manual in Claude Code, read-only or on-request in Codex, Ask Permissions in Qwen Code). Other repositories can use the middle mode.
5. Block the permissive mode where the vendor lets you. Claude Code's managed settings, Gemini CLI's security.disableYoloMode and Codex's managed configuration are examples from their docs.
6. Reserve the permissive mode for isolation. Containers, VMs, throwaway clones and the Safeguard cloud sandbox. Write that down.
7. Require a second reviewer. The requester does not approve their own agent's pull request. Branch protection with required approvals enforces it.
8. Put scans and policies at the merge gate. Every pull request gets a vulnerability scan and policy evaluation, whatever produced it.
9. Keep CI agents to read and report. safeguard exec with a summarising prompt, Claude Code with dontAsk and an exact allowlist, or the equivalent in your tool.
10. Review monthly. Look at what got declined, what got through and what scans found, then adjust the table.

Common mistakes

• Approving everything to make prompts stop. If people do this, the prompts are too frequent. Move routine actions into allow rules and keep prompts for the ones that matter.
• Assuming defaults match across tools. Cline prompts before each action by default; goose runs autonomously by default. Check each tool on first run.
• Letting the requester approve. They are the person least likely to spot a surprise.
• Reviewing only the diff on dependency changes. Scan the result. A diff shows lines, not vulnerabilities.
• Giving CI agents write tasks with no human in the loop. Keep non-interactive runs to reading and reporting unless the change still goes through review.
• Ignoring browser agents. Submitting a form is harder to undo than editing a file. Ask every time.
• Connecting a subscription against its terms. OpenCode's providers docs say there are plugins to use Claude Pro or Max models in OpenCode and that "Anthropic explicitly prohibits this." Read your provider's terms first.

For more on picking tools, see our comparison of AI coding agents and our post on the Safeguard CLI as a security-aware coding assistant.

FAQ

What should an AI coding agent always ask about?

Anything hard to undo or with wide reach: shell commands outside a read-only set, package installs, network access, git push, edits outside the project, and browser actions such as submitting a form. Deploys and infrastructure changes should go through your normal release process, not an agent session.

Who should approve an agent's pull request?

Someone other than the person who asked for it. GitHub applies this to Copilot cloud agent by preventing the requester from approving the pull request it creates.

How does Safeguard handle approvals?

The CLI and the Chrome extension use Ask, Auto and Yolo, with Auto as the CLI default. In the CLI, tools that write files, edit code or run commands ask before they act. Search on your computer works through the CLI and shows the diff and the command for your approval before it runs. Policies and gates are evaluated in the platform.

Can I keep my Claude, ChatGPT or Codex plan if I switch to Safeguard?

Yes. Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. You can also connect Claude or ChatGPT to the Safeguard MCP server.

Should CI agents run in the most permissive mode?

Vendors that publish guidance tie that mode to isolation. Claude Code's docs show dontAsk with an exact allowlist for CI. With Safeguard, give safeguard exec prompts that read and report.

Does my code leave my machine?

Terminal agents work on files on your machine and send context to your model provider. Copilot cloud agent works in GitHub's environment. With the Safeguard local runner, source code stays on your machine and only SBOMs and findings are uploaded.

Try it yourself

This walkthrough sets up the runner on your own machine: pick the platform, start it, approve it with its device code, then use the same CLI to scan from the terminal.

Click through it at your own pace, or open it full screen.

Then download Safeguard, run safeguard, set /permissions to Ask for your first session, and read the CLI docs.

Quick check

Sources

• Safeguard CLI docs
• Safeguard CLI interactive terminal docs
• Safeguard download page
• Claude Code permission modes, Anthropic docs
• Codex agent approvals and security, OpenAI docs
• OpenAI Codex repository
• Risks and mitigations for GitHub Copilot cloud agent, GitHub docs
• Gemini CLI configuration reference
• Gemini CLI repository
• Cline auto approve docs
• Cline repository
• goose permission modes
• goose repository
• Qwen Code approval modes
• Qwen Code repository
• OpenCode providers docs

Last reviewed: 21 October 2026.