Action Approvals

Your agents can run DorkOS for you: make agents, schedule work, change settings, add and remove packages. On a Trusted install (the default), most of that runs on its own and lands in your activity feed, so you check it afterwards instead of approving it first.

Six things an agent does cannot be taken back: removing an installed package, deleting a scheduled task, removing an agent, changing an agent's safety boundaries, changing what an agent runs on (its runtime, model or effort), and running a package from a folder. The last three always ask, on Trusted and on Careful alike, because they bring in code nobody has reviewed yet or they would move an agent in a way every one of its scheduled runs would also move. The first three run on Trusted like everything else, recorded in your activity feed and named to the agent that asked. If you chose Careful in Permissions, all six wait for your yes, the way DorkOS always used to work.

The card for changing what an agent runs on shows each change as it is now and as it would be, for example Model: claude-sonnet-4 → claude-opus-4. An agent does not get to do one of the always-ask things and then tell you about it afterwards.

What you see

An amber marker appears in the top bar, on whatever screen you happen to be on, saying how many requests are waiting on you. Click it and the requests open right there, so you can answer without leaving what you were doing. The same requests sit at the top of Home, above your team's conversation, under Waiting On You.

Either way you get the same card, and it holds everything you need to decide:

• What would run, in plain words, including the details that matter (which package, whether saved data goes too)
• How big the change is: a label that reads "Cannot be undone", "Changes things", or "Read only"
• Who asked: the agent's name, or a note that the request came in without an agent identity
• How long you have before the request runs out
• Three answers: Allow, Always allow, and Deny

Nothing is pre-selected. Allow is the filled button because a one-time yes is the easy answer to give; Always allow is quieter because it lasts. Saying no is a normal answer.

When one of an agent's rooms caused the request, the card also shows up inside that room, just above the line that says who is working, so you can answer it where the conversation is.

What needs your OK, and what doesn't

Six things an agent can do have no undo. Three of them wait for you every time, whichever preset you are on, because each carries a risk nothing else on this page does. The other three run on a Trusted install like everything else and land in your activity feed, named to the agent that did them; on Careful they wait for you too:

• Changing an agent's safety boundaries (always asks), the list of things you told it never to do: the new text replaces the whole list, so whatever it said before is gone
• Changing what an agent runs on (always asks): its runtime, model or effort. Every scheduled task that doesn't pick its own would move with it. The card shows each change, as it is now and as it would be
• Running a package from a folder on your computer (always asks): whatever is in that folder runs in DorkOS, edits included, without another review. No setting can approve this ahead of time, so the card shows the folder's full path each time, and every command it runs and when. Approving covers those commands; anything new the folder adds later asks again
• Removing an installed package, with or without its saved data (asks on Careful)
• Deleting a scheduled task, which has no undo: the prompt, the schedule, and the timezone are gone (asks on Careful)
• Removing an agent, which also deletes its setup file and turns off its scheduled tasks (asks on Careful)

Creating a new package in your personal marketplace also always asks, because it is new code landing on your machine for the first time. Installing or updating a package asks too, on Trusted and on Careful: a package is code from outside your team. Its own hooks and any global plugins it carries ask separately as well — see Marketplace package trust.

Your permissions can add more. Any area you set to Ask, like Rooms, puts a card in front of you before an agent makes a change there, even one you could take back. An area set to Blocked is off for that agent: see When something is blocked.

Almost everything else an agent asks DorkOS for runs straight away. Reading your activity, listing your agents, editing an agent, changing a preference: those go through, and the ones that change something land in your activity feed so you can see them after the fact.

The rule is about the action, not about which agent asked. On Careful, the one way to stop being asked is Always allow, which is a decision you make yourself, for one agent and one action. See Always allow.

One set of settings is neither of those things. Agents are refused them outright, with no card and no way to say yes. See Settings your agents cannot change.

Every action carries a size label, and when a card shows at all, the label is on it, so you can tell at a glance what you are being asked:

On a Trusted install, the three with no undo that are not on the always-asks list above (removing a package, deleting a schedule, removing an agent) carry this label in your activity feed rather than on a card: nothing stopped to ask, but the record still says what kind of change it was.

Settings your agents cannot change

Most settings are preferences, and an agent can change one on your word. A few are not preferences. Most of them protect this DorkOS: they decide who can reach it, what it can reach on your computer, where your keys go, what leaves the machine, and whether you get asked before an agent acts:

• Whether Ask for a password on this computer too is on
• Your public web address, and the ngrok account it runs through
• Whether the tool endpoint answers, and the key that guards it
• Your AI service credentials, and the addresses they get sent to
• The DorkOS account this instance is linked to
• The folder DorkOS is allowed to touch, and the programs it is allowed to start
• Which extensions may run their code inside DorkOS, and which outside tool servers your agents may attach to
• Your privacy choices
• Whether you get asked before an agent does something

The two below are about something else. They are not protecting anything; they decide how often your agents speak without being asked, and every one of those turns costs you model usage. They are yours to set for that reason:

• How far agents may keep replying to each other in a room, how many turns an hour that may take, and how long an agent stays in the conversation after you talk to it
• Whether agents greet you when you come back, after how long away, and how many may speak

The last group is different again. These are the dials you turn down to give yourself room — less memory in use, fewer things running at once, smaller uploads, fewer tool groups in play. When DorkOS has to rebuild your settings file after a problem, it already refuses to undo a choice like that; an agent should not be able to undo it on purpose either. Each one says where you change it yourself:

• Whether your Claude Code chats keep an agent awake between messages, which costs memory — Control Center, under Warm agents
• How many scheduled runs may go at once — Control Center, or Settings → Advanced → Tools
• Which sets of DorkOS tools your agents are told about — Settings → Advanced → Tools
• How large an upload may be, and how many files it may carry — no screen yet; dorkos config set uploads.maxFileSize
• Whether DorkOS updates the agent files inside your projects on its own — no screen yet; dorkos config set harness.autoSync
• Whether DorkOS may move a skill into the folder every one of your tools reads, inside the folders it owns — no screen yet; dorkos config set harness.autoAdopt

The Control Center opens with ⌘⇧L (Ctrl+Shift+L on Windows and Linux). The last three have no switch anywhere in the app, so the command line is the way to them — and once you set one there, it stays set.

Agents are refused all of those, both from the tools they get inside DorkOS and from the settings screen itself. There is no card for them, because saying yes to one is not a decision anyone should be asked to make in the middle of somebody else's task, and there is no job that needs an agent to make it. An agent that tries gets a plain refusal telling it to ask you instead, and you change the setting yourself — in Settings, in the Control Center, or from the command line, as the lists above say. Three of these settings can still be reached by another route, which the second note below explains.

One more thing works the same way, though it is not a setting: where your packages come from. Agents cannot add or remove a marketplace source, because a source is a place DorkOS will download and run code from. The note just above does not describe it, though: this one is guarded the same way whether Ask for a password on this computer too is on or off, so turning login on does not add a second lock here the way it does for settings. Marketplace sources explains it, including the part Ask for a password on this computer too does not fix.

What about an agent that does not say who it is?

An agent can tell DorkOS who it is, and most do. One that doesn't is still stopped by the same question. The card simply says the request came in without an agent identity, so you know DorkOS cannot tell you who asked.

This also holds for dorkos call, which is how an agent reaches any DorkOS action from a shell. Running an agent outside DorkOS does not get past the question.

There is one gap, and it is worth knowing about. dorkos uninstall is the older, person-shaped command for removing a package. On Careful, an agent that runs it is asked, the same as everywhere else, because DorkOS spots the agent by the identity it carries; on Trusted, it runs and is recorded instead, the same as anywhere else an identified agent removes a package. Either way, a program that deliberately drops its identity first looks exactly like you clicking Uninstall in DorkOS, and with Ask for a password on this computer too off there is nothing left to tell the two apart. Turning Ask for a password on this computer too on is what closes it: an unidentified caller then gets a card in front of you like any other unattributed risky action, and the command tells you how to try again once you have said yes.

Two things stay open even with login on, and both are open on purpose. Adding or removing a package source, and creating or changing a scheduled task, are still things one of your API keys can do, because those are commands you run from your own terminal and DorkOS cannot tell your key apart from a copy of it. Answering an approval is the one thing a key can never do.

The agent that asked cannot answer

Saying yes is your half of this. An agent that asks for something is never allowed to answer its own request, and neither is anything else that holds the retry code DorkOS handed the agent. Both get refused, and the request stays at the top of Home, waiting.

Either way, every yes and every no lands in your activity feed. With login required, it says which account answered. Without it, the feed says the answer came from this machine and that DorkOS could not check who gave it, so an approval you never clicked is something you can find.

Always allow

Answering the same question five times a day is not safety, it is noise. So you can answer it once, for one agent and one action.

Press Always allow on a card and two things happen: this request goes ahead, and that agent is set to Allowed for that one action from then on. It is an ordinary permission setting, so you find it and change it where every other one lives, on the agent's Permissions page, and your permission history records who set it and from which card.

Some things about it are worth knowing before you use it:

• It covers one agent doing one action. The same agent doing something else still asks, and so does a different agent doing the same thing. There is no "trust this agent with everything" button on a card, on purpose.
• It lasts until you change it. Set the action back to Ask or Blocked on the agent's Permissions page and the next request asks again. It does not undo anything that already ran.
• Every use is still recorded. For an action that cannot be undone, your activity feed says each time the agent went ahead without asking.
• Some requests never offer it. Changing safety limits, and anything that opens this computer to the internet or touches keys and sign-ins, always need your yes, every time. Those cards show Allow and Deny, with a line saying so. A request DorkOS cannot tie to a named agent does not offer it either, because there would be no agent to remember it for.

Standing permissions, the old "Allow, and stop asking about this for 8 hours" button, are gone. Always allow replaced them. Any that were still running when you upgraded were ended rather than turned into something permanent, and your permission history has a line for each.

When something is blocked

An area set to Blocked for an agent is off for it: its tools are left out of what the agent is shown, and the agent is told the area is blocked. If it tries the action anyway, DorkOS refuses and no card appears.

When an agent really needs something that is blocked, it can ask you on purpose with a tool called request_permission. It names the action, the exact details it would use, and why. You get a card that says the agent is blocked and quotes its reason. Allow lets that one request through with exactly those details. Always allow does the same and sets that one action to Allowed for the agent, which brings its tool back. Deny says no.

So that asking never turns into nagging, DorkOS limits it:

• One question at a time per area. While a request in one area is waiting on you, the agent cannot ask for anything else in that area.
• No means no for a day. After you deny something, the same agent cannot ask for the same action again for 24 hours.
• Five an hour. An agent can ask past a block at most five times an hour, across every area.

These limits are kept in DorkOS's own records, so restarting does not reset them.

When nobody is watching

A scheduled run, a message from a chat connection, or a message from another agent starts a turn with nobody watching it in DorkOS. When one of those needs your yes, the agent does not sit there waiting. The card goes to your inbox, the agent says it is waiting, and when you answer, DorkOS tells the agent so it can carry on. A conversation you are in waits for your answer in place, the way it always has.

Approvals are used once, and they expire

• One approval, one action. Saying yes to removing one package does not say yes to removing another, or to the same one with different options. If a detail changes, DorkOS asks again.
• Used once. After an approval is spent it stops working. A second attempt needs a second yes.
• Two hours. If nobody answers in two hours, the request runs out and the agent has to ask again. Two hours is long enough that a meeting or a school run does not kill the request, and short enough that you are never asked to approve something you read about yesterday.
• No secrets on the card. DorkOS shows only the details a capability says a person needs, and it hides anything that looks like a password or a code. Cards are visible to your agents, so nothing private goes on one.

You don't have to babysit the card. Whatever the agent does next, the action itself does not run until you answer.

Your activity feed names who did what

The activity feed says which agent made each change, not just that something changed. It also records the attempts that did not go through: when a request is waiting on you, and when one was refused. So the feed reflects what your agents tried, not only what they finished.

From the command line

If you drive agents in a terminal, the same rule applies to dorkos call. A call that needs your OK comes back with status: approval_required and a token instead of doing the work:

dorkos call marketplace.uninstall --input '{"name":"some-package"}'
# status: approval_required, with an approval token

Approve it in DorkOS, then run the same call again with the token:

dorkos call marketplace.uninstall --input '{"name":"some-package"}' --approval <token>

Change the input and the token stops matching, because an approval covers one exact action.

Next steps