Integration
Safety Confirmation
ZCode brings ZCode Agent permission control into the task UI. The execution mode picker sits near the composer, so you can choose how the Agent should execute based on task risk.
The goal is simple: before allowing execution, review what the Agent is about to do. Commands, file changes, network calls, and script execution are surfaced in the task. When a high-permission or fully automatic mode is active, ZCode keeps the risk state visible in the toolbar.
ZCode Agent Permission Modes
ZCode Agent is ZCode's first-party Agent. It is tuned closely for the GLM 5.2 model family and is a good default for long-running, multi-step development work.
| Mode | Description | Best For |
|---|---|---|
| Default | Use ZCode Agent's default confirmation behavior. | Everyday development and normal Q&A. |
| Confirm Before Changes | Ask for confirmation before every file edit or command. | Critical code and production configs. |
| Auto Edit | Apply file edits automatically; commands still require confirmation. | Routine iteration work. |
| Plan | Plan first, then wait for confirmation before implementation. | Refactors, migrations, and long-horizon work. |
| Full Access | Run with fewer confirmations. | Trusted contexts where continuous execution is preferred. |
Workflow
- Trigger confirmation: when an Agent sends a permission-gated request, the current task pauses and the composer is blocked so the next action cannot be queued accidentally.
- Show the request: ZCode displays the exact command, file change, or tool action the Agent plans to run.
- User decision: the Agent continues only after you approve the request; rejecting it stops the current operation or returns the task to an adjustable state.
- Sync task state: permission requests are scoped to the task. If you switch away and come back, the pending request is still there, and the sidebar can show the task as waiting for confirmation.
Decision Options
| Option | Description | Recommended Scenario |
|---|---|---|
| Allow | Authorize only this one action. | Temporary or uncertain one-off tasks. |
| Always Allow | Authorize this and future actions of the same type without asking again. | Trusted repeated operations, such as routine builds. |
| Reject | Prevent the Agent from running the current action. | The command, path, or risk does not match expectations. |
| Always Reject | Block this and future actions of the same type. | Operations you never want the Agent to perform. |
In some scenarios, finer-grained options such as Allow for this session or Always allow for this project are also available.
Typical Scenarios
- Running third-party scripts: Python, Shell, or Node.js scripts inside your project.
- Network requests: external API access through
curlor similar tools. - File changes: creating, editing, deleting, or renaming files. ZCode shows a file-change summary with open and undo actions.
- System-level commands: commands that may change system configuration, install dependencies, or delete files.
Best Practices
- Review the command, path, and file names before allowing execution.
- Use Allow when you are unsure; avoid jumping straight to Always Allow.
- Always Allow and Full Access mode reduce future prompts, so use them only when the operation is trusted.
- For large changes, use Plan first, confirm the plan, then implement.