Planning and permissions

Use planning to agree on an approach before implementation, and permissions to decide which tool actions require your approval. For a first task, choose Always ask so you can inspect file changes and commands as they are requested.

​

Plan before editing

If you want to agree on an approach before files change, open the + menu and choose Draft a plan before sending the request. The agent can investigate the project and propose a plan, but plan mode restricts editing. Refine the plan in the conversation, then choose Implement the plan to proceed. For the checkout example, a planning request could be:

Identify the files and tests affected by adding quantity support. Propose a plan before editing.

​

Review the plan

A useful plan names the affected files, the behavior that will change, and the checks that will demonstrate success. For the checkout fix, it should identify the calculation and its tests, explain how quantity affects the total, and propose running the same regression test before and after the edit. Resolve assumptions before choosing Implement the plan. For example:

Keep the existing price representation and exported function name. Cover quantities of one and three. Do not change the payment integration or add dependencies.

Planning and permission mode serve different purposes. The plan establishes what to do; the permission mode controls approval as the agent attempts tool actions during implementation.

​

Choose a permission mode

The permission selector controls how tool approval requests are handled: Saved permission rules can also affect approval decisions. Plan mode restricts editing, and plugin hooks require separate consent. Permission modes govern the agent’s actions; operating system or container permissions determine what an executed command can access.

​

Respond to an approval request

An approval card identifies the proposed tool action. Read the command, file, or external resource and compare it with the task you requested. A command that runs a test is different from one that installs packages or publishes a result, even if both appear as terminal activity.

1. Expand the request and inspect its target and arguments.
2. Approve if the proposed action fits the task, or deny it if the scope is wrong.
3. If the agent needs a different approach, explain the change in the conversation.
4. Inspect the tool result after the action runs. Approval permits the attempt; it does not establish that the action succeeded.

The agent can also pause for a multiple-choice question. Answer it in the session to resume work. An unanswered question or approval request can make a scheduled run show Needs attention.

​

Reuse approval decisions

When you repeatedly approve the same command, the app may offer to save a permission rule for the repository or your account. Check that scope before saving: a repository rule applies to that project, while an account-level rule can affect other local work. For a task where you want to inspect every requested change, start with Always ask and review existing rules if an action behaves differently than expected. Use Accept files when you are comfortable with project edits but still want to decide on command requests. A saved rule or broader mode is not a substitute for reviewing the final diff. Continue with Quickstart.