Action Approvals
DorkOS asks you first before an agent does something to DorkOS you cannot take back
Action Approvals
Your agents can run DorkOS for you: make agents, schedule work, change settings, add and remove packages. Most of that is easy to take back. Four things are not: removing an installed package, deleting a scheduled task, removing an agent, and changing an agent's safety boundaries.
So DorkOS stops at those four and asks you. An agent does not get to do one of them and then tell you about it afterwards.
This is not the same as tool approval. Tool approval covers what an agent does inside a session: writing a file, running a command. Action approvals cover what an agent does to DorkOS itself.
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
- Two buttons: Allow and Don't allow
Read what would run. The sentence on the card is written by DorkOS, not by the agent. The name of the action comes from DorkOS itself, and anything the agent supplied is shown in quotes, so an agent cannot word the card to look like something else. For anything that cannot be undone, the whole sentence is shown, never cut short.
Click Allow to let it through. While the agent is still waiting on your answer, the same request also shows up as a card right inside that conversation — clicking Allow there, in the top bar, or on Home all finish the exact action the agent already asked for, so you never have to repeat yourself. If the agent stopped waiting before you answered, the card stays in your conversation as a reminder and the agent tries again once you say yes.
Or click Don't allow. The agent is told you said no, and it should stop rather than look for another way in.
Nothing is pre-selected, and neither button is styled as the safe choice. Saying no is a normal answer.
What needs your OK, and what doesn't
Six things an agent asks for will wait for you today. Four of them cannot be taken back:
- Removing an installed package, with or without its saved data
- Deleting a scheduled task, which has no undo: the prompt, the schedule, and the timezone are gone
- Removing an agent, which also deletes its setup file and turns off its scheduled tasks
- Changing an agent's safety boundaries, the list of things you told it never to do: the new text replaces the whole list, so whatever it said before is gone
Two more wait for you because they bring new code onto your machine:
- Installing a package
- Creating a new package in your personal marketplace
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. The one way to change it is to grant a standing permission, which is a decision you make yourself, for one agent and one action, on a clock. See Telling DorkOS to stop asking about one thing.
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.
Waiting is for the things you cannot rebuild, and a few things you can are still gone in one call. An agent can overwrite a scheduled task's prompt and timing with no copy of the old one. It can clear its own message inbox, which deletes the messages it just read. It can remove a message endpoint along with anything undelivered in it, or delete a chat route. None of those stop to ask, because they are the ordinary way an agent tidies up after itself, and a card on every routine cleanup teaches people to click through cards without reading them. What you get instead is a record: each one lands in your activity feed, named to the agent when DorkOS knows which one asked. Extension tools work differently again: an agent can write and compile extension files freely, but it cannot make DorkOS run an extension's code until you have allowed that extension, once. That covers both places it would run, on your computer and on the DorkOS page in your browser.
Each action DorkOS does cover carries a size label on its card, so you can tell at a glance what you are being asked:
| Label | What it means |
|---|---|
| Read only | Only reads. You will not be asked about these at all. |
| Changes things | Changes something you can change back. |
| Cannot be undone | There is no undo. Four today: removing an installed package, deleting a scheduled task, removing an agent, changing an agent's safety boundaries. |
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 Require login 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 provider 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, and how long a yes lasts
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 → Tools
- Which sets of DorkOS tools your agents are told about — Settings → 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.
How well this holds depends on Require login, and it is worth knowing which half you have.
With Require login on, only a person signed in to DorkOS can change these settings through the settings screen. A program holding one of your API keys is refused there just like an agent, because a key proves an account, not a person at the keyboard.
With Require login off, which is the default, it holds against any agent that says who it is, and that is how agents normally run. It does not hold against a program on your computer that deliberately hides that it is an agent. That program looks exactly like you clicking a toggle in Settings, and with no password anywhere, DorkOS has nothing left to tell the two apart. This is the same gap as the one below, and turning on Require login is what closes it.
The same is true of dorkos config set on your command line. That command is you, at your own
computer, so it changes any of these settings — and anything else running as you can type it. What
it cannot do is do it quietly: every change that command makes is written to your log at
~/.dork/logs/dorkos.log by name, and a setting that needs you to confirm what it means still asks
there.
Read that as being about dorkos config set and nothing wider. DorkOS's other commands still change
settings without writing a line — dorkos telemetry, dorkos auth, dorkos cloud, dorkos init
and dorkos config reset each change the one thing their name says, and none of them records it. So
a quiet log is not proof a setting never moved.
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 Require login 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 Require login does not fix.
Not every one of these settings is guarded everywhere yet, and the unguarded paths are wide open. Three of them have their own separate buttons that write the same setting by another path: connecting a model provider, starting your public web address, and linking this instance to a DorkOS account. Those paths have no agent check at all. Not "they accept an API key" — they do not ask who is calling in the first place, so an agent that says plainly who it is can use them, with Require login on or off. Reaching them still takes a terminal or the ability to make web requests to DorkOS, which is the same access the gap further down describes. So read this as: the settings screen is guarded, those three buttons are not yet. We are closing them separately.
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. An agent that runs it is asked, the same as everywhere else, because DorkOS spots the agent by the identity it carries. But a program that deliberately drops that identity first looks exactly like you clicking Uninstall in DorkOS, and with Require login off there is nothing left to tell the two apart. Turning Require login on is what closes it: removing a package then puts a card in front of you like any other 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.
What this protects, and what it doesn't. With Require login off (the default), DorkOS runs as you on your own machine, and anything else running as you looks exactly the same to it. So the question stops mistakes, and it stops an agent that follows the rules but was talked into something it shouldn't do. It does not stop a program that already has full run of your computer and is deliberately pretending to be you. Nothing on the same machine can, with no password in the way.
Turn on Require login (Settings, under Security) and that changes: answering a request then has
to happen in DorkOS itself, in a browser you are signed in to. An API key is not enough, on purpose.
Your agents hold one of your keys so they can run dorkos commands, and if a key could answer
requests, an agent could approve its own work. So it cannot. If you run agents you don't fully
trust, or you reach DorkOS from another device, turn login on.
Turn it on too if you leave agents running on their own and those agents can use a shell. Without login on, one of those agents can approve its own scheduled task, and reach your other protected settings the same way. It does this by sending DorkOS a plain request that looks just like you clicking in the app, so there is nothing left to tell the two apart. With login on, that request needs a browser sign-in it does not have.
That also means there is no way to say yes from a script or a terminal while login is on. That is the point of it, not a gap.
Worth knowing either way: what gets checked is a browser sign-in, not a person at the keyboard. Your activity feed says "a signed-in account" rather than "a person" for that reason. And a key still does plenty you can do, like installing packages, changing where packages come from, and creating tasks. So give out API keys the way you would give out your password.
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.
Telling DorkOS to stop asking about one thing
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, for a set stretch of time.
Turn it on in Settings, under Security. After that, an approval card carries a third button that names exactly what it does: Allow, and stop asking about this for 8 hours. Press it and that one agent does that one thing without stopping, until the time runs out.
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 purpose.
- The clock does not reset. Eight hours means eight hours from when you pressed the button, no matter how often the agent uses it.
- A day is the longest you can pick. "Forever" is not on the list.
- You can find it and end it in two places. Settings under Security lists everything that is live, and the Inbox in the top right shows it too. Either one has a Stop trusting button next to it.
- Every use is still recorded. Your activity feed says so each time the agent goes ahead without asking. Ending a permission stops the next action; it does not undo one that already ran.
- Turning the feature off ends everything that is live. Nothing sits dormant waiting to wake up later.
This needs Require login on, and there is no lighter version. Opening a permission means DorkOS has to know it is you asking and not an agent on the same computer. With no login, there is no password anywhere and nothing to tell the two apart, so the control is shown but switched off, with Require login sitting right above it. Any weaker check would be one an agent could pass exactly as easily as you, which would be worse than not offering it.
A standing permission really does lower the gate. That is what it is for. It is a trade you make on purpose, bounded by one agent, one action, and a clock. If you would not be comfortable coming back to find that action had run three times while you were at lunch, do not grant it.
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 tokenApprove 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.