Agent permissions

You can let an agent create devboxes, organize work, or update project settings through Agent permissions. To control whether the agent asks before editing files or running commands, choose Claude's working mode or set a custom command policy for Codex or Claude.

Allow boxes.dev operations

Open one of your threads and select Agent permissions in its header. In the mobile app, choose … → Agent permissions in the thread. The control shows the permissions of the exact Template box or devbox the thread runs on. Switches show whether a permission is on or off. On desktop, Read threads, Pause and resume agents, and Destroy and archive devboxes show the selected scope as an icon with a chevron; open the menu for the full labels or to choose Off. These controls include permissions enabled through Project settings. A permission you turn on will apply to every agent on that box until you turn it off.

If an agent needs a disabled permission for your task, it can show a request with Deny, Allow, and, where supported, Always allow for project. Suppose you asked Codex to move its devbox into your Planning folder while folder access is off: choosing Allow will turn folder access on for that machine, just as if you had enabled it yourself; it is not a one-time exception for that move. Choose Deny to decline this request without changing any permission settings.

You can also manage these from a terminal on your computer. dvb permissions get and dvb permissions set view and change a box's permissions or the project's shared settings, and dvb permissions requests lists the requests agents are waiting on so you can allow or deny them. See Use the CLI.

The controls include:

• Create devboxes and threads: allow agents to start additional work in this project.
• Update thread titles: allow agents to rename their current thread and its devbox.
• Folder access: choose no access, permission to move devboxes into folders, or permission to move devboxes and create, rename, reorder, and delete folders.
• Message other agents: allow agents on the machine to send messages to your other agents in this project and receive their messages, including attached files. A message will start an idle agent and wake its devbox if it's asleep. Both machines need this permission.
• Message teammates' agents: allow agents on the machine to message your teammates' agents, and let your teammates' agents ask to message agents here. See Messages from teammates' agents.
• Read threads: choose this project, all your projects, your threads plus threads shared with you, or your threads plus teammates' threads you can access. Each level includes the preceding levels. Team visibility and private-thread settings still apply. Agents will only be able to read these other threads with this permission; sending messages and controlling agents have separate permissions.
• Pause and resume agents: choose Created from this devbox (the default), In this project, or Across all my projects. Each level includes the preceding levels and covers only your own threads. Agents will be able to stop an active turn and send follow-ups in those same threads, preserving their devboxes and files. Queued follow-ups can still run afterward. This permission works independently of permission to create devboxes and threads.

On an ordinary devbox, Destroy and archive this devbox lets agents request its deletion after all agents finish. This permission is off by default; you can also enable Destroy and archive in Project settings for devboxes that follow the project setting. This permission lets agents destroy only their own devbox. Files are permanently deleted; thread history is retained. Turning the permission off cancels a pending request. An agent can also cancel with dvb-onbox box cancel-destroy, even when this permission is off; cancellation is available only before destruction starts.

On a Template box or devbox, Destroy and archive devboxes lets agents request deletion of your other devboxes in the project, for example after their work has merged. Choose Created from this devbox to cover only devboxes that agents on that box created, or In this project to cover all of your other devboxes in the project, including ones you created yourself. Each devbox will be deleted after all of its agents finish. Its files will be permanently deleted, and its thread history will be retained. This permission is off by default and is separate from Create devboxes and threads and from each devbox's own Destroy and archive this devbox permission. Agents can't use it to delete the box they run on, a Template box, or a teammate's devbox. Turning the permission off or narrowing it cancels pending requests it no longer covers, and an agent on any box in the project can cancel a request before destruction starts.

On an ordinary devbox, either level of Destroy and archive devboxes also lets agents archive worker threads that agents on that same devbox created there. It doesn't cover manually started threads or threads created from another box. The devbox's first thread stays until the devbox itself is destroyed and archived.

On an ordinary Template box, you can also enable Edit devbox lifecycle for startup and teardown settings, or Edit template maintenance for the maintenance script and its GitHub watches. Agents on that Template box will then be able to change them without asking. Agents on any box in the project can instead ask to edit project settings, which covers both. Team admins can enable Create Team Templates to let agents create, configure, and save Team Templates.

Messages from teammates' agents

When Message teammates' agents is on, your agents can send messages to your teammates' agents, and their agents can ask to message yours. It needs to be on for both machines: the one the sending agent runs on and the one the receiving agent runs on. You and your teammate each turn it on for your own machines, in the desktop app or on mobile.

When a teammate's agent sends your agent a message and you haven't always allowed messages from its thread, your agent's thread will show a card above the reply box, in the desktop app and on mobile, with the full message, for example "Nick's Codex agent wants to send this agent a message." boxes.dev will also notify you, unless you've muted the thread or turned those notifications off. The message will wait until you decide, however long that takes:

• Allow will deliver this message. An idle agent will start, and an asleep devbox will wake.
• Always allow from Nick's thread will deliver this message and every other message from that thread to this one without asking.
• Deny will discard the message. The teammate's agent won't get a notification about it.

Delivered messages appear in the thread labeled with your teammate's name, such as From Nick's Codex agent. View thread will appear only if you can read their thread, because they shared it and you opened the link, or because your team lets everyone read all threads.

To stop always allowing a thread, open Agent permissions in your thread's header in the desktop app, or choose … → Agent permissions in the thread on mobile, and select Remove next to it under Always allowed in this thread. Its next message will ask you again. Turning off Message teammates' agents on either machine will stop delivery.

Messages your agents send work the same way: your teammate can allow them one at a time or always allow messages from your agent's thread to theirs.

Let one thread edit settings

Agents can read Project settings and accessible Team Template settings without an editing permission, including saved guidance and where it came from. Saved environment values and member-file contents are not included in these reads.

If you ask an agent to change settings, it can ask Allow this thread to edit settings? Choose Allow for 3 hours to let that thread change guidance, startup and teardown scripts, Template maintenance, Git, ports, storage, the Browser, Project URLs, and your own environment and member-file values. The thread will also be able to share itself with your team by link and change your account preferences, such as notifications, idle sleep, Git identity, and agent replies. Access will end after three hours and will apply only to that thread. Agent permission defaults will remain editable only by you. See Read and edit settings.

Let one thread configure an integration

Agents can read saved integration status without permission to edit, including which setup steps need you or a team admin. The read does not include saved credentials or sign-in codes. Setup links open the selected integration and project in the desktop app.

For routine changes, an agent can request three-hour permission for Tailscale's future-devbox auto-connect setting or Google Cloud's default/quota project. Each permission covers only that integration in the requesting thread's project. It does not grant access to unrelated Project settings. Saved changes will remain after the permission expires.

Changing an AWS Company SSO profile or enabling Tailscale requires a separate approval of the specific action. The request will show the project and AWS account/profile/permission set, or the Tailscale tailnet/tag and automatic connection choice. Review that access before approving: software and agents on the project's boxes will be able to use it. There is no Always allow for project option for these actions. The agent must apply the approved choice within ten minutes, and the change will remain afterward. Use an updated app or CLI to review these detailed requests.

Let one thread edit your Template

If you ask an agent on a devbox to change the Template that devbox came from, it can ask for access in that thread. The request shows Allow for 3 hours and Deny. Access will apply only to that thread and will end 3 hours after you allow it. Other threads and devboxes won't receive it, and it isn't one of the Agent permissions switches.

In a project with its own Template box, the agent will be able to run commands on your Template box, change the project's settings and environment variables, and take a snapshot that future devboxes will use. In a Team Template project, you need to be a team admin; the agent will be able to open the Team Template's editing session, change it and its environment variables, and save a new version for your team. If you save that editing session yourself in the desktop app, the agent's access to it will end. Team Template settings and definitions can be changed with this permission without opening its editing session. The same permission is available from an independent project created from that template. Changing template defaults will affect future project copies, and existing projects will keep their copies. Agent guidance is the exception: new devboxes in managed projects always get the template's current guidance before the member's own. Template access also covers the current thread's own project settings, with permission defaults remaining user-only.

If you're a team admin, an agent in any of your projects can also ask Allow this thread to edit team settings? For 3 hours, that thread will be able to change your team's name, teammate thread access, idle sleep default, allowed domain routing, and static egress destinations, the project's Team Template when the project came from one, and the settings of any project on your team, including your teammates' projects. Your teammates' integrations, environment values, and member files will stay theirs to change.

An agent can also invite someone to your team, revoke an invite, or change a teammate's role, but only one change at a time: each request names the person, the role, and the team, and you'll need to approve that exact change. Removing members stays in Team and members.

In a Team Template project, any member can also let a thread edit their own environment variables. That request asks Allow this thread to edit your environment variables?, and the agent will be able to add, change, and remove your own variables, your values for the team's Member variables, and personal overrides where the admin enabled Allow personal override. These values will reach all your devboxes in the project. The agent can't read saved values.

Let one thread edit your automations

If you ask an agent to set up or change an automation, it can ask Allow this thread to edit your automations? in that thread. Choose Allow for 3 hours to let that agent create, change, pause, activate, run, and delete your automations in the project. Like Template access, it will apply only to that thread and will end 3 hours after you allow it. A thread can have this access and Template access at the same time. Agents can read your automations without asking. See Ask an agent to set it up.

Share permissions across your project

Open the sliders beside the sidebar's project selector, then Agent permissions for this project, to choose shared settings for creating devboxes and threads, updating thread titles, folder access, reading threads, pausing and resuming agents, messaging other agents, messaging teammates' agents, and destroying and archiving devboxes. In the mobile app, tap the gear button in the project and choose Agent permissions. Changes will apply to your existing and future devboxes, except those you've configured separately. These are your permissions, including in a managed project; they will not change a teammate's permissions.

In a managed project, a team admin can set these permissions in the Team Template. They will follow the template until you change one, and Use Team Template permissions will return all of them to the template's values. If the admin locks them, you won't be able to change them in Project settings or choose Always allow for project, but you can still change permissions on individual boxes. See Team agent permissions.

In an agent's permission request, choose Always allow for project to grant shared access. This will also enable the permission on the requesting box. Other boxes will keep any permissions you've set individually.

To give a particular box different permissions, change them in its thread header. That choice will apply to the box even when the project setting changes. Turning off shared access will revoke it on boxes that follow the project setting; permissions set individually will remain. Some older boxes also have permissions saved individually. To turn those off, use the box's Agent permissions control. Template-only permissions keep their existing scope.

Project settings control shared agent permissions for existing and future devboxes. Select the image to enlarge it.

Choose Claude's working mode

Claude's working mode controls approvals for edits and commands in that thread. It does not change the boxes.dev operations allowed through Agent permissions. In a connected Claude thread, use the mode control near the reply box to choose how Claude should work. The available choices depend on the machine and model:

In Full-access, Claude will still ask before a few operations that its own safety checks flag, such as deleting files when it can't tell in advance which files those are. It will also ask before anything that matches an ask rule in its settings and won't do anything that matches a deny rule. These rules can come from your project's Agent settings or your repository's .claude/settings.json. Claude's request will include the reason it's asking, or the rule that matched when Claude reports one.

If your repository's Claude Code settings turn off bypass mode, for example with permissions.disableBypassPermissionsMode in .claude/settings.json, Full-access isn't available. Claude threads in that project will start in Auto instead, or in Manual if the settings also turn off Auto.

Your confirmed Full-access, Auto, or Manual choice stays with the thread unless a custom machine policy overrides it when the agent restarts. Plan is temporary: when Claude proposes a plan, choose Yes, implement this plan to return to the previous mode and let it implement the plan. To keep planning, type what to change in No, tell Claude what to change, or send the change from the reply box, and Claude will revise the plan. If Auto becomes unavailable, Claude can return the thread to Manual.

Advanced: custom command policies

Codex normally makes ordinary edits and runs commands on its machine without individual approvals; to change that, set a custom command policy on the machine. For either agent, a policy can require approval for commands outside an allowlist, and command hooks can run your own checks around agent tools.

To set them up, read the machine README under /etc/boxes/agents/codex/ or /etc/boxes/agents/claude/. Finish active work and reboot to activate policy changes; reboot preserves files but stops workloads. See Custom command policies for file formats, activation, and recovery details.