> Source: Onevium official documentation
> Article: Choose a work mode and permission profile
> Original URL: https://onevium.com/docs/permissions
> Language: English
> Updated: 2026-09-09
> Applies to: 1.1.22
> Feature status: Released

---

# Choose a work mode and permission profile

Understand Code/Plan and Default/Auto/Full Access, set new-session defaults, and verify actual execution.

## Two choices with different jobs

**Code/Plan controls how work progresses. Default/Auto/Full Access controls how tool permissions are handled.** You can review an approach in Plan, then keep an appropriate permission profile when implementing it.

## Choose the work mode

| Mode | When to use it                                                           | What to do                                                                               |
| ---- | ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------- |
| Code | The goal and scope are clear and work should execute                     | Supply the goal, allowed changes, and verification requirements                          |
| Plan | Understand the current state, compare approaches, or review impact first | Switch to Plan in the composer, request an approach, and review it before implementation |

Plan is not a third permission profile. Auto or Full Access does not mean every implementation detail is already approved when you choose Plan. Code does not mean unlimited access either.

## Choose tool permissions

| Profile     | Useful for                                                         | Actual behavior and limits                                                                                                           |
| ----------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ |
| Default     | A new project or work where you want to review permission requests | Requests requiring confirmation use approval cards; rules, tools, and SDK behavior still apply, so not every call must prompt        |
| Auto        | Reducing repeated confirmation during routine development          | The SDK classifier handles requests; decisions needing a person can still return to approval                                         |
| Full Access | Continuous, explicitly authorized work in a trusted environment    | Reduces ordinary tool approvals; does not grant external account access or replace Plan review, necessary questions, or verification |

Define project, file, and account scope first. Prompts describe the intended work; tool authorization and account permissions determine what can actually succeed.

## Session choices and global defaults

- **This task:** change the permission selector in the conversation's input area.
- **Future tasks:** open Settings → General → Default Permission Mode, choose the starting profile, then create a new conversation to check it.
- **Reasoning effort:** General → Default Reasoning Effort sets the starting level by model. This controls reasoning effort, not authorization.

Existing conversations can keep overrides. The fresh-install baseline is Full Access, while older configurations may differ. Use the displayed value; the option named Default is not necessarily the installation default.

## First exercise: plan, then make a small change

1. Open a demo project and inspect its directory and existing changes.
2. Choose Plan and an appropriate permission profile, then send:

```text
Plan a clearer empty state for the member list.
Read the component and project conventions first.
Identify affected files, loading/empty/error states, and checks.
Do not edit until the approach is approved.
```

3. Review the plan's coverage and boundaries, then allow implementation.
4. When an approval card appears, inspect the action, arguments, files, and target service before approving.
5. Review the diff and perform the agreed checks.

## Confirm the controls worked

The new conversation shows the expected profile, Plan produced a reviewable approach, and tool records and changes stay within scope. The final diff, tests, or page behavior should demonstrate completion.

No approval card does not automatically mean the setting failed: rules or the classifier may already handle a call. A denial does not automatically justify Full Access either; inspect the reason and required access first.

## Automations and external entry points

The current automation create/edit form **has no Default/Auto selector; tasks created through it use Full Access**. They do not wait for ordinary per-step conversation approval and should not be described as inheriting the current chat's profile. Test the prompt in a demo project before scheduling it.

Channel bots have their own approval policies. Preview external access uses assistant bindings and authorization. Changing a local conversation's profile does not automatically change these entry points.

## Common problems

- **Default changed but old chat did not:** it applies to future sessions; inspect the old session's own value.
- **Task remains waiting:** locate the approval or question and respond to it rather than repeatedly saying “continue.”
- **Work exceeds scope:** stop and clarify the task instead of first expanding permissions.
- **Different terminology:** CLI `permissionMode` and chat modes use different values; do not copy them interchangeably.

## Next steps

Use the [settings reference](https://onevium.com/docs/settings/reference#general) for defaults, [projects and sessions](https://onevium.com/docs/projects-and-sessions) for scope, and [files and Review](https://onevium.com/docs/files-terminal-review) to verify results.