Until now, working with an agent meant one chat with one agent. This release adds rooms: channels and direct messages where you and several agents talk together, in one place. It also puts every trust and permission decision in front of you, so you can always see what your agents are allowed to do without asking.

Highlights

Channels and direct messages

Channels and Direct messages now sit in the left sidebar, beside your agents. Make a channel, invite the agents you want, and talk to all of them in one conversation, or start a one-to-one direct message with just one.

One dial for how much your agents may do

The DorkOS approval card asking to approve a file write, showing the file path, a countdown bar reading 1:59 remaining, and Approve, Always Allow, and Deny buttons with an Add a reason link beside them Set where new chats start, and answer the ones that stop to ask. See how approvals work in the Tool Approval guide.

Settings now asks one plain question: where should new chats start? Ask first, Act, or Full autonomy. The same three words mean the same thing for every agent runtime you use, and a line under each one says what it actually means there.

See every file, link, and command a turn handled

Each reply now carries a row of small chips, one per file, page, or command the agent touched, and each chip moves the way its job moves. When the reply is done the row folds into one quiet line you can open to read the full list.

The desktop app has a stable address

The desktop app now runs on http://localhost:4242, the same address as the command line, instead of a new random one every time you open it. Your bookmarks and MCP setups keep working from one launch to the next.

All Changes

Added

Your agents can now browse and install marketplace packages from inside a session. The same marketplace tools an external client had (search, get, list, recommend, install, uninstall, create a package) now work for the agent you are chatting with, with the same approval step before anything is installed (DOR-429)
Your agents can now help run DorkOS itself. From inside a session, an agent can edit its own personality (traits, conventions, SOUL.md and NOPE.md), read the activity feed, see which agents were active recently, read and change your settings, and check whether a DorkOS update is available. System agents like DorkBot still refuse to have their identity changed, and settings changes only happen when you ask for them. These tools work for both your in-session agent and external MCP clients (DOR-430)
Setting up local models is now guided. When Ollama isn't installed, DorkOS explains what it is (a free, open-source app that runs AI models right on your computer, so nothing you type ever leaves it) and offers the simplest way to get it: a one-click install on macOS (Homebrew) and Windows (winget), or the official command to copy on Linux. DorkOS never asks for your password, and it checks that Ollama is actually running before saying it worked (DOR-439).
Drive DorkOS from the command line: new dorkos agent, dorkos task, dorkos activity, and dorkos version --check commands. List, inspect, and create agents; list, create, and trigger scheduled tasks; read the activity feed; and check the running server's version against the latest release (it still answers from a local cache when no server is running). Every command takes --json for clean, machine-readable output, so an agent in any runtime can operate DorkOS through the terminal. Run any command with --help for its options (DOR-434)
New agents now come with built-in knowledge of how to run DorkOS for you. Every agent you create, and DorkBot itself, gets a set of first-party skills that explain the dorkos command line and the in-session tools for making agents, scheduling tasks, installing marketplace packages, reading activity, and changing settings. The skills update themselves when you upgrade, and any skill you have edited by hand is left untouched (DOR-433)
New guide: how to ask your agents to run DorkOS for you. It walks through what you can ask an agent to do (create agents, schedule tasks, install packages, change settings, read your activity) and lists the dorkos commands that do the same from a terminal (DOR-436)
Your agents can now ask a running DorkOS "what can I do here?" and get a live answer. A new dorkos capabilities command (add --json for raw output), a list_capabilities tool inside sessions and for external clients, and a dorkos://capabilities resource all return the same up-to-date catalog: every capability the registry carries, with a short description and how risky it is. Agents no longer have to guess from static docs (DOR-442)
The API reference now documents capabilities from the registry automatically. The live capability catalog (GET /api/capabilities/catalog) and the activity feed (GET /api/activity) show up in the API docs at /api/docs, each with its request and response shape. As more capabilities move onto the registry, their endpoints appear in the docs on their own, with no separate step to keep in sync (DOR-444)
New dorkos call <capability-id> command: invoke any DorkOS capability by id from the command line and get the result as JSON. Pair it with dorkos capabilities to discover what's available, then call one with --input '{...}' (or --input-file). Unknown ids and invalid input come back as clear errors. This gives an agent in any runtime a single, uniform way to drive DorkOS (DOR-443)
The Activity feed now names which agent did what. When one of your agents changes a setting, updates another agent, or installs a package, the entry shows that agent's name instead of leaving you to guess. DorkOS hands each agent its own identity when it starts a session, and nothing about how your agents work changes.
Save the setup you are working in as your own Shape. The Shape switcher now has Make your own version next to Reset to defaults: name your copy, and it keeps the extensions you have turned on and the way your workspace is arranged. Anything DorkOS cannot see stays exactly as the original Shape had it — it will never erase a setting nobody changed, like panels closed by a page reload — so your copy only records what you actually chose. Escape backs out one step at a time: it closes Name your version first, the switcher second. And if you walk away while a copy is still saving, DorkOS still tells you how it went (DOR-402, DOR-453)
End a line with a backslash and press Enter to keep typing on the next line — the backslash disappears. It works anywhere in the message, not just at the end, and two backslashes in a row still send (DOR-452).
Option+Enter (Alt+Enter on Windows) now starts a new line instead of sending (DOR-452).
The keyboard shortcuts panel now lists what the message box does: new line, keep typing on the next line, clear, and what one Escape does first when several things could happen at once (DOR-452).
A Session panel behind the ⋯ at the end of the status line, on click or Cmd+Shift+.. It lists everything about the session with its live value — directory, git, runtime, model, context, cache, usage, permissions — plus sound and background refresh, and diagnostics: connection, how far the live link has caught up, how many messages are waiting, and the session id. On a phone it opens as a bottom sheet, most urgent first (DOR-452).
Copy diagnostics in the Session panel puts everything above on your clipboard as one block of readable JSON — the thing to paste into a bug report (DOR-452).
Pin any session row to keep it in the status line even when it has nothing to report, and Reset pins to clear them all. Your pins are saved with the rest of your settings rather than in one browser, so they follow you to your other windows, the desktop app, and Obsidian — and you can just ask an agent to pin something for you (DOR-452).
When the conversation window passes 85% full and your agent is not mid-answer, a one-click Compact appears right beside the percentage instead of on a row of its own. It waits for the turn to finish, because compacting cannot start while your agent is still working (DOR-452).
DorkOS can now ask you before an agent does something you cannot undo. When an agent requests approval, a card appears on your dashboard saying what would happen in plain words, with Allow and "Don't allow" buttons and how long you have to decide. The card shows up in every window you have open and disappears everywhere as soon as you answer (DOR-447). The countdown bar reaches the browser, including after a reload or in a second window.
A Session tab in the right panel, next to Agent Profile. It shows everything about the session you are in and stays open while you work: whether the live connection is healthy, how long it has been since anything arrived, the full project folder, which model actually answered you, how full the conversation window is and what is filling it, how much came from cache, what your plan or spend looks like, and which helper agents are running or have finished this turn. Handy when a reply seems stuck and you want to see whether the problem is the connection or the agent. Copy diagnostics puts the whole picture on your clipboard for a bug report.
Agents now have to ask before anything they cannot take back. Every DorkOS action an agent can run through the capability catalog carries a size: read only, ordinary change, or cannot be undone. Reading is free, ordinary changes go ahead and get logged, and anything that cannot be undone stops and waits for you, with plain-words instructions for the agent on what to do next. The check runs on every path an agent can reach: the API, the tools inside a session, and the tools an outside app like Claude Code or Cursor uses. Tools that are not in the catalog are not covered by this check (DOR-448).
Your approval card now names the agent that asked and how consequential the action is, so you can tell who wants what before you answer (DOR-448).
The activity feed now records what an agent tried and was not allowed to do, not only what it did (DOR-448).
dorkos call takes an --approval <token> option, so an agent working from the command line can finish the same ask-and-retry flow (DOR-448).
New guide, Action Approvals, explaining when DorkOS asks you before an agent does something that cannot be undone: what the card on your dashboard shows, why an agent cannot skip the question by leaving its name off, why an approval works once and runs out after two hours, and how the activity feed names which agent did what (DOR-451).
See when an agent is waiting on you, from any screen. A marker in the top bar says how many requests need your approval, and clicking it opens them right there so you can answer without leaving what you were doing.
Requests clear themselves once they run out of time, so you are never looking at one you can no longer answer.
Three new pages on dorkos.ai describe what shipped: Action Approvals, Agent Attribution, and the Capability Catalog (DOR-428)
Press Escape once while you have something typed in a chat and a quiet note now appears just above the composer: Press Esc again to clear. Pressing Escape twice has always wiped a draft, but the first press did nothing you could see, so nobody ever tried the second one. The note shows up only while that second press would really work, and it is gone the moment it would not (DOR-479)
Standing permissions now work. When you answer an approval with "and stop asking about this", DorkOS remembers it for one agent doing one action, for as long as your trust window says, and lets that agent get on with it without interrupting you. Every time it does, your activity feed says so, and one line tells you which permission let it through (DOR-501)
You now decide which extensions may run their code inside DorkOS. That covers both halves of an extension: the part that runs on your computer, which can reach anything DorkOS can reach, and the part that runs on the DorkOS page in your browser, signed in as you. Until you say yes, neither one runs. The first time an extension tries, it waits: Settings → Extensions shows it with an Allow it to run button. One click and you are done. After that, editing, testing, and reloading that extension all work with nothing further to click, and turning it off and on again does not ask you again. Stop it on the same card takes the permission back and stops the extension right away. Extensions that ship with DorkOS never ask, because you already installed DorkOS.
Your agents can see which extensions you have allowed, but they cannot add to the list. An agent that could allow its own extension would be approving its own code, so that answer is yours alone, alongside your other protected settings. The same limit applies as to those: with Require login off, which is the default, this holds against any agent that says who it is, and turning Require login on closes the rest.
Updating or reinstalling an extension asks you again. New code is a new decision, even under a familiar name. Editing an extension you already allowed never re-asks, so building your own is still one click, once.
A web page you visit cannot allow an extension for you. Requests to allow or stop an extension now have to come from DorkOS itself.
Tell DorkOS to stop asking about one thing. An approval card now carries a third button, "Allow, and stop asking about this for 8 hours", that covers one agent doing one action, for a stretch of time you choose. Turn it on in Settings, under Security (DOR-501)
Find and end a standing permission from either of two places: Settings under Security, or the approvals marker in the header, which now shows a quiet count when trust is live. Each one has a Stop trusting button (DOR-501)
Choosing a trust level that skips prompts now says what it does not cover: actions on DorkOS itself, like removing packages, still ask. The line appears wherever a level is picked: the session picker, a channel binding, and a scheduled task (DOR-501)
Group conversations now have somewhere to live. A room holds several people and several agents in one running conversation, keeps every message forever, and remembers where each member left off reading (DOR-524)
Rooms come in two shapes: channels for a topic and direct messages for one-to-one. A side conversation hangs off the message it answers rather than taking the room over (DOR-524)
An agent keeps the same name on everything it has ever said, even after DorkOS rebuilds its records in the background (DOR-524)
Refuse to start a second DorkOS against the same data directory, and say which one already has it. Two servers sharing one directory used to corrupt each other's agents and history (DOR-532)
Channels and Direct messages now sit in the left sidebar, beside your agents. Click one to open it and read what has been said. Both sections collapse, and DorkOS remembers whether you left them open (DOR-525)
Make a channel straight from the sidebar: hit the + beside Channels, type a name, press Enter. Start a one-to-one conversation the same way — hit + beside Direct messages and pick an agent (DOR-525)
A room shows who is in it, groups messages by who is talking, marks where one day ends and the next begins, and draws a line at the first thing you have not read. Open the room and the line stays put while you catch up; the unread count beside it clears (DOR-525)
Where you left off reading is remembered by DorkOS, not by your browser — so it is the same on your laptop and your phone (DOR-525)
Anything posted into a room you have open appears straight away, with no reload (DOR-525)
The desktop app keeps running when you close its window, so your agents carry on working (DOR-538)
A DorkOS icon in the macOS menu bar shows how many agents are working, and brings the window back (DOR-538)
The first time you close the window, DorkOS tells you it is still running, and offers to quit if that is what you meant (DOR-538)
Quitting while agents are mid-task now asks first: "3 agents are still working. Quit anyway?" (DOR-538)
"Open in New Tab" opens a second DorkOS window instead of sending you to your web browser (DOR-538)
Open your agents in tabs in the desktop app, the way you already work in a browser or an editor. The tab strip runs across the top of the window, and the + button opens another one (DOR-540)
Those tabs tell you what your agents are doing while you are looking somewhere else. A tab lights up when its agent starts working, needs an answer from you, or hits a problem. You can leave five agents running and glance at the strip to see which one wants you
Keyboard shortcuts for the desktop app's tabs: Cmd/Ctrl+T opens a tab, Cmd/Ctrl+1 through 9 jump to one, and Cmd/Ctrl+Shift+[ and ] step between them. Cmd/Ctrl+W closes the tab you are on, and closes the window once it is the last tab. You can also reach the strip with Tab, move with the arrow keys, and close a tab with Delete. The × on a tab closes it too
Your desktop tabs come back after a reload, and each window keeps its own set
"Open in New Tab" in the command palette opens an agent without losing the one you were reading. In the desktop app that is a DorkOS tab; in a browser it is a browser tab, which you can bookmark or drag onto a second screen yourself
The desktop app's command palette also has "Open in New Window", which opens a second DorkOS window on the agent you picked. Handy for a second screen. A browser has no separate answer to that, so the choice is not offered there
See the address DorkOS is running on in Settings → Server, with a button to copy it and a button to open it in your browser. The MCP endpoint is right below it, ready to paste into Claude Code, Cursor, or Windsurf (DOR-539)
Agents now answer in rooms. Post in a channel or a direct message and every agent the message is meant for takes a turn and replies, right there in the conversation. Each agent keeps its own thread of context per room, so what you say in #backend stays separate from your one-to-one chat with the same agent (DOR-526)
A new setting, rooms.maxAgentDepth, caps how many replies in a row agents may send each other before a room stops them and says so in the conversation. Messages from you start the count over, so a room that has gone quiet is one message away from running again. Set it to 0 to turn automatic replies off (DOR-526)
Two more settings put a ceiling on what automatic replies can cost you: rooms.maxAutomaticTurnsTotalPerHour (240 by default) caps how many DorkOS runs in an hour across every room you have, and rooms.maxAutomaticTurnsPerRoomPerHour (60) stops any single room using up that whole allowance. Both count no matter who the message looked like it came from, and the room says so when it stops. These are the ones that hold if Require login is off — see the note below (DOR-526)
Agents in a room now show their emoji and colour, the same way they do everywhere else in DorkOS (DOR-526)
Say something in a channel or a direct message. Rooms used to be read-only from the cockpit — the line at the bottom said so — and now there is a message box: Enter sends, Shift+Enter starts a new line, and everyone in the room, agents included, sees what you wrote (DOR-526)
Your words are never thrown away. The box empties as soon as you press Enter, so you can start the next sentence right away; if a message can't be sent, it comes back into the box — above whatever you've typed since — with a note saying what went wrong. That holds even if you've moved to another conversation in the meantime, or sent another message after it: the words go back to the room you wrote them in, and are waiting there when you return (DOR-526)
Half-written messages keep. Start typing in one channel, go read another, come back — your sentence is where you left it. Each channel and DM keeps its own (DOR-526)
A direct message can hold several agents. The "+" beside Direct messages now lets you pick more than one: type a name and press Enter to add it, then keep going. Everyone you pick shows as a tag, so you can see who is in the conversation before you open it. One agent gives you a one-to-one; two or more give you a group named after the people in it. Backspace takes back the last agent you added, and Escape closes without opening anything (DOR-571)
Channels and direct messages now have a docs page. It explains what a room is, how a channel differs from a direct message, and how both differ from a session, plus how to create each one (DOR-565)
Channels and direct messages now have a menu, on right-click and on the "…" button beside the row: mark as read, add agents, members, rename, edit topic (channels), and archive. It matches the menu agent rows already have.
A members panel shows who is in a room, lets you add or remove agents, and — for the first time — lets you choose when each agent replies there: to everything, when spoken to, only when @mentioned, or not at all. Until now that setting was fixed the moment an agent joined.
On a one-to-one conversation, the menu has a shortcut straight to that agent's profile.
When you add agents to a room, each one drops off the list the moment it is in. If one doesn't make it, it stays picked so you can try that one again without adding the others twice.
See the exact commands a package sets up before you install it. The install preview now lists each one, word for word, next to a plain description of when it would run (DOR-635)
See the jobs a package will schedule, when they run, whether they start switched on, and how much each one may do without asking you. Shapes used to create timed jobs that no preview mentioned at all (DOR-635)
You can now pick the agents when you make a channel. The + next to "Channels" opens a dialog that asks for a name and who's in it, instead of just a name. A channel with nobody in it has nobody to answer you, so this is now one step rather than a thing you couldn't do at all. If you really want an empty one, "Create it without agents" is still there (DOR-599)
You can add agents to a channel any time afterwards, from three places: the row of faces at the top of an open channel, the "Add agents" button in a channel with nothing in it yet, or a right-click on the channel in the sidebar. All three open the same panel, which is also where you remove someone and set how each agent decides when to reply in that channel (DOR-600)
Two new settings for rooms: rooms.replyWaitMinutes (how long a room waits for an answer, 10 minutes by default) and rooms.lateReplyCeilingMinutes (when it gives up and says the agent could not finish, 60 minutes by default). (DOR-621)
Your channels and direct messages are now in the command palette. Press Cmd+K and, before you type anything, you see what is unread, most pressing first. Type # to jump to a channel by name, or @ to open a conversation with an agent. The palette now tells you what each of those keys does, so you do not have to know already.
Sidebar groups can now hold channels and direct messages alongside your agents. Put the channel, the conversation and the agent for one project in the same group, sorted and filtered together. Grouped rooms move out of the Channels and Direct messages lists, so each one shows up in exactly one place.
Type @ in a channel or a direct message and a list of everyone in it appears — people first, then agents. Pick one and the message is addressed to them: an agent you name will answer, a person you name just gets told. Arrow keys move through the whole list, Enter takes the highlighted one, and typing narrows it down.
The picker writes the name that actually reaches someone, which is not always the name on screen. An agent called "Mio Clicker PM" answers to @mio-clicker-pm, and typing its full name by hand reaches nobody at all. Pick it from the list and the right thing gets written for you.
An agent that no @ name can reach still shows up in the list, greyed out and saying so, instead of quietly going missing.
Ask an agent how DorkOS works and it looks the answer up instead of guessing. Agents now come with a skill that searches the DorkOS documentation. It reads the one page that answers your question, then tells you which page it came from. When the docs do not cover something, it says so plainly rather than inventing an answer. DorkBot picks this up the next time DorkOS starts. Every agent you create from now on has it too (DOR-661)
Connector packages now stand out in the Marketplace. Packages that connect your agents to services like Gmail or Slack get their own CONNECTOR badge, and a new "Connectors" filter in the sidebar shows only them. The plain "Adapters" filter still includes them (DOR-704)
The features page on dorkos.ai now lists Connections, marked alpha: connect a service once, and you always see where your sign-in lives (DOR-704)
DorkBot now asks what kind of work you do, right after you pick its personality during setup. Answer with a tap or type your own, or skip it and never be asked again. Your answer stays on this machine: it goes to your own agents so they know who they work for, and it is never included in any telemetry payload. Tests hold that line. Every agent session now opens knowing your name, your work, and your tools, once you have shared them. If you set up DorkOS before this question existed, DorkBot asks once in the sidebar, with a one-tap "Don't ask again". (DOR-705)
After you answer, DorkBot suggests a couple of services that fit your work, like Gmail and Greenhouse for hiring. One line, no setup pushed on you. (DOR-705)
Saving your Composio or Nango key now turns that connector on instantly — no restart. Delete the key and it switches off the same way (DOR-371)
Your agent can now connect services when you ask. Say "connect my Gmail" and it replies with the sign-in link and a plain sentence about where your login lives; attaching the account to a session still asks you first (DOR-371)
Accounts connected through your own Nango server now give your agent a tool that can call that service's API — your logins stay in your database the whole time (DOR-415)
Offer a remote tool server as something you can connect to, by listing it in your config file under connectors.rawMcpServers (DOR-371)
A new Connections screen lets you link Gmail, Slack, and other services to DorkOS. Paste your provider key once, click Connect on a service, sign in, and the account appears with a plain sentence about where your sign-in lives. You can hold two accounts of the same service — "Gmail (work)" and "Gmail (personal)" — and disconnect any of them anytime (DOR-708)
Sessions grew a quiet Connectors section in the Session panel: attach a connected account to the session you're in (you see the custody sentence again before you confirm), detach it with one click, and get told plainly when an attached account has expired and needs a reconnect (DOR-708)
Do you use more than one Claude Code account on the same computer, maybe one per client? You can now choose which account DorkOS runs your work on, and switch any time. Your session list shows work from all of your accounts together, and each session is labeled with the account it belongs to. Reopening an older session always runs it on the account that created it. This setting only changes DorkOS. Your terminal and the claude command keep working exactly as before.
Agents in a channel now stay in the conversation after you talk to them, instead of needing an @mention on every message. Ask one something and it keeps answering your follow-ups for about ten minutes, or until five messages from other people have gone by — whichever happens first. Talking to it again starts both over
This is a new setting — Engaged, on the room's quiet-to-loud scale — and you pick it per agent in the room sheet. The other settings are all still there
Two settings control how long that lasts: rooms.engagedWindowMinutes (10) and rooms.engagedWindowPosts (5). Set either to 0 and an agent goes back to needing an @mention every time
You can now see when an agent is working on your message in a room, and when it's taking longer than usual. A line under the message box names whoever picked it up and counts how long they have been at it — "Kai is working on it · 42s". Past three agents it counts them instead, and you can tap it for the names
The line is honest by design. It shows only while an agent really has your message in hand, and it goes the moment the answer lands or the room explains why there isn't one. Nothing an agent decides can switch it on or keep it on
It survives a bad connection. The room repeats the signal every 10 seconds, so opening a room in the middle of a long reply — or coming back after your connection dropped — tells you what is happening within 10 seconds instead of showing you a room that looks empty. If the server stops, the line clears itself rather than sitting there saying "working" forever, and if your browser loses the room's live connection the line goes instead of freezing
You can now reply to a single message in a room instead of answering into the whole conversation. Hover a message and a small toolbar appears on it with "Reply in thread" — your reply gathers under the message it answers, where everyone in the room can follow it without it burying the conversation around it. Threads have always shown up in the cockpit; until now the only way to add to one was through the API
Right-click a message for the same actions, or press and hold on a phone for them to slide up from the bottom. It is the same short menu either way, and the same one the sidebar already uses. On a touch screen the press-and-hold is the only way in — tapping a message reads it, it doesn't offer you a menu
Alongside replying, the menu copies a message's text — telling you it did, or that it couldn't — and offers to mention whoever wrote it, dropping the exact name that reaches them into the message box so you can be sure it will land. Mentioning is left out when nothing would come of it: on your own messages, and on anyone an @ cannot reach
The menu works without a mouse, and it stays out of your way. Tab moves between messages, one press each, however many actions a message has. On the message you're on, an arrow key or Enter steps into its actions, arrows move along them, and Escape comes back. Choosing "Reply in thread" puts the cursor straight in the message box, pointed at that thread
While the box is pointed at a thread it says so, right above where you type, with a way to point it back at the room. It stays pointed there after you send, so a back-and-forth inside a thread does not mean choosing "Reply" again for every sentence
Replying to a reply keeps you in the same thread rather than starting a new one under it. Rooms stay one level deep on purpose, so the conversation reads the same way for everyone
A reply reaches the agents you name in it, exactly as a message to the room does. Say @ana in a thread and Ana picks it up, and answers in that same thread
One line at the top of the sheet says what the room will actually do — "Two agents will answer you here", "Only @mentions get an answer here", "There is nobody here to answer you" — with a small meter beside it. It names the odd one out when there is exactly one worth naming.
Taking an agent out of a room can be undone, the way archiving a whole room already could. Putting it back restores how loud it was, rather than resetting it to what a brand-new arrival gets. Take two out in a row and you are offered Undo for each of them.
A one-to-one says what a second agent would do to it — "Adding a second agent turns this into a group conversation" — before you add one, instead of leaving you to work it out from the faces afterwards.
Agents arrive and leave instead of blinking in and out. An agent you add opens into place and glows once, so you can see where it went. One you remove collapses its row, so the Undo offer refers to something you watched happen. Opening a scale slides it open. An agent that is working has a pulsing dot rather than a still one. All of it stops moving — without anything disappearing — if your system is set to reduce motion.
You can react to any message in a room. Hover it and the toolbar now starts with your three most-used emoji — one click to say "got it" to an agent without spending a message. The 🙂+ beside them opens a searchable picker for everything else, and on a phone a long press brings the same row up in the drawer.
Reactions show up under the message as small pills. Yours are outlined in orange, and clicking one again takes it back. Hover a pill to see who reacted, by name. New ones pop in as they land, and they arrive live — someone reacting in another window shows up in yours without a reload.
Your reaction reaches the agent quietly. It lands in the agent's memory of the room as an acknowledgment: no reply, no new turn, nothing to pay for.
Choose which model new chats start on, and how hard they think. Each runtime gets its own pair of settings, because a model name only means something to the runtime that offers it — so Claude Code, Codex and OpenCode each have their own. Leave them alone and nothing changes: every runtime keeps picking for itself, exactly as before. Set one and every new chat on that runtime starts there, while chats you already have keep what they are running with. OpenCode gets a model setting but no thinking setting, because OpenCode gives no way to ask for more or less thinking and we would rather say so than pretend. Room agents benefit most: until now a room reply had no way to say which model it should run on. You choose them in Settings → Runtimes; on disk they live in ~/.dork/config.json.
Threads now open in a panel beside the room. A message with replies shows one quiet line under it — "↳ 3 replies · last 9:45 AM" — and clicking it opens the whole thread next to the conversation, with its own box to write in. The room's own scroll stays the room's, however long a thread gets. On a phone the thread takes the screen and a Back button returns you.
A thread with replies you have not read shows that line in colour, with a count of what is new. It is worked out from where you left off in the room, so it agrees with the "New messages" line a few pixels above it.
The waiting line follows you in. When an agent is working on something inside a thread, "Kai is working on it" appears in the panel rather than under the room, so the wait is shown where the work is happening.
A thread has an address. The link in your browser bar now names the open thread, so a refresh keeps it open and a link you paste to somebody opens the same thread you were reading.
Give one agent its own model and its own thinking level, instead of one answer for the whole machine. The agent that reviews your diffs can run on the big model while the one watching a room runs on the quick one. What an agent says about itself wins; anything it leaves unsaid falls back to your default for that runtime, and an agent that says nothing keeps working exactly as it did today. Room agents get the most out of this: a room reply now starts on whatever the agent it addressed asked for. You choose them in that agent's Config tab; on disk they live in its own .dork/agent.json.
Settings → Runtimes now lets you choose what a new chat starts with: which runtime, which model, and how hard it thinks. The runtime setting has been in DorkOS all along with nowhere to change it — this is its first screen. Model and effort are per runtime, because a model name only means something to the runtime that offers it. Change anything and DorkOS tells you the truth about when it takes effect: new chats start with it, chats already running keep what they have.
Under that card, every agent that runs on something else. Agents that are simply set up differently are listed plainly; agents whose setup has stopped working — a runtime you have not connected, a model that is no longer offered, a thinking level on a runtime that has none — come first, in amber. Click any of them to land in that agent's own settings. When every agent is on your defaults, the list isn't there at all.
Model and thinking level joined the runtime dropdown in an agent's Config tab, each wearing a small chip that says where the value came from: "server default · Opus", or "set here" when this agent picked its own. The chip is also the undo — click a "set here" chip and the one thing it offers is going back to your default. On a phone the rows open a sheet from the bottom with the same choice at the foot.
Where a thinking level cannot work, DorkOS says so instead of hiding the row: "Not supported by OpenCode", or "This model doesn't take an effort setting". If one is already saved there, it says that too, and lets you clear it.
A Threads list in the sidebar, above your channels. Every thread you started or replied in is there, whichever room it lives in, with the most recently answered at the top. Each row shows what the thread was about, which room it is in, and how many replies it has — so finding your way back to a conversation no longer means remembering which channel it happened in and scrolling for it.
A thread with replies you have not read shows the count beside it, the same way an unread channel does. Reading the room clears it, because a thread shares its room's place-marker.
Clicking a row opens that room with the thread already open beside it, on the exact thread you clicked. The section collapses like the others, and DorkOS remembers whether you left it open.

You are in a thread because you wrote it or answered in it — there is nothing to follow or unfollow, and nothing to keep tidy. The section only appears once you are in a thread, so a fresh install is not given a heading it cannot fill.
A small dot beside a room in the sidebar while an agent is working in it. Ask a question in one channel, go and read another, and you can still see that the first one is busy — without opening it and without wondering whether anything happened. The dot appears the moment an agent picks the work up and goes out when the answer lands.
It is honest about how many: a screen reader hears "2 agents working" when two of them are on it.

The dot is never a guess. It exists exactly as long as real work does, so if DorkOS stops running mid-answer, every dot goes out within half a minute rather than sitting there claiming something is still happening.
dorkos doctor now finds the problems that used to only show up as strange behaviour later: a room whose saved conversation has gone missing from disk (the reason an agent sometimes answers as if it has never met you), agent messaging rules DorkOS could not read, saved chat integrations whose settings are unreadable, chat connections pointing at an agent or an integration that no longer exists, and the same agent id claimed by two different folders.
Those checks need DorkOS to be running, so they live behind dorkos doctor --deep. If DorkOS is not running, it says so and skips them — that is not a problem with your setup.
dorkos doctor --json prints the same results as plain JSON, so you can pipe them into another tool.
dorkos doctor now also checks how many files your system lets DorkOS keep open at once. Too few, and DorkOS starts failing in ways that never mention files.
Rooms now tell you when an agent has gone quiet because it is waiting on you. If it stops to ask permission for a tool, or asks a question, and nobody has answered a minute later, the room says so and points you at its session — instead of sitting there looking busy until the request quietly expires. Quick approvals stay quiet, so a room does not fill up with notes about pauses that lasted seconds.
Every room has a Stop button in its header while agents are working. It stops the work; it is not something you can ask for in a message, because an agent stuck in a loop will just reply to that.
When your agent asks permission and you answer, the card now settles into the conversation as a receipt — a one-line record of the ask and your answer, right where it happened. Allowed and denied requests say so by name; a request nobody got to says it expired and how long it waited. Answering several at once leaves one line with the details a click away.
When DorkOS decides not to do something — an agent skips a message, a room runs out of automatic replies, a prompt times out with nobody watching — it now writes one line saying exactly why. The ones you were never told about are recorded as warnings, so they stand out instead of blending into the ordinary chatter. That is what makes "the room just went quiet and I don't know why" a question with an answer.
New: dorkos debug answers the questions you can only ask while DorkOS is running. Which agents are working right now and for how long, what was recently declined and why, which conversations have a live connection, and whether a room's agents still have their history on disk. It reads ids, counts and times — never the text of anything anyone wrote — and stores nothing. Run dorkos debug --help to see the subjects.
Reopening a conversation now shows the permission asks and answers, right where they happened. What you allowed, what you denied, and what ran out of time before anyone got to it are kept with the turn they belong to, so the record is still there tomorrow — not just for as long as the tab stays open.
Turning on Full autonomy now asks you to acknowledge what it means — once, if you tell it to stop asking. Tick Don't show this again and DorkOS writes down the date and stops asking; leave it unticked and it asks again in your next conversation, as before.
Settings → Security shows the date you acknowledged it, with a Reset button. Resetting brings the confirmation back the next time you reach for Full autonomy, and takes effect everywhere within about half a minute — a tab you left open can skip it once more before it catches up. It changes nothing about a conversation that is already running — only the asking comes back.
Tell DorkOS how much new sessions may do — once. Settings, in the card that already holds the model and effort a new chat starts with, now asks where new chats should start: Ask first, Act, or Full autonomy. One choice covers every agent you run — the three words mean the same thing whichever one you are talking to — and underneath, a line per runtime says what that choice actually means for it, including where a runtime cannot pause to ask. Ask first stays the out-of-the-box default, and chats you already have keep what they are running with. Changing model, effort, or trust level before your first message no longer silently locks the chat to Claude Code: the runtime you actually start on is what applies.
Something different for one agent? "Customize per runtime" opens a row for each, with the same dial and a way back to the shared setting.
Make it the default right where you decided it. After you change a chat's trust level, a quiet line appears under the dial for a few seconds — Start every new session in Act? Make default · Dismiss — so the habit is caught where it happens instead of costing you a trip to Settings. It stays quiet when that stop is already where new chats start, and it takes no for an answer for the rest of the conversation.
Full autonomy is a choice you acknowledge once, in Settings or right where you just made it. DorkOS asks what it means at the moment you choose it and writes down that you read it; from then on new chats start without asking, and Settings keeps a quiet note saying so with a link to change it back — naming the agent, when it is only set for one.
Say why you said no. When an agent asks permission and you want to refuse, the approval card now offers Add a reason — one line, entirely optional. What you type goes to the agent with the refusal, so instead of trying the same thing again it can take another route. Deny on its own still works exactly as before: click Deny, press Esc, and nothing slows down.
The transcript says whether the agent heard you. A denial you explained reads You denied rm -rf node_modules — agent was told why. A denial you did not explain says only that you denied it, and a request that ran out its ten minutes still reads Expired — denied, because a clock explains nothing. The line only claims the agent was told when the reason actually reached it.
DorkOS now tells you when something is running without asking and nobody is there to answer. If a chat integration or a scheduled task is set to Full autonomy, a quiet amber line sits under the header on every page: The Deploys integration and the Nightly cleanup task run without asking. Nobody is watching, so nothing waits for your approval. It names them rather than counting them, and puts a button beside the words that takes you to the integration or the task so you can change it in a couple of clicks.

This is the one place that fact had no home. A chat you are sitting in front of shows its trust level in the status strip, right where you are looking. A schedule that fires at 3am and an integration that answers a message from your phone show it only on the screen that configures them — the screen you are not on. The banner appears the moment you turn one on, stays while it is true, and disappears on its own when you dial the last one back. There is nothing to dismiss and nothing new to configure.
See every file and link your agent touches, live. Each reply now carries a row of small chips — one per file, page, or command the agent handled — and each one moves the way its job moves: reading sweeps across the name, searching passes a beam through it, editing scribbles and counts the lines as they land, a new file draws its own outline, a deleted one is swallowed by the bin and stays behind, struck through, so a deletion is never invisible. The moment a job finishes, its chip goes still. Nothing you can see moving is over.
The row stays short, and nothing gets lost. Only the four newest chips stay out front; older ones slide into a small pile beside them that counts what it holds. When the reply is done, the whole thing folds into one quiet line — 📖 21 · ✏️ 3 +34 −11 · 🌐 9 — and show all opens the full list, which you can filter by what happened and read either grouped or in the order it happened. A file that was read and then changed does not get a second chip: the one already there turns into the edited one where it stands.
Click a chip to open that file or page beside the chat. Hovering one tells you the whole story of it — every time it was touched, in order.

Changed

When your agent's sign-in stops working, chat now shows a clear message with a "Fix sign-in" button that takes you straight to Settings to sign in again, instead of a raw error. Works for Claude, Codex, and OpenCode.
You can now change how OpenCode is powered without disconnecting first. A connected OpenCode shows a Change link that reopens the power-source picker with your current source labeled ("Currently: On your computer (Ollama)"), so switching from your own computer to the cloud, or the other way, is one clear choice (DOR-427).
The model menu for local (Ollama) models now offers only the models that are actually on your computer, so you never pick one that isn't installed and watch the turn fail. Add more models from the local panel as before (DOR-427).
Status bar settings now sync, and your agents can change them for you. What the status line shows used to be saved only in the browser you set it in. Now it lives with the rest of your settings, so a choice you make in one window shows up in your others and in the desktop app, and you can just ask an agent to change it. In this same release the ten per-item on/off switches became a single list of pinned items, so read the status line entry for what that means and what carries over (DOR-431)
A runtime that shows "Ready" now still lets you fix its sign-in. "Ready" only checks that a key or login exists, so a stale key or an expired login can still read Ready. Open Settings, then Runtimes, and use the quiet "Fix sign-in" link (or "Change" for OpenCode) to sign in again or paste a fresh key, without disconnecting first.
The message box no longer greys out while the session is busy, so your cursor and your place in the text stay put. Sending is still held until the session is free (DOR-452).
Opening a session on a phone or tablet no longer pops the keyboard and scrolls the page — the message box only takes focus on desktop (DOR-452).
The hints under the message box now teach the backslash trick and stop rotating after you have seen them three times through. "Press Esc twice to clear" is gone; we would rather not advertise the destructive one (DOR-452).
The status line is now quiet by default: it shows who you are talking to, which model is answering, and which folder it can touch — and stays silent about everything else until there is something to say. Context appears at 70% full, git when the tree is dirty or you are off the default branch, permissions when they are not the default, runtime when it is not the usual one, usage when you are near a limit, and connection when the live link drops. A number that always reads 34% is wallpaper, so the 91% that matters would not register either (DOR-452).
The status line is one row with two sides at every screen size: who and where on the left, state and numbers on the right. Nothing is centred on a phone and left-aligned on desktop any more, and no separator is ever left floating in the gap between the two (DOR-452).
The status strip above the message box — "Waiting for your approval", the thinking verbs, the post-turn summary — no longer re-centres itself on narrow screens (DOR-452).
The status line now measures the space it actually has and fits itself to it, instead of guessing from the screen size. On a narrow window it keeps the things most likely to be a real problem — a dropped connection, a nearly-full context window, a usage limit — and shows how many it left out as a small +2 beside the ⋯. Everything it left out is still in the Session panel, one tap away (DOR-452).
Status items are easier to hit on a phone: every one of them, and the ⋯, now has a touch-sized target (DOR-452).
Chat now shows who sent each message, with day and unread separators.
Every message has an avatar and a name on the left, and a run of messages from the same sender groups under one header — the layout you already know from Slack. This replaces the old right-aligned bubbles for your own messages, which could only ever show two sides of a conversation.
The list separates itself by day, so you can tell at a glance when something happened. If a conversation moved on while you were away, a "New messages" line marks where you left off.
On a narrow window the status line now says things in fewer words. The runtime drops the model name the item next to it already shows, the model drops its effort and Fast tags, and a long trust level gets shortened — all of it still spelled out in full in the Session panel. "Default (recommended)" now reads "Default" everywhere: the parenthetical is advice for picking a model, not news about the one you picked (DOR-452).
Anything still too long for the row now ends in an ellipsis you can see, instead of being cut off where nothing hinted it was there (DOR-452).
Marketplace installs, uninstalls, and new packages requested by an outside agent now go through the same approval card as everything else, so there is one place to look and one way to answer. You get two hours to decide instead of 5 minutes (DOR-447).
The Agents page now shows your fleet in attention order: whatever needs you leads, instead of an alphabetical inventory list. Rows group into Needs you, Working, and Quiet. Pick a different sort, by name for example, and the groups flatten.
Working now reflects chats across your whole fleet, not just the project you happen to have open. An agent counts as working when a chat in its folder is live, or was live within the last hour, even while you are looking somewhere else.
Each row now says what the agent last did, in plain words: "Finished a reply", "Got a message", "Cannot be reached". The time it happened sits underneath. If a chat with the agent is waiting on you — for a permission you have not answered, or after an error — the row says so and moves to the top.
A new Scheduled column shows how many scheduled tasks are waiting on each agent. An agent that has gone quiet for a day with tasks still scheduled is flagged as needing you, because those runs are failing.
The Status and Sessions columns are gone. Health now shows in the group a row sits in, the ring around the agent's avatar, and the row's own wording — three quieter signals instead of the same word repeated down the page. You can still filter by status. The old session count was never a count of open chats, so nothing replaces it.
The agent's runtime and project moved under its name, which frees up room and makes the page much easier to read on a phone.
A long request on an approval card is trimmed to two lines, so the Allow and "Don't allow" buttons stay where you expect them (DOR-448).
If DorkOS cannot check what is waiting for your approval, the dashboard says so and offers to try again. Before, a failed check looked exactly like having nothing to answer, which could leave an agent waiting on you with nothing on screen (DOR-448).
Uninstalling a marketplace package now asks you once, not twice (DOR-448).
When a conversation has to be restarted under a new id — which can happen when an older chat is reopened and cannot be picked up where it left off — the list now shows only the one you would actually land in. Before, the old entry stayed in the sidebar and quietly opened the newer conversation instead, showing the older one's trust level. If a chat you remember seems to have vanished, look for the newer entry with the same conversation in it; nothing is deleted.
The relay_inbox tool now says plainly that ack destroys the messages it hands back. The content is deleted and cannot be recovered, so an agent that wants to look without clearing should leave ack off. (DOR-506)
The tool approval guide used to say DorkOS agent tools skip the approval card "because these tools cannot modify state". That was not true of relay_inbox, which deletes messages when it acknowledges them. The guide now gives the real reason: these tools carry their own permission checks, and an agent polling its inbox all day would bury you in cards you would soon dismiss without reading. (DOR-506)
Standing permissions need Require login on. Without it DorkOS cannot tell you apart from an agent running on the same computer, so the control is shown but switched off, with the reason and the fix right above it. Turning the feature off ends every permission that is live, and says so before it does (DOR-501)
When DorkOS turns down an answer you gave on an approval card, it now tells you what actually happened instead of "Action failed". The case that matters most: if the action went ahead but the permission could not be saved, it says so plainly, so you never repeat something that cannot be undone (DOR-501)
If DorkOS cannot check which standing permissions are live, both places that list them say so and offer to try again, rather than showing an empty list that reads as "nothing is trusted" (DOR-501)
The Settings tab where you set up Telegram, Slack, and webhooks is now called "Integrations" instead of "Channels" — same setup, clearer name now that "Channels" means something else in DorkOS (Slack-style conversations, which now sit in the sidebar).
Each agent's "Channels" section, where you link it to Telegram, Slack, or a webhook, is now called "Integrations" too.
A session badge that used to read "Channel" for messages arriving from Telegram, Slack, or a webhook now reads "Integration".
Our own documentation described a few protections DorkOS does not have, and oversold some it does. The protections were never missing; the writing was wrong. Fixed:
- Three things an agent cannot take back, not one. The docs said removing an installed package was the only action that stops and asks you. Deleting a scheduled task and removing an agent stop and ask too, and have since the permission gate was widened. One page even said an agent could delete a scheduled task without asking, which was the opposite of what happens.
- Bypass permissions does not turn everything off. It skips the prompts inside a session, so an agent edits files and runs commands without stopping. The three actions above still wait for your answer.
- Tool group switches are guidance, not a lock. Turning a group off changes what an agent is told about, so it stops reaching for those tools. It does not take the tools away. The pages that called this "controlling which tools an agent can access" now say what it does.
- Every protection now names the login it depends on. With Require login off, which is how DorkOS starts, DorkOS refuses the agent that asked for something but cannot tell you apart from other software running as you on the same computer. With login on, only your signed-in account can answer. Both are real, and the docs used to state only the stronger one.
- "Secure by default" is gone. In its place, the narrow claim that is actually true: DorkOS listens only on your own machine by default. We deliberately did not replace it with "sign-in required the moment you expose it", because that is not true of our Docker image: the image binds to every network address and switches off the guard that would otherwise refuse to start without a login, which our Docker guide already told you.
- Tool group switches are per-agent, but permission is not. One thing genuinely is per-agent: a standing permission you grant from an approval card covers one agent doing one action, so two agents can meet the same gate and get different answers.
The Security page has a new section on what an agent cannot do without asking you, including the limit, and the Threat Model now explains the three permission labels, where the approval gate sits, and the two ways traffic can reach DorkOS without passing the bind guard.
The 0.8.0 release post carried the strongest version of the tool-switch claim. Rather than quietly rewrite a dated announcement, we left the wording and added a correction note at the top of it.
The desktop app keeps only the tab you are looking at connected to its agent. Background tabs let go, then pick the conversation back up with nothing missed the moment you return. A window full of tabs costs no more than one
On the desktop app, the Window menu now says "Close Tab" for Cmd/Ctrl+W, because that is what it does. "Close Window" still closes the whole window
The desktop app now runs on http://localhost:4242, the same address as the command line, instead of a new random one every time you open it. Bookmarks and MCP setups keep working from one launch to the next. If something else already has that port, DorkOS takes the next free one and Settings shows you where it landed (DOR-539)
You can pin the desktop app to a port of your own with dorkos config set server.port 5000, the same setting the command line reads. A port you pick this way is one DorkOS stays on: if it's taken, the app says so instead of quietly answering somewhere else and breaking whatever you pointed at it (DOR-539)
Settings → Server now says when it can't reach the server, and offers to try again, instead of showing an empty panel (DOR-539)
Changing who is in a room, or how an agent behaves in one, is now something only you can do. Agents used to be able to do both, which was harmless when nothing acted on it — now that a message makes agents reply, an agent could have used it to start a conversation nobody asked for (DOR-526)
Asking for a conversation you already have opens that one instead of making a second copy. DorkOS now recognises a direct message by exactly who is in it, so picking the same people again takes you back to the same place, history and all — and if you had archived it, it comes back out. It keeps its name and its place in the list, because opening a conversation is not the same as something happening in it. "You and Ana" and "You, Ana and Kai" are still different conversations, so every agent stays available whether or not it already has one (DOR-571)
If you drive DorkOS through the API, POST /api/rooms now answers 201 when it made a room and 200 when it handed you one that already existed. The two replies look identical otherwise, so this is the only way to tell a brand-new conversation from one with a month of history in it (DOR-571)
DorkOS now sends us nothing unless you turn it on. The daily heartbeat, marketplace install counts, and feature-usage events used to be on by default. All three are off, and they stay off until you say yes in the Privacy & Data settings tab or with dorkos telemetry enable. If you already chose to keep sharing, your choice is kept exactly as it was and nothing changes for you. If you never answered, sharing stops
The first-run notice now explains what you could share and how to turn it on, instead of telling you sharing is about to begin. On a machine you set up for someone else, DO_NOT_TRACK=1 still keeps everything off no matter what the settings say
A chat integration binding that never had a trust level picked for it now prompts, instead of quietly auto-accepting. Bindings you already configured keep the setting they had. If a channel of yours starts asking about shell commands it did not ask about before, that is this change, and you can set the binding to "Bypass permissions" if that channel is one you trust (DOR-604)
Renaming a channel now changes its #name too. Before, the new name was saved but the sidebar kept showing the old one.
Archiving a room asks first, and the confirmation comes with an Undo so you can bring it straight back. If the Undo can't work — someone took the name meanwhile — it now says so instead of a blank "Action failed".
A channel you archived can come back under a different name when something else took its old one. Before, it could not come back at all.
Deleting a task now also deletes its run history, and that is permanent. Before this, deleting a task with any run history simply failed with an error, so nothing was lost — and nothing was deleted either. Two knock-on effects worth knowing: the runs are gone from the task's history for good, and any chat session that task started will no longer show that it came from a task.
Naming a new task "Templates" is now refused, with a message asking for a different name. That folder name is reserved for the starter tasks.
To pause a task, switch it off. Marking a task "paused" directly is no longer accepted, because it never lasted — DorkOS uses that mark for its own purposes, such as noting that a task's file has gone missing.
If you already have a Telegram bot in a group chat, it will now be quieter. It used to reply to every single message. Now it replies when someone mentions it by name (@yourbot), when someone replies to one of its messages, and when someone sends it a command. It stays quiet the rest of the time.
One-on-one chats have not changed. Your bot still replies to everything you send it directly.
You can change this. Open Settings, go to Integrations, click Configure on your Telegram bot, and continue to the second step. Under "Replies in Groups", choose "Every message" to get the old behavior back.
Anonymous group admins still get replies. Telegram sends their messages in a way that looks like a bot, but they are people, so your bot treats them like anyone else in the group.
Your agent's instructions now explain the marketplace tools (search, install, and the rest) the same way they already explain relay, mesh, adapters, and scheduled tasks. Marketplace was the only one missing this, so an agent had less to go on when deciding how to search for or install a package (DOR-529)
The install preview describes what a scheduled job may do in plain words, like "can run any command without asking you", instead of showing a setting name only a developer would recognise (DOR-635)
If a package declares commands in a form DorkOS cannot read, the preview says so. It used to show nothing, which looked exactly like a package that runs no commands (DOR-635)
An agent answering in a channel or a DM now knows who else is there, and which of them are people rather than other agents. It also gets the room's topic, the messages it has not read yet, what it said there recently, and how many automatic replies are left. Before this it got the one message and nothing else, so it could not tell a colleague from a bot and had no way to follow the room's etiquette rules. (DOR-622)
The message an agent receives is now exactly what the person typed. DorkOS used to wrap a sentence of its own around it, which then showed up in the session transcript as words nobody wrote. (DOR-622)
A name nobody in the room has stays ordinary text. @99 in "refunded @99" is a number, and an email address is an email address — neither is a failed mention, so neither is treated as one. Pressing Enter sends the message as usual.
Replies in a channel now gather under the message they answer, behind a small "3 replies" line. Threads used to be separate rooms you opened on their own, so following one meant leaving the channel and coming back; now you read the whole conversation in one place.
When the message a reply answers is older than the history that has loaded, the reply says "Replying to an earlier message" rather than reading like a new remark. Old links that pointed straight at a thread still open the channel it lived in.
The command palette lists your channels, not every thread inside them.
Threads finished moving into the channel they came from. If you ever started one, its messages are now replies under the message they answer, in that channel, instead of sitting in a room of their own — so there is one conversation to read and one unread count instead of two. If you were caught up before the upgrade you are still caught up. If you were behind, your unread count can come out a little high — it may include a reply you had already read inside the thread — and one visit to the channel clears it; erring that way is deliberate, because hiding something you have not read is the mistake you cannot undo. Most installs have never started a thread, and for those this changes nothing at all. (DOR-634)
New agents joining a channel now get the new mode instead of "only when @mentioned". Agents you add to a direct message are unchanged
Existing channels were switched over too. Every channel this changed gets one message in it explaining what happened, so nothing widens quietly — and an archived channel, which cannot be given that message, was left alone entirely. Any agent you had deliberately set to something else — always, never, or direct messages only — was left exactly as you set it
Being asked something inside a thread keeps an agent in that thread, not in the whole channel. And talking to it in the channel does not pull it into every thread you have open
If an agent posts to the room while it is still working on a slow reply, that post now counts as part of the same conversation. A question it asks another agent there gets picked up, where before it was quietly dropped. This can mean one extra reply in a conversation that used to end early
You can finally see and understand when each agent speaks. The members panel is now a room sheet, and it holds everything about the room in one place: its name and topic at the top, one line saying what the room will actually do, everyone who is in it — you included — a row that adds an agent, and when the room was made. Archiving is at the foot.
How loud an agent is has become a scale you point at. It used to be five sentences that all began with "Replies", in an order nobody could work out. Now each agent has a spot on a quiet-to-loud scale — Silent, @only, Engaged, Everything — and pressing it opens the scale with the real rule written underneath, including the actual number of minutes and messages your DorkOS keeps an agent talking after you mention it, read from your own settings rather than guessed.
A one-to-one gets the same four settings a channel does. Engaged — answers when you say its name, then keeps answering for a while — is offered in a direct message too. Add a second agent and it is still a direct message, and it is exactly the room where you want an agent that answers when spoken to and then goes quiet.
Point at a setting and the room tells you what it would become. Move the mouse across the scale, or arrow through it, and the line at the top of the sheet shows what the whole room would do if you chose that — tinted to say it is a "what if". Stop pointing and it goes back. Nothing is saved until you actually pick one, and an archived room shows no such preview, because nothing would be true.
A change lands the moment you make it. The meter moves straight away instead of waiting for the server. While it saves, the setting dims; if the save is refused it goes back to what is really stored and says why — so you are never looking at a value that was never saved.
Each person or agent is a line, not a card, with its face, what it is doing right now or the last thing it did here, and its loudness on the right. Agents carry a small robot mark; people carry none.
A room's name and topic are edited where you read them. Press the line, type, press Enter — Escape puts it back. A channel with no topic says "Add a topic" instead of leaving a gap.
Adding an agent is the last row of the list of who is in the room, rather than a second panel with its own heading. Press it and it becomes the picker, cursor already in it.
An archived room stops pretending. Every meter goes grey, the scales cannot be changed, and there is no way to add or remove an agent — nothing is triggered in an archived room, so its members and their settings are on hold until you bring it back. The settings are still shown, because they are what each agent will do the moment you do, and the sheet says so where a screen reader will read it too.
Opening the sheet for a room with nobody in it opens the picker straight away. A room with nobody in it does nothing, so putting somebody in it is the only thing worth offering. "You have not added any agents yet" now comes with a Create agent button, and a roster that could not be read now offers Try again instead of asking you to close the sheet and open it again.
Rows in the roster are taller on a touch screen, so a face and two lines read as a person rather than as a dot with a caption.
Every agent picker now shows who it is offering. Choosing agents — for a new channel, a new conversation, or a room you are already in — used to be a plain alphabetical list of every project folder you own, with no faces at all. Each agent now carries the same face it has everywhere else in DorkOS, and, where you have written one, its own description on a second line. Two agents can share a name; that line is what tells them apart by what they do. An agent you have not described simply has no second line, and an agent DorkOS cannot read gets a plain letter rather than a made-up face that would match nothing else on screen.
Starting a conversation when you have no agents yet offers a Create agent button instead of telling you to go and add one somewhere else.
A conversation has one place to be read. Replies never pile up inside the room; they live in the thread panel, so however long a thread gets it cannot push the room off screen. Every reply is in the panel, including every reply written before this release.
"Reply in thread" opens the thread and puts the cursor in it. It used to quietly re-point the room's own box at a thread, with a small banner above as the only sign of where your next sentence was going. Now you type in the thread, so there is nothing to misread.
An agent taking a turn inside a thread is told its answer lands in the thread rather than in the room's main flow, so it writes for the conversation it is actually in.
OpenCode chats no longer carry a thinking level anywhere. OpenCode gives no way to ask for more or less thinking, so the setting was only ever handing you back what you typed — it is no longer saved, shown, or inherited from an agent. We would rather say it is not supported than pretend it does something.
An agent set up to run on a runtime you have not connected — or to think harder on a runtime with no such setting — now shows up under Needs attention in the sidebar, next to the chats waiting on you. You should not have to open Settings to find out that an agent cannot start. A model that is no longer offered is a quieter problem and stays in the list under your defaults, where checking it does not cost a lookup per agent.
The very first chat DorkBot starts during setup now runs on your default runtime. It used to always say Claude Code, even if you had chosen something else.
First-run setup now points new chats at the coding agent you actually have. If Codex is the only one connected when the setup check finishes, DorkOS starts new chats with Codex instead of quietly assuming Claude Code. The sentence on that screen says which one it picked — "Codex is connected. New chats will start with it." — and a Change link right under it switches to any other agent in one tap — including one you have not connected yet, in which case the screen tells you which agent your chats will use in the meantime.
It waits for the check to finish rather than deciding the moment DorkOS opens, because you can connect an agent from that very screen and the answer changes when you do.
The pick happens once, on your first run, and never again. Reopening setup, refreshing halfway through, or installing another coding agent later will not move the setting behind your back. From then on it is yours, and Settings → Runtimes is where you change it.
Slack now shows you when an agent has actually picked your message up. Your message gets an 👀 reaction the moment an agent starts working on it, and loses it when the answer lands or the attempt fails. Before, the reaction was an hourglass added the instant your message arrived — which meant a message nobody ever picked up still looked like it was being worked on. Now the mark means somebody is on it.
Nothing is added when the work finishes — no green tick, no red cross. The reply is the answer, and the error message is the failure.
If an agent stops to ask you something mid-answer, the reaction comes off while it waits and goes back on the same message when it carries on.

Setting the working indicator to None still turns all of this off, and still makes zero calls to Slack.
Cross a room a message at a time with Page Down and Page Up. A busy channel used to take a Tab press for every message, plus another for every thread, before you reached the box to type in. Now the history is a feed: Page Down and Page Up move message to message however many buttons, reactions and replies each one carries, and Ctrl+End jumps straight to the composer. Every message also says who wrote it and where it sits — "12 of 30, Ana" — so a screen reader reads a room as a conversation instead of one long wall (DOR-757).
Messages now say who wrote them everywhere they appear, threads included, so a screen reader can find its way around one without reading everything either side of it first.
Arrow keys scroll a long message again. Up and down used to be taken by the message's own action buttons, so a message taller than the window could not be read through without moving off it first. The buttons are still one press away with Enter or the right arrow.
Cross an open thread the same way you cross a room. The thread panel is now a feed of its own: Page Down and Page Up move from the first message to each reply, Ctrl+End jumps to the box you reply in, and Ctrl+Home goes back to the button that closes the panel — so leaving the thread never drops you into the room behind it. Each message says where it sits in the thread, and the panel says it is still loading when you open a link straight to one (DOR-780).
Cross a session's conversation a message at a time with Page Down and Page Up. A long chat used to be one press per message and everything in it before you got anywhere; now the transcript is a feed, so one press moves to the next message however much it carries, and Ctrl+End jumps out to what is below it. Every message says who wrote it, when, and where it sits — "12 of 30, DorkBot" — so a screen reader reads a conversation instead of one long wall (DOR-779).
An answer that is still being written is now read out as it arrives, sentence by sentence, instead of the whole answer being repeated on every word. When the turn finishes, only the last few words that were not yet spoken are — the message is never read from the top a second time.
Waiting for a conversation to load is now announced rather than silent.
An unreadable chat integration now says out loud that any bot token inside it is still sitting in the file in plain text, rather than leaving the file looking protected when it is not.
The relay's Activity panel counts honestly. A message sent to something nobody is listening for is now "No listener" rather than a failure, so a quiet machine stops showing a wall of red; failures carry the reason they failed; the dead-letter count reads from the actual queue instead of always showing zero; and connecting or reconnecting an integration no longer counts as delivered traffic.
Auto works again on models that support it. The same lost flag had been quietly running "auto" sessions at the default trust level and hiding "auto" from the picker; both now behave as selected.
The fast-mode toggle appears for models that support it — the flag that showed it was lost the same way.
Starting DorkOS prints less. A healthy start used to write eleven near-identical lines about routes being set up; now it writes one that names what came up. Nothing else about starting changed — there is just less to scroll past before the part you were looking for.
Every trust level a runtime offers now says what it actually does — when it stops to ask you, how far it can reach, and one plain sentence about the consequence. Warnings on screen are worked out from that instead of from a list of mode names kept in the app, so a mode a new agent invents is described correctly the day it arrives. Nothing looks different yet, with one exception: Claude's Auto mode is no longer tinted red. It still raises an approval card for the risky calls, and red is now reserved for the one setting that never asks about anything, anywhere. Your pick is validated against that runtime's own declared mode list, not a fixed set.
Choosing how much your agent may do is now one dial with three honest stops — Ask first, Act, and Full autonomy — instead of a list of six engineering words. Under it, one line says what that stop means for the agent you are actually talking to, in its own words. Where an agent cannot keep the stop's promise, the line says so in amber rather than quietly hoping you find out later: on Codex, "Act" runs shell commands without asking, because Codex has no way to pause and ask.
A stop an agent cannot take simply is not offered, and a session sitting at a setting the agent no longer has now says which setting that is instead of showing an empty dial.
Full autonomy asks once before it takes effect, and says what that means for the agent in front of you. Every other stop applies straight away — this is the one you cannot walk back, so it is the one that asks. Arrow keys stop at the ends of the dial instead of wrapping around to it.
Plan moved out of the permission list and next to the composer, where you can switch it on for a stretch of work and off again. Turning it off puts you back at the stop you were on — or to the agent's normal setting if the old one is no longer available. It appears only for agents that can plan, and it is in the Session panel too, so a narrow window cannot take it away.
Auto is no longer a setting of its own. It is a switch inside Act, on the models that can run it — the same one-time confirmation as before.
Choosing what an agent may do looks the same everywhere now — and always tells the truth for the runtime it runs on. Integration bindings and scheduled tasks used to ask this question with their own hand-written lists; both now use the same three-stop dial as a chat session, with the same honest line underneath about what the stop means for that agent.
The integration binding's list said "asks before running shell commands" for every agent, which is false for agents that cannot pause to ask, and offered Plan as a level of trust — which it is not. Both are gone.
Turning on Full autonomy for an integration or a schedule now asks first, and says what stops happening on that surface: an integration gives up the answer it would have waited for, and a scheduled run gives up the approval it would have raised.
A schedule that still stops to ask now says so plainly: nobody is watching a scheduled run, so anything it stops to ask about is refused after 10 minutes and the run carries on without it.
Both screens say what they are set to and why there is nothing to pick, when DorkOS hasn't heard from the agent behind them yet — instead of showing a picker built on nothing.
Install previews describe a package's schedule in words that hold for every agent, instead of describing Claude Code and hoping the reader is on it.
The confirmation is no longer something a screen can skip. DorkOS itself now turns down any attempt to put a conversation into Full autonomy without your acknowledgement, so a second tab, a stale window, or a stray keystroke lands on the same question instead of quietly getting through. If that happens, the confirmation opens rather than an error you cannot do anything about.

This is a confirmation for you, not a lock against your agents: it makes sure a person cannot arrive in Full autonomy without having been told what it means. Scheduled tasks, chat bindings and rooms are unaffected — they never used this setting and keep their own, stricter rules.
Reset takes the Full-autonomy default with it. The note DorkOS keeps of you reading what Full autonomy means is what lets new chats start without asking, so pressing Reset in Settings → Security now also turns that default off. Otherwise new chats would keep opening without asking while DorkOS had no record that anybody agreed to it — and the first time you tried to change one, it would ask you to confirm something you thought you had just switched back on. Chats you already have are untouched, and a gentler default (Ask first, Act) is left exactly as you set it.

This is for the chats you open yourself. Scheduled runs, chat integrations and rooms keep their own settings and their own, stricter rules — nothing here reaches them.
The button on a running job says Stop, matching what it does and what DorkOS says back when you press it. (DOR-808)
Any setting that stops the asking now asks you first — not just Full autonomy. Some agents cannot pause mid-turn to ask permission. On those, the middle setting ("Act") still edits files and runs commands in your project, it just never checks with you first. Until now only the top setting stopped to confirm, so you could land in a mode that asks nothing without ever being told. Now DorkOS confirms before it turns on any setting that will not stop to ask and can do more than read — in a chat, on a chat integration, and on a scheduled task alike.

The confirmation says what is true of the setting you picked rather than borrowing the loudest words: it keeps the name you pressed, adds the one sentence that matters ("This stop never pauses to ask. Whatever it decides to do, it does."), and shows your agent's own description underneath. It also carries the line that was previously only shown for Full autonomy — that this covers tools inside the chat, and DorkOS's own actions, like removing a package, still ask you. A read-only setting is left alone: it never asks because there is nothing to ask about, and a confirmation in front of the safest choice is how confirmations stop being read.

If you have already ticked Don't show this again, nothing changes: that one answer covers all of it, and you can bring the question back any time from Settings.

Removed

The "Show shortcut chips" setting and the / and @ chips below the message box are gone. The rotating hints already teach both, and the agent you are talking to still shows there (DOR-452).
The Configure status bar panel and the Status Bar tab in Settings are gone, along with their ten on/off switches and the right-click "Hide this item" menu. Pins in the Session panel replace them: one thing that adds, instead of ten that only ever subtract. Diagnostics rows deliberately have no pin (DOR-452).
Heads up: those ten show/hide choices are cleared, once, by this release — they are not carried over as pins. The two settings mean opposite things, so there is no honest way to convert one into the other: everything used to show unless you hid it, and now nothing shows unless it has something to say or you pinned it. Carrying "shown" over as "pinned" would have pinned all ten items for anyone who never touched the switches, which is exactly the noisy status bar this release removes. Pin what you want back from the Session panel (DOR-452).
Swipe-to-collapse on the status area is gone, along with its drag handle and the "Swipe to collapse" hint. It existed because the status area used to be up to five rows tall; it is now one row of at most a few items, so there is nothing left to collapse (DOR-452).
Installing a marketplace package always waits for you to say yes, and there is no longer a way to switch that off. A setting called MARKETPLACE_AUTO_APPROVE used to skip the question for scripts and CI runs. It is gone. If you install packages from a script, have the script answer the request the way the app does: read GET /api/approvals/pending, then POST /api/approvals/:id/grant, and retry the install. If you have Require login turned on, that script needs a per-user API key (from the Security tab in Settings) to make those calls at all. If you have cloned the DorkOS repository, contributing/external-agent-marketplace-access.md walks through it step by step.
Dropped three keyboard shortcuts from the shortcuts panel (⌘1, ⌘2, ⌘3) that were listed but never did anything — the sidebar tabs they pointed at no longer exist (DOR-534)
The separate topic dialog. "Edit topic…" now opens the room sheet with the topic line ready to type in, instead of a window holding one text box.
The app-wide "all permissions bypassed" banner that sat above every page while the session you were looking at ran with permissions bypassed. The session's own status line already carries the word and the colour, for as long as the session is in that mode, and two alarms about one fact teach people to read neither.

Fixed

When a session's saved model is no longer available (you switched where models come from, or removed one), the model menu now marks it "not available" and asks you to pick another, instead of silently failing (DOR-427).
If a turn does run against a model that isn't available, you now get a plain message pointing you to the model menu instead of a raw error from behind the scenes (DOR-427).
First-run setup no longer snaps back to the Welcome screen partway through. Meeting DorkBot and settling its personality now carries you straight to the handoff instead of dropping you at the start.
The first-run setup check no longer says Claude is connected when it isn't. If the Claude Code tool is installed but you haven't signed in, DorkOS now shows the sign-in step instead of a green checkmark, so your agents can actually start work. Signing in with your Claude account or adding an Anthropic API key both count as connected.
Install and download spinners now actually spin instead of sitting frozen, so it's clear when something is working (DOR-439).
Pressing Enter to accept a Japanese, Chinese, or Korean candidate no longer sends the half-typed message (DOR-452).
Pressing Escape to close the command or file list no longer stops the agent mid-answer, and no longer arms a second Escape that wipes your draft. Clearing now takes two plain Escapes (DOR-452).
Hiding a status item and bringing it back no longer leaves it with a stray dot in front of it (DOR-452).
Opening a status item's menu no longer closes it the instant another item appears or disappears (DOR-452).
The "Compact now" nudge now animates away instead of vanishing (DOR-452).
The keyboard shortcuts panel called Cmd+. "Toggle canvas"; it toggles the right panel (DOR-452).
Status items that did not fit used to be genuinely unreachable on a phone — the row looked scrollable and faded at the edge, but a gesture on the row above ate the swipe. The line no longer scrolls or wraps at all, so nothing can hide there (DOR-452).
A screen reader now announces what the strip above the message box says — "Waiting for your approval", a finished turn's summary — instead of staying silent. The parts that tick every second, like the thinking verbs and the timer, stay quiet so the announcement is not drowned out (DOR-452).
Changing the model or trust level from the status line now updates every part of the screen at once. Before, one place showed the new value while another kept the old one until the server replied.
The Tasks page now sorts by which task runs next when you first open it, and the sort button says so. It used to show "Sort:" with nothing after it.
CLI commands work again when your DorkOS asks you to sign in. dorkos agent, dorkos task, dorkos activity, dorkos call, and dorkos version --check sent nothing to prove who you were. On an instance with login turned on, every one of them stopped with a bare "Unauthorized". Your agents in Codex and OpenCode lost their only way to act. The CLI now sends your API key, read from DORKOS_API_KEY or from ~/.dork/api-key. When no key is set up, the error names what is missing and where in the cockpit to create one. If you have not set up a key, nothing changes (DOR-428)
In first-run setup, "Skip" no longer throws away the rest of setup. Choosing a personality for DorkBot now has its own "Skip this step" button that moves you to the next thing, and the button that leaves setup for good says so: "Skip all setup". If you do leave, a note tells you where to start setup again (Settings → Preferences) (DOR-472)
The session list now shows the trust level a session is really running at. The sidebar used to call almost everything "Default", so a session left to act on its own looked exactly like one that asks before every step, and a session running without approvals could appear with no warning icon at all. It also went stale: a level changed in another window or by a scheduled task did not reach the list, and a refresh that arrived a second late could quietly undo a change you had just made. Every place a session appears now reads the same value, updates the moment it changes, and your newer choice always wins.
Lined-up messages no longer disappear. If you typed a follow-up while your agent was working and it then stopped to ask you to approve something, your message could vanish without a trace — the "Queued (1)" mark went away and the text was gone. Lined-up messages now wait their turn properly, and if one can't be sent for any reason it goes straight back in the line instead of being thrown away.
Every lined-up message now has a "send now" button. If a reply fails partway through, the messages waiting behind it used to be stuck there with no way to send them — and the only trick people found for getting the text back deleted it. Each one can now be sent on its own, and when sending genuinely isn't possible the button says why.
Visiting other conversations no longer deletes messages you lined up — or a message you started typing. DorkOS keeps the last 20 conversations in memory, and used to drop the oldest one whether or not it still held your words. A conversation with something waiting to send, or half-typed in the box, is now kept regardless.
Picking a slash command keeps the rest of your line. Typing /deploy staging, clicking back to just after /deploy, then pressing Enter used to delete staging and send nothing at all.
A file that fails to upload now says so, and offers to try again. The chip showed a small red icon with no words, and sending anyway delivered your message with no file attached — so you sat waiting for an answer about something your agent never received. DorkOS now holds the message until you retry the upload or remove the file.
Typing a command into a message that's waiting in line now just runs it. Commands like /compact or /rename do something right away rather than getting sent to your agent, so one sitting in the line used to jam it — everything queued behind it waited forever. Now it runs when you press Enter, and if it can't run (a missing name, say) your text stays put so you can fix it.
Rewriting a message that's waiting in line no longer loses the rewrite. Moving to another one, or switching to a different conversation and back, keeps what you typed.
Coming back to a conversation no longer sends a duplicate. If you left while editing a message that was waiting in line, its text stayed behind in the box and pressing Enter sent a second copy.
The "Your Agents Can Operate DorkOS" guide promised two safety checks DorkOS does not perform: that an agent checks with you before editing a different agent, and that it changes settings only when you ask. Both are instructions we give the agent, not locks. The guide now says so, and points you at your activity feed, which does record the change (DOR-428)
The MCP server page listed 48 tools and left out everything the operator surface added. It now lists all 55, says which 15 carry a risk level, and counts the capability catalog resource it had been missing (DOR-428)
The message box only grew when you typed. Anything else that filled it — clicking a queued message to edit it, pressing Up to reach the queue, Escape putting a draft back, a re-run pre-filling a prompt, tapping a suggestion — left a six-line message showing one line, in a box with no scrollbar to tell you the rest was there. The box now fits whatever it is holding, however it got there (DOR-479)
Editing a queued message and deleting all the text left you stuck: the banner still said "Editing message", and every button vanished. On a phone, with no Escape key, the only way out was the row's X, which deletes the message. The box now offers a plain "Cancel edit" (DOR-479)
Pressing Escape twice wipes your draft, and it used to be gone for good. Cmd+Z now brings it back (DOR-479)
Opening a session on a phone popped the on-screen keyboard and scrolled the page every single time. It doesn't any more (DOR-479)
While an attachment uploaded, the box claimed the agent was replying: the send button turned into a red Stop that did nothing when you pressed it, and if the upload hung, the box stayed stuck in that state forever. It now shows the upload in progress, and waits for it to finish before anything else happens (DOR-479)
If an attachment failed to upload, your message was deleted along with it. Your words stay in the box so you can try again (DOR-479)
The dashboard and the welcome conversation showed a greyed-out X for clearing the box that did nothing when clicked. It's gone — pressing Escape twice still clears the box on those screens, and Cmd+Z still brings the text back (DOR-479)
Typing your very first message on the dashboard and pressing Enter did nothing at all while DorkOS was still finding your agent, with nothing on screen to say why. It now says "Getting your agent ready…" (DOR-479)
Typing something like /zzz that matches no command left "No commands found." on screen and swallowed your Enter, so the message needed two presses to send. One press is enough, and the card goes away when the message sends (DOR-479)
Making a desktop window narrow — say, to sit beside your editor — quietly changed Enter from "send" to "new line". Enter now depends on the device rather than the window size: it sends anywhere you have a mouse, trackpad, or stylus (including a tablet with a keyboard case), and inserts a line break on a phone or a bare tablet (DOR-479)
Running /compact focus on the API changes while the agent was still replying deleted your instructions and then told you the agent was busy. The text now stays put unless the compaction actually starts, and the box waits for it rather than letting a second Enter run the same thing twice. If the request never comes back, it gives up after 30 seconds and says so, instead of leaving the box stuck (DOR-479)
When an agent asked you to approve something, the "Queued (N)" panel disappeared for as long as the question was up. The messages were always safe, but nothing said so. A quiet line now tells you how many are waiting (DOR-479)
The composer said "Editing message —" with nothing after the dash. It now tells you which one you are rewriting: "Editing message 2 of 3" (DOR-479)
"Session is busy. Please wait..." named nobody and gave no idea how long. It now says "Your agent is still finishing the last message. Try again in a moment." (DOR-479)
The list of waiting messages told you how many there were but never when they would go out. It now says so: "Queued (2) — Waiting for the reply to finish", or "Will send next" once nothing is holding them up (DOR-479)
A follow-up suggestion too long for its chip was cut off with no way to read the rest. Hover it and you get the whole line (DOR-479)
While you edit a message that is waiting to send — the one mode where Enter saves instead of sends — the writing box had no name at all for a screen reader. It now announces "Edit queued message 2 of 3 — press Enter to save" (DOR-479)
A file search that matched nothing could point a screen reader at a list that was not on the page (DOR-479)
The paperclip and the clear (×) button showed no outline when you reached them with the keyboard (DOR-479)
The list of waiting messages popped out of existence the instant the last one sent, instead of sliding away, and the extra stop button did the same. Both settle properly again (DOR-479)
The composer's right edge jumped sideways the moment you typed your first character, and a waiting message shifted two pixels when you clicked to edit it. Neither moves now (DOR-479)
A photo you attached rebuilt its little preview many times a second the whole time it was uploading. It is built once (DOR-479)
Setting up an agent in a folder you already have can no longer delete that folder. If setup stops partway, such as when the disk is full, DorkOS takes back only the files and folders it just made, leaves everything of yours alone, and tells you if anything is left over (DOR-507)
Agents can no longer turn off the safety prompts on a scheduled task, or approve one. A task runs later on its own with nobody watching, so how much it may do without asking, and whether it is allowed to run at all, are now yours to decide in DorkOS. A task an agent creates waits for your approval however it was made, including from the command line, where it used to go live right away. If an agent tries to change either setting, the whole change is refused and nothing at all is saved, so it never ends up half applied. Setting these yourself in the cockpit works exactly as before.
Scanning for agents from outside DorkOS can now show the agents it already knows about. The scan tool always supported asking for them, but the outside connection did not offer the option, so there was no way to ask for it. It also said it looks three folders deep by default when it really looks five.
The Tools screen was underselling what your agents can always do. It listed six tools that are on no matter what, leaving out the three that let an agent read its own preview window. All nine were always available; now the screen says so.
Reloading an extension you had turned off no longer quietly turns it back on. Asking DorkOS to reload a switched-off extension used to start it up again, routes and all, while the switch in Settings still showed it as off. DorkOS now says it is off and leaves it alone.
A folder in your project can no longer take the place of an extension DorkOS ships, or of one you already allowed. DorkOS decides what counts as its own code by where that code sits on disk, not by the name inside it.
A bookmark or shared link to the old Settings "Channels" tab now still opens the Integrations tab instead of silently opening nothing.
The adapter setup wizard and a couple of "Add" buttons in the Relay panel and onboarding preview still said "channel" after the rename above; they now say "integration" too.
Your agents were being given wrong information about which actions stop to ask you. The built-in instructions every agent is set up with said that deleting a scheduled task "carries no gate of its own", and the tool catalog that agents read to learn what they can do said that a whole group of DorkOS tools carries no permission level at all. Neither was true. Deleting a scheduled task and removing an agent have both stopped and asked you since they were classified, and every tool in that group has a permission level. The protection was never missing; the description of it was wrong (DOR-509)
An agent that believed those descriptions would not warn you before an action it could not undo, and would read your refusal as something broken rather than as your answer. The instructions now say plainly which actions wait for you, how to ask, and that a refusal is the answer. Existing agents pick up the corrected version automatically the next time DorkOS sets them up; a copy you edited yourself is left alone, as always (DOR-509)
The same instructions had three other details wrong: they named only two of the three actions that stop to ask you, they said removing an agent could only be done one way, and they said every command accepts the --json option when several reject it. All three are corrected (DOR-509)
Moving between DorkOS pages no longer reloads the whole app. Links that stay inside DorkOS switch pages instantly, so an agent that is mid-answer keeps streaming while you look around (DOR-534)
Links that belong outside DorkOS — the docs, GitHub, a sign-in page — now reliably open in your browser, including the ones an agent or a connected tool puts in front of you (DOR-534)
DorkOS now opens only ordinary web and mail links, and tells you when it turned one down instead of leaving you to guess. A tool that asks you to sign in through a link DorkOS won't open can no longer show you a "Done" button for a sign-in that never happened (DOR-534)
Stop the Restart and Reset buttons from leaving the desktop app with no server. Restart now tells you to quit and reopen the app, which does the same thing. Reset tells you plainly that nothing was deleted, and names the folder to remove if you really want to start over (DOR-532)
The Mac app now tells you when the background server it runs has stopped, and offers to start it again. Before, the window stayed open but quietly stopped working — most noticeably right after "Reset All Data" — with nothing on screen to explain why (DOR-533)
When that server won't start, the Mac app now tells you what the server said about why, then closes. If you already have DorkOS running in a terminal, for instance, it says so — instead of showing a bare error code and leaving the real explanation in a log file (DOR-533)
If the server keeps failing — whether it won't start at all, or starts and dies again moments later — the Mac app stops offering a button that isn't working and offers to open its logs instead (DOR-533)
Quitting the Mac app no longer pauses for several seconds when its server has already stopped (DOR-533)
The desktop app no longer flashes a white rectangle before it loads (DOR-538)
A window left on a monitor you then unplug comes back to a screen you can see, without a restart (DOR-538)
Quitting while full screen no longer brings the window back jammed under the menu bar (DOR-538)
Sending two messages in a row no longer gives an agent two separate conversations with itself. Both replies used to start from scratch, and the second one quietly forgot everything — including what you had just said (DOR-526)
Agents talking normally in a shared room no longer fill it with notices claiming somebody hit a reply limit they never came near (DOR-526)
Starting a direct message is one step again. It used to create the room and then add the agent, so if the second half failed you were left with a conversation named after an agent that was not in it — and starting it again did not help. Now it either works or nothing is created (DOR-526)
The "New direct message" menu no longer hides two agents at once when they happen to share a name (DOR-526)
Closed two ways agents could keep replying to each other forever. An agent writing to a room itself — rather than answering through it — started a brand-new conversation every time, so the reply limit never counted anything and never stopped them. Messages from you are what start the count over now (DOR-526)
A room now reconnects on its own when its live feed drops — after a laptop wakes up, or a restart — and picks up exactly the messages it missed. A sleeping laptop leaves a connection that looks open but is dead, so a room that hears nothing at all for 45 seconds now stops waiting and reconnects instead. If it can't get back after several tries it says so at the bottom of the room, with a Reconnect link, instead of sitting there looking quiet (DOR-526)
A message you were part-way through typing no longer follows you into the next conversation (DOR-526)
Reading back through a room no longer yanks you to the bottom every time a new message lands. Scroll up and you stay put; you're only carried along while you're already at the newest message (DOR-526)
Your privacy choice now survives a config reset. If your settings file was damaged and DorkOS had to rebuild it, or you reset your settings, the answer you gave about sharing data used to be thrown away and replaced with the sharing-on defaults. It is now kept, along with anything else you had made stricter: a login requirement you switched on, a limit you tightened, and the record that revoked your standing permissions. Preferences like your theme still go back to defaults, as a reset should (DOR-584)
Resetting one section by name, like dorkos config reset telemetry, still does exactly what it says. Naming the section is the clear request that a blanket reset is not (DOR-584)
Limits you tightened are kept too, not just switches you turned off. A smaller upload size or file count, a lower rate limit, a shorter room reply depth: all of these used to quietly go back to the shipped value after a repair or a reset (DOR-584)
DorkOS starts even when the settings it rescued no longer fit. A setting kept from a damaged file is now checked against the rules before it is written back, so an out-of-range value is dropped instead of stopping the server from starting. When that happens, the log names the setting so you know which one went back to its default (DOR-584)
DorkOS checks your task files against its own records every five minutes. That check gave up on the first deleted task it met, so deleted tasks lingered and edits you made outside the app stopped showing up. It now finishes.
Deleting a task now works even if that task has run before. It used to fail with an error.
Before removing a task, DorkOS now double-checks that its file is really gone. Tasks whose folder is a shortcut to somewhere else were being removed while the file sat there untouched.
A typo in a task file no longer costs you the task. A file DorkOS cannot read is left alone, so fixing the typo picks up where you left off, run history intact.
Tasks in a project folder DorkOS is not currently watching are no longer cleared out. This hit tasks you added for an agent connected after startup, and tasks belonging to an agent you disconnected.
Two tasks with the same name in different projects no longer interfere. One losing its file used to pause the other.
A task paused because its file went missing now runs again once the file is back.
Stopped the repeated log warning about a missing file in your tasks/templates folder. That folder holds the starter tasks DorkOS ships with, so it is not a task itself. A task folder of yours that really is missing its file is still reported.
A task file placed loose in your tasks/templates folder no longer turns into a task. It became one that ran on a schedule, and deleting it took every one of your templates with it.
Tasks in a project folder that has been deleted or unmounted are no longer cleared out. DorkOS could not tell an empty folder from one that is not there any more, so a checkout you moved took its tasks and their history with it.
Updating no longer fails if your database holds run records whose task is already gone. Those leftovers would have stopped DorkOS from starting at all, with no way to fix it from inside the app. They are tidied up during the update.
Your settings now survive a busy moment on your computer. When a computer has too many files open at once, reading a file can fail even though the file is perfectly fine. DorkOS used to read that as damage. It renamed your settings file and started over with defaults. One person lost their pinned status bar items that way. The riskiest moment was the first launch after an update, which is when DorkOS reads your settings the most.
DorkOS now waits a moment and tries again. If it still cannot read your settings, it stops and tells you why, and it does not replace or delete them. Start DorkOS again once your computer is less busy and your settings come back.
A settings file that really is broken is still backed up and rebuilt, and your privacy and safety choices still carry over to the new one. If this already happened to you, your old settings are in ~/.dork/config.json.bak.
When DorkOS does stop, it now tells you what to do about the actual problem. A full disk says to free up space. A file you are not allowed to open gives you the command to fix that, on Mac, Linux, or Windows. It no longer tells you to wait for a problem that will not pass on its own.
Fix an extension staying broken forever after a brief glitch on your machine — like running low on memory or disk space for a moment during startup. DorkOS used to remember that one-time hiccup as if the extension itself were broken, and would repeat the same error on every restart even after the glitch was long gone. Now it only remembers a real problem with the extension's own code; anything else gets a fresh try next time.
Fix one extension hitting a brief startup glitch from blocking every other extension from starting too. Each extension now starts on its own, so one hiccup no longer holds up the rest.
Quiet down a harmless background message that was showing up as a warning dozens of times a day. It's a safety check working exactly as intended, not a sign of trouble.
The first-run setup screen now has a way out. If DorkOS did not find a coding agent on your machine, the screen used to leave you stuck: nothing to continue with, and no Skip or Back to press. It now offers "Skip all setup" and Back, so you can look around the app first and set up an agent when you are ready — the Getting started card will still offer it (DOR-481)
Buttons that say they will take you to a setting now take you to that setting. "Add more agents", "Open Relay settings", "Add an integration" and the guided tours all opened Settings on the Appearance tab instead of the one they named, leaving you to hunt for it yourself (DOR-484)
Your permission choice now sticks to a chat for good. Claude Code gives a new chat its real ID partway through the first reply, and settings you picked before that were left behind under the old ID. If the chat then sat idle for a while, or you restarted DorkOS, the next message quietly ran at the default setting instead of the one you chose — so an agent you had set to act on its own might start asking again, or the reverse. The setting now moves with the chat, and every screen reads it from the same place.
Change a session's permissions from the status line and its sidebar row updates right away, instead of taking up to half a minute to catch up.
Fixed a crash that could hit the sidebar's Recent list the moment a brand-new session picked up its real id.
Scheduled tasks accept every trust level DorkOS offers, not just two. Set a task to anything else and the task file DorkOS wrote was one it could no longer read: the task kept running, but the file on disk and the task in the app quietly disagreed from then on, and every edit to the file was ignored. Every stop on the dial now survives a save (DOR-607)
Building a Shape? The setting that says whether one of its timers starts running is now called startEnabled, and it is off unless you turn it on. If your setup file still uses the old startDisabled, applying the Shape tells you so and points at the new name, instead of leaving you with a timer that never fires and nothing to explain it (DOR-607)
Your Telegram bot no longer replies to other bots. If two bots that both answer messages ended up in the same group, they could talk to each other forever and fill the chat. Your bot now ignores anything another bot says, and there is no setting that turns this off.
Buttons that open Settings work again in the Obsidian plugin. A recent change made "Add more agents", "Open Relay settings" and "Add an integration" do nothing at all there instead of opening Settings. They open it again (DOR-484)
A link to a Settings tab that no longer exists now opens Settings on its first tab instead of showing an empty panel. An old bookmark or a renamed tab used to leave you looking at a blank window with nothing selected (DOR-484)
Rooms now say something when an agent cannot answer. If the agent was busy with another task, or its turn hit an error, the room posts a short line telling you so, instead of leaving your message sitting there with no reply. A busy agent used to just say nothing, which looked exactly like a broken one. You get one line, not one per message you sent. (DOR-621)
A slow answer is no longer thrown away or cut off. If an agent takes longer than the room's wait, the room stops waiting but the agent keeps working, and its full answer is posted when it lands, quoting the message it answers and saying how long it took. Before this, the room either went quiet or posted whatever half-sentence the agent had written so far as if it were the finished answer. (DOR-621)
Sending a second message to an agent that is still working no longer posts a stray fragment of its first answer. (DOR-621)
Slack and Telegram settings that the setup screens never showed you are now on screen, in the add flow and behind Configure. The most important ones decide who is allowed to approve an action: when your agent asks permission to run something, only the people you list under Approvers can say yes. That list was impossible to fill in before, so nothing could be approved from Slack or Telegram at all. Slack also gains its DM controls: who may message your bot, which channels behave differently, and when the bot joins in.
A setting that no setup screen claims now appears under its own heading on the last screen. Nothing can go missing again just because it was left off every screen.
Lists and per-channel rules you had already saved now show up the way you wrote them: one entry per line, and readable settings instead of [object Object]. Editing one of these and saving used to run your existing entries together into a single broken one, which quietly took away everyone's permission to approve.
If the Channel Overrides box is not valid JSON, saving now stops and tells you, and your existing rules stay put. It used to accept the save and erase them.
Nothing changed value. Every setting opens on what it was already set to, including the ones you are seeing for the first time.
A direct message now shows the face of the agent you are talking to, instead of a plain letter. A conversation with several agents shows all of them.
The Channels, Direct messages and Agents lists no longer say "create your first one" when the reason they look empty is that everything is filed into a group. They say that instead.
Every agent ships with a small set of built-in skills that teach it how to run DorkOS. Those skills were being written to a place the default runtime does not look, so agents never actually learned them. They now land where the agent can read them, for new agents and for DorkBot (DOR-659).
Agents that DorkOS set up for you are repaired the next time you start it. Nothing to click, and it does not slow startup down. Agents that live in your own project folders are left alone, because starting DorkOS is not a reason to write files into your projects (DOR-659).
DorkBot re-checks its own skills on every start, so if the links are ever lost it puts them back on its own (DOR-659).
New agents now land in the DorkOS folder the running copy is actually using. If you point DorkOS at a different folder — a second copy, a container, a checkout you are working on — creating an agent used to build it in your main ~/.dork/agents instead, so folders appeared in your everyday setup that you never asked for. Setting your own agents folder still means exactly what you typed.
Setup saves the personality you pick for DorkBot to that same copy's DorkBot. It used to edit the DorkBot in your main folder.
The create-an-agent screen now shows the real folder the agent will be created in, and checks that folder for a conflict. It used to show ~/.dork/agents, which was not always where the agent went.
Point your agents at your own copy of the docs. DorkOS hands your agents a link to the docs, and until now that link always went to dorkos.ai. Set DORKOS_DOCS_BASE_URL to your own site and your agents read that one instead. It has to be an http:// or https:// web address, or DorkOS will not start. Leave it unset and nothing changes (DOR-660)
OpenCode sessions no longer go missing once a project has more than 100 of them. Older ones used to drop off the list quietly — nothing failed and nothing said anything was hidden, so the list just looked short. The background sessions your agent starts for its own subtasks counted toward that 100 as well, so you could lose sight of your own sessions even sooner. Opening one of the hidden ones could also fail with a message saying the session did not exist, when it did. They are all listed and openable again, and if a project ever holds more sessions than OpenCode can hand over at once, DorkOS reports a problem loading the list instead of quietly showing you a shorter one. (DOR-673)
dorkos harness sync --check no longer creates a file. Check is the mode that only reports, and the docs called it safe to run any time — but run it somewhere that has no harness manifest and it quietly wrote one, into whatever folder you happened to be standing in. It now stops, names the folder it searched, and leaves everything exactly as it found it (DOR-678).
Three other ways into the same write are closed too. Plain dorkos harness sync with no flags, narrowing the run to one tool with --harness, and even naming a tool that does not exist all created that file first — so a command that went on to reject your input still left something behind. None of them write now.
--fix still creates a manifest when a folder has none, which is what --fix is for. The built-in help now says plainly which mode writes and which never does, and reminds you that sync always acts on the folder you run it in — so if it cannot find a manifest, the usual answer is that you are one directory away from where you meant to be.
Your agents now keep up with the built-in DorkOS skills. Until now only DorkBot did, and every other agent kept the skills it was handed on the day you made it. That matters when we correct a skill. One correction taught agents to warn you before deleting a task, and agents made before that fix never found out. Now DorkOS refreshes the built-in skills every time it starts, and puts them where the agent can actually read them (DOR-671)
Your own work survives the refresh. A skill you wrote is left alone, and so is a built-in skill you have edited. Deleting a built-in skill does not stick, though: it comes back the next time DorkOS starts, so edit it instead if you want it out of the way. Agents you registered from a folder of your own are not touched at all.
Saving from two places at once no longer loses one of the saves (DOR-697). If you had DorkOS open in two tabs, or an extension saved in the background while you changed a setting, two saves to the same file could collide: one would fail with an unexplained error, and the other could quietly store the wrong content. Sign-in details for your agent runtimes, your marketplace sources, and your agent templates were all stored this way — a collision could drop a saved key or source, and in the worst case wipe your whole template list. Saves to the same file now take turns, and each one keeps its own content.
An agent that takes a long time to answer in a room no longer counts as finished. A room waits 10 minutes for a reply. After that, the other agents in the room used to be told it was free, so two of them could start the same job. It now counts as working until its answer lands
A room no longer names the same agent twice while it is working. One agent can have two replies going at once in a busy room, and each one was listed separately
When a slow answer fails on its way into the room, the room now says the turn failed. Before, it went quiet and left you waiting for an answer that was never coming
Press-and-hold menus no longer interrupt you mid-gesture. Starting a scroll or dragging to select text used to be able to open the menu under your finger; a press that travels now leaves your gesture alone
A room with a lot of agents in it no longer grows the sheet off the top of the screen. It stops at a readable height and the middle scrolls, the way every other panel in DorkOS does.
Opening the sheet on a phone no longer pops the keyboard at you. The search box is still the first thing under the heading, and still one tap away — you just get to look at the list first.
The × that takes an agent back off the list while you are choosing was a few pixels too small to hit reliably on a phone. It is now comfortably thumb-sized.
On Telegram, "typing…" now means an agent is actually working. It used to appear the moment your message arrived — before anything had picked the message up, and even when nothing ever would, so a chat that was never going to get an answer sat there watching a bot pretend to type. Now it starts when the turn starts, and stops when the reply lands, when the turn fails, or when the agent pauses to ask you something — a question, or a tool it wants approved. The old 60-second cutoff is gone too: a long job keeps typing for as long as it keeps working, instead of going quiet a minute in while the work carries on. And if an agent goes silent without ever finishing, the typing stops by itself after a minute rather than running forever.
Choosing a default runtime other than Claude Code no longer silences your agents on chat platforms. dorkos config set runtimes.default opencode is a documented setting, but it also reached the relay — the part of DorkOS that carries messages between your agents and Telegram, Slack, and the like. The relay only knows how to talk to Claude Code, so a different default left it with nothing it could use, and it switched message routing off during startup with nothing you would ever see in the app. The server looked healthy, the chat connection looked connected, and messages went nowhere. The relay now uses Claude Code directly whatever your default is, and where it genuinely has to make a choice it writes that choice to the log instead of going quiet.
Keep a long conversation's memory when Claude Code renames it a second time. Claude Code can give a session a new name when it picks it back up, and after the second rename DorkOS lost track of which conversation was which — the agent started over with no memory of what you had been talking about. A session now answers to every name it has ever had (DOR-774).
An agent that stops to ask your permission no longer gets cut off as stuck. If a second reply started on the same chat while the first was still waiting on your answer, DorkOS could decide the waiting agent had frozen and end its turn ten minutes later. The turn now stays open while it waits on you. (The permission request itself still expires after 10 minutes, as before.)
Long jobs keep their chat to themselves. A turn that ran longer than five minutes — normal for room agents and for anything that reads a lot of files — used to become fair game for another browser tab or device, which could start a second reply on top of it. A turn that is still working, or still waiting on you, now holds the chat for as long as it needs. One that has genuinely gone quiet is still handed back after five minutes.
Sessions started in a linked folder, a folder with accented characters in its name, or a very deeply nested one now find their earlier history instead of starting from scratch.
When the same chat opened twice at once, one of the two views could go permanently silent — connected, but never receiving anything again. It now reconnects and catches up.
If DorkOS can't stop a frozen agent, it no longer waits forever trying. It gives up after 30 seconds, closes the turn, and says what happened in the log.
Telegram private chats now use an allowlist, the same way Slack DMs do. A bot handle is public, and a private message starts a real agent turn on your machine, so a new integration answers only the people you name. If a message is ever turned away, the log says who it was, their user ID, and the setting to change (DOR-788).
A Telegram bot you already set up still answers anyone who messages it. Changing that automatically would have taken a working bot off the air, so the old behaviour is kept and DorkOS warns about it by name at every startup. Open that integration, set DM Access to "Allowlist only", and add the people you want.
Slack says the same thing out loud. Turning someone away used to be silent, which looks identical to a broken bot — especially right after setup, when the allowlist is still empty. It is now one clear line per conversation, not one per message.
"Let this agent start conversations here" is now a permission for that one agent on that one channel. Before, once you granted it, any agent on your machine could message that chat as your bot.
If the part of DorkOS that decides who may message whom fails to start, chat integrations no longer start either. They used to connect, look healthy, and answer nobody — with the permission checks quietly switched off.
If your relay access rules become unreadable, DorkOS now stops delivering and says which file to fix, instead of behaving as though you had never written a rule.
One unreadable integration in your settings no longer hides all of them, and adding a new integration can no longer delete the ones DorkOS could not read. An unreadable one is kept exactly as written — so if it holds a password, that password stays in plain text until you fix or delete it, and DorkOS now says so. You can delete it by name, and re-creating an integration under the same name clears the broken copy.
Group chats set to "a separate session per person" now really do give each person their own session. Everyone in the room was sharing one, so a conversation could be read by whoever spoke next.
A message from a chat platform can no longer impersonate DorkOS's own instructions to your agent. Code and prose you paste into chat still arrive exactly as written.
Custom webhook headers can be set at all now — saving them used to fail every time — and they are treated as secrets: stored encrypted, hidden when read back, and never written to a log. An API key put there used to sit in a plain settings file (DOR-796).
A Telegram integration that loses its connection now reports the problem and reconnects, instead of retrying in silence forever while reporting itself connected.
A webhook pointed back at DorkOS now stops after a few laps instead of talking to itself indefinitely. If your service answers DorkOS through the inbound endpoint, pass the X-Relay-Hop-Count and X-Relay-Max-Hops headers back unchanged.
An agent in a room no longer forgets the conversation. Its replies used to get filed under one name while the room remembered another, so the next message started the agent over from nothing. It happened quietly: no error, no notice, just an agent that had lost the thread. The room now keeps up with the name the moment it changes.
On startup, DorkOS checks every agent in every room and writes a line in the log for any whose saved conversation it cannot find, naming the room and the agent. Nothing is deleted, so a conversation that went missing can still be tracked down by hand. If DorkOS cannot read your saved conversations at all, it says that too, instead of finishing quietly and looking like all is well.
When a message you send from Telegram or Slack cannot reach its agent, the chat now tells you so in one line — instead of going quiet in a way that looks exactly like an agent thinking. It says which thing to change: the chat is paused, it is set not to reach its agent, the agent is not available, a session would not start, or the agent is at capacity. If you send the same message five times, you are told once. These lines only ever appear in a chat you connected to an agent yourself; DorkOS never speaks in a chat you haven't set up.
A turn that ends without saying anything now says so, rather than leaving your question sitting there. It stays quiet when the agent already answered, already showed an approval card, or already reported an error — so you never get "the agent finished without sending anything back" underneath a real reply.
A long answer no longer arrives with its beginning missing. Any reply that took more than five minutes used to lose everything written before that point; on Slack it also split into a second message halfway through. Both now wait for a stream to actually go quiet, however long the answer takes.
Mail waiting in an agent's inbox is no longer deleted an hour after it arrives. An agent that was switched off for an afternoon came back to an empty mailbox with nothing to say a message had ever arrived. Unread mail is now kept for a week, and when it finally does expire it is set aside where you can still read it.
Task-completion notices go to the conversation you were actually using, not to whichever one happened to be listed last — which was often a channel nobody had touched in weeks. Under the one-session-per-person setting, a group's notice can no longer end up in somebody's private messages.
Changing an integration's settings while it is refusing to shut down no longer starts a second copy of it. That is what made a bot answer everything twice, and bill twice for one question.
On Slack, the 👀 mark now lands on the message being answered. When a message was dropped before it reached an agent, the mark used to shift onto the next person's message instead.
A task problem that sticks around no longer repeats in your log every five minutes. DorkOS checks your task files on a timer, so one bad file used to write the same line twelve times an hour, all day, burying anything else that went wrong. You now get the full message the first time it happens, then one reminder an hour that says how many times it has repeated. A different problem always shows up right away.
When an agent asks to use a tool and nobody answers, it gives up after ten minutes. That used to happen in complete silence. DorkOS now writes a line saying which agent gave up and what it was asking about, so you can find out afterwards why it stopped.
An agent in several rooms at once no longer starts a separate job for each one in the same project folder. It finishes what it is doing first, and the other rooms say it is busy elsewhere rather than going silent.
A room could mistake somebody else's work on the same agent for its own answer and post it. It now tracks exactly which piece of work it asked for.
The agent's thinking shows up again. It streams in while the agent is thinking and stays in the conversation afterward — a lost capability flag had been leaving every thinking block empty.
A scheduled task that runs past its time limit now actually stops, even when it is sitting on a permission prompt waiting for an answer. Before, the limit only took effect the next time the agent said something — so a task parked on a prompt nobody answered kept running, held onto one of your run slots, and made shutting DorkOS down slow. This works whichever way your tasks are dispatched.
A task run that was stopped now records why — you cancelled it, or it ran out of time — instead of reporting both the same way. Cancelling a run also shows up once in your activity feed instead of twice.
A task file on disk can no longer set a scheduled task to run without approvals. If one asks for it, DorkOS quietly turns the task back down to the normal prompts and notes why in the log. Choosing "Full autonomy" yourself, in the cockpit, still works exactly as before — and if that task's file is later rewritten behind your back, or reappears after the task was paused, it drops back to the normal prompts instead of carrying your permission over to work you never approved. The install preview now shows the setting a package's task will really get, not the one it asked for.
Editing a scheduled task no longer widens what it may do. A task set to a mode the edit form does not offer — like plan mode — keeps that mode when you save, and the form now says in plain words what it is instead of quietly switching it to "Allow file edits".
A session can no longer be set to a trust level its agent cannot actually run. A Codex session set to a stop Codex does not have used to be accepted and displayed everywhere while Codex quietly kept running read-only. The setting is now refused, with a message naming the ones that agent does support. Sessions already saved that way still open and run as before.
A Claude session set to "Auto" no longer fails to send when DorkOS has not confirmed that the chosen model supports Auto — right after a restart, for instance. The turn runs in Default and says it could not confirm, and your Auto setting is kept, so it applies again as soon as the model is confirmed.
Approving or denying a tool in an OpenCode session now clears the card right away. It used to wait for OpenCode to confirm the answer, and if that confirmation never arrived the card sat there and the session stayed stuck as "waiting on you", blocking the next message.
An integration or a task saved at a setting the dial does not offer keeps that setting instead of being quietly widened to a broader one. It says which setting it is, and saving leaves it alone until you pick something else on purpose.
Stopping a scheduled run now works. On a normal install, DorkOS hands a scheduled run to its message bus, and the Stop button in a task's run history did not know how to reach a run that had gone that way — it answered "run not found" for a run that was plainly still working, and the only way out was to wait or restart. Stop now reaches the run wherever it is running: the agent is told to finish the turn it is on, and the run is recorded as cancelled. (DOR-808)
DorkOS no longer claims to have stopped something it could not reach. If nothing picks up the stop, you are told so in plain words — including when the hold-up is DorkOS's own message limits rather than a silent agent — and the run is left as it is, instead of being marked cancelled while the agent keeps working. Pressing Stop on a run that has already finished says so, and does nothing else. (DOR-808)
A run that finished its work is never recorded as one you stopped. Pressing Stop in the same instant a run was ending filed the finished run as cancelled, output and all. Whichever happened first now wins honestly, on both the scheduled and the direct path. (DOR-808)
A scheduled run that hit its time limit is no longer also reported as failed. The run's own record said "cancelled" while your activity feed said the task failed. Only the run's record was ever right. (DOR-808)
Only DorkOS itself can stop your scheduled runs. Stop requests travel over the same message bus your agents use, and an agent that guessed a run's id could have ended somebody else's work. Anything that is not DorkOS asking on your behalf is now refused. (DOR-808)
The names DorkOS reserves for its own messages are now protected everywhere. Anything reaching your DorkOS port could claim a mailbox at an address DorkOS uses for its own traffic — including agents' own addresses, and the channel that carries a Stop — which quietly intercepted messages meant for someone else. Those addresses are refused now, whoever asks. (DOR-808)
The soft pulse that says work is happening — on the thinking line, on loading placeholders, on connection dots — had never actually been drawn. About twenty places in the app asked for it and got nothing. They breathe now.
Changing how much a Claude Code session asks before acting, right as its first message was being sent, could be quietly undone a moment later — putting the agent back on the setting you had just moved away from, including "act without asking". Your newer choice now always wins.
A hiccup in the settings database while a session was picking up its permanent name no longer ends the message you were in the middle of. It gets logged, and the turn carries on.
If you had set a server-wide default for how much new sessions ask before acting, that default could overwrite the choice you made for one particular session, moments after you made it. Your choice for a session now always beats the default.
Sending a second message while a brand-new session was still answering the first no longer counts as starting a whole second session.
An attachment that got stuck uploading used to freeze the whole message box — the send button spun forever and the Enter key stopped working, with no way out but a page reload. Now you can stop an upload: click the spinner where the send button sits, press Escape, or click the X on the file. And if the connection dies mid-upload, DorkOS gives up after 30 seconds and tells you on the file itself, so you can try again or drop it and carry on. A big file on a slow connection is left alone — only silence counts as trouble, not slowness. (DOR-494)
Some wifi networks answer for you — the hotel or cafe sign-in page that appears before you're online. When one of those replied to an attachment upload, DorkOS took it for an answer it could not read and sat on a spinner that never stopped, with the Cancel button unable to help. It now says the upload got an unexpected reply, so you can sign in to the network and try again. (DOR-494)
DorkOS watches files in the background so it can notice when your sessions, tasks, agent rules, and integration settings change on disk. When one of those watchers failed — usually because the machine ran out of file handles — it went quiet and nothing said so. Now each one writes a single clear line naming what it was watching and why it stopped. Repeats of the same failure are folded into that one line, and the line says so, so a quiet log afterwards is on purpose rather than a second thing to worry about. A watcher that stops does not restart itself: it keeps serving what it already loaded, but changes in that folder go unnoticed until you restart DorkOS.
On a machine that had run out of file handles, DorkOS could get stuck partway through starting up and never finish — no window, no error, nothing in the log. It now starts, tells you which watcher failed, and runs with that one part degraded instead of not running at all.
Scheduled tasks stay in sync again: the background sync that runs every five minutes no longer fails, and a problem that won't go away now writes one log line an hour instead of a flood (#667)

Security

An approval now only covers the exact thing you approved. Saying yes to uninstalling one package cannot be reused to uninstall a different one, to delete that package's saved data when you agreed to keep it, or to change a different project. Each approval works once, only a person can answer one, and approvals are never stored in a form anything could reuse (DOR-447).
Agent identity tokens now expire. A token stops working after a week of not being used, and after a month no matter what. Before, a token handed out for a five-minute session last month still worked today, which mattered much more now that DorkOS records who an agent is (DOR-448).
An approval covers one exact action, and the check happens before anything runs. An agent that changes even one detail of what it asked for has to ask again (DOR-448).
Hiding does not help. An agent that leaves its name off a request still cannot run a catalog action that cannot be undone without your approval, and the card tells you plainly that DorkOS does not know who asked (DOR-448).
When an agent presents an identity DorkOS does not accept, that now shows up in the debug log so you can see an agent with an expired or rejected token still trying. The token itself is never written down (DOR-448).
Closed an information leak in the config_get tool. It returned your whole settings file with only four fields held back. What came through included pointers to where your provider keys live. That means an environment variable name, a keychain entry, or the path to a key file on your disk. It also included the name of the DorkOS account this install is linked to. That tool answers without asking for a token, so any program running on your machine could read all of it. Your keys themselves were never in there. Now the tool shares a fixed list of settings. Anything key-related comes back as a plain yes or no instead of a value. Adding a new setting to DorkOS now means deciding whether it belongs on that list, so nothing new can slip in unnoticed (DOR-428)
An agent could approve its own request. When an agent asked to do something that cannot be undone, the reply carried the code needed to retry, and nothing stopped the agent from answering the request itself. Now the agent that asked, and anything holding that retry code, is refused, and the request keeps waiting for you (DOR-428)
The approval card could be worded to hide what would really happen. An agent could put punctuation in a package name so the card read "keeping saved data" while the real setting was "delete saved data", and pad it so the true setting scrolled out of view. Details an agent supplies now appear in quotes, each one is kept short, and a card for something that cannot be undone is never cut off (DOR-428)
Approval cards no longer show anything that looks like a password or a code. Your agents can read the waiting list, so a card that echoed a secret back was publishing it. Cards now show only the details the action needs, and hiding a code no longer depends on where it sits in the text or how long the text is (DOR-428)
The docs now say plainly what the approval question does and does not protect against. With no login required (the default), it stops mistakes and it stops an agent that follows the rules but was talked into something bad. It cannot stop a program that already has full run of your computer. Turn on Require login in Settings, under Security, and answering a request needs a real account (DOR-428)
Through DorkOS's own tools, agents can no longer turn off your login. The config_patch tool let an agent change any setting, and nothing asked you first. That included the login switch. Turning login off is the one change that undoes every other protection, because approving a risky action is what a signed-in person does. An agent could switch that off and then approve its own work. The tool now refuses the settings that decide who can reach your instance, what it can touch, and what leaves your machine: login, the public tunnel, the MCP endpoint and its key, telemetry choices, where your provider keys come from, extensions, the runtime programs DorkOS runs, and the folders DorkOS reads and writes. Ask an agent to change one and it is told plainly to ask you instead. You still change all of these yourself in Settings, exactly as before. Adding a new setting to DorkOS now means deciding whether an agent may write it, so nothing new can slip through unnoticed. To be clear about the limit: a program running on your machine as you, including an agent with a terminal, can still reach these settings directly, the same way it can reach any tool you run. That is the trust boundary described in the threat model, and turning on login is what moves it (DOR-488)
Uninstalling a package now asks you first, whichever way an agent reaches for it. The dorkos uninstall command used to remove packages with no approval at all, and it was the command your agents were taught to use. Now an agent gets an approval card and waits for your answer, and you can hand it the go-ahead with dorkos uninstall <name> --approval <token>. Clicking Uninstall yourself in DorkOS works exactly as before (DOR-467). With Require login on, the approval must be granted by a signed-in person in the browser; dorkos uninstall then prints the command to finish once you've said yes.
Agents can no longer change the settings that protect your instance through the settings API. Turning off sign-in, widening which folders DorkOS may touch, and changing where its credentials go are yours to choose. Your own changes in Settings are unaffected (DOR-467).
Ask you first before an agent deletes one of your scheduled tasks. Deleting a task cannot be undone, so it now waits for your approval like removing a package does (DOR-468)
Ask you first before an agent removes another agent. That one call used to take three things at once: the agent, its setup file on disk, and its scheduled tasks (DOR-468)
Sort every tool an agent can reach into read-only, changes-something, and cannot-be-undone, so a new tool cannot arrive without somebody deciding which it is. Only the two above wait for you; everything else runs exactly as before (DOR-468)
Refuse extension names that would put a new extension outside your extensions folder (DOR-507)
With Require login on, the settings screen now insists on a person, not just an account. Changing the settings that protect your instance (whether login is required, the key for the tool endpoint, the folder DorkOS may touch, the programs it may start, your privacy choices) now needs someone actually signed in to DorkOS. A program holding one of your API keys is refused, where before a key was enough to turn login itself back off. Nothing else about signing in changed (DOR-505).
Three of those settings can also be changed from their own buttons elsewhere, and those paths are not guarded yet at all: connecting a model provider, starting your public web address, and linking this instance to a DorkOS account. They do not check who is calling, so this is unchanged whether Require login is on or off. The approvals guide says which is which, and we are closing them separately (DOR-505).
Worth knowing if you leave Require login off, which is the default: nothing changes there, and nothing can. A program on your own computer that hides the fact it is an agent looks exactly like you clicking a toggle in Settings, so DorkOS has nothing left to tell the two apart. Turning on Require login is what closes it. The approvals guide now spells out which of the two you have (DOR-505).
Agents can now only read a Relay inbox that belongs to them: their own address, an inbox handed to them when they sent a background message, or one they set up themselves. Before, an agent could name any other agent's address and read its waiting messages, and polling with ack deleted those messages for good. The same rule now guards removing an endpoint, which throws away its whole mailbox. Asking for someone else's inbox is refused, and says so. (DOR-506)
An inbox keeps belonging to the agent that set it up, even after DorkOS restarts. Ownership used to live only in memory, so the first agent to ask for an address after a restart became its owner, could read mail meant for someone else, and locked out the real owner. (DOR-506)
Two inbox names that differ only in capital letters can no longer both exist. On macOS and Windows they shared one mailbox on disk, so an agent could wipe another's messages by registering a differently-capitalized copy of its address and then removing it. (DOR-506)
Agents can no longer claim the addresses DorkOS manages itself (relay.agent.*, relay.system.*, relay.human.*). Claiming another agent's address would have quietly intercepted its incoming messages, not just read them. An agent's own inboxes live under a set of addresses of its own (relay.inbox.*). (DOR-506)
A standing permission cannot outgrow what you agreed to. It covers one agent and one action, never a group of either. Its clock is set the moment you grant it and using it never extends the clock, so an agent cannot keep itself trusted by staying busy. It stops working the instant you end it, the instant you switch standing permissions off, and the instant you turn off Require login. And nothing an agent can do creates one: opening a permission needs a person signed in to DorkOS, so answering a single approval is not enough (DOR-501)
Your agents cannot read the list of what they are allowed to do without being asked. Knowing which irreversible action goes through silently right now, and the minute the window shuts, is a map worth keeping to yourself, so that list needs the same proof of a person as answering an approval does. And when DorkOS starts, any permission left over from a time when it was not allowed to exist is ended, whether that is because standing permissions were switched off or because Require login was, so turning either back on never wakes an old one (DOR-501)
No trust level can switch off the questions about DorkOS itself. Running a session at a level that skips prompts still leaves removing packages, deleting scheduled tasks, and the rest of the actions that cannot be undone behind the same question. That is now something DorkOS tests for rather than something that happens to be true (DOR-501)
Only you can change where DorkOS gets packages from. A marketplace source is a place DorkOS will download and run code from, so an agent that tries to add or remove one is now turned down with a plain refusal telling it to ask you instead. There is no card and no way for it to say yes. Adding and removing sources still works normally from your own terminal and from the Marketplace sources screen, and agents can still list, refresh, and validate sources and install from the ones you already added (DOR-502)
Close a hole where a web page you visit could drive your agents. A page can point its own domain at your own machine, which makes your browser treat it as if it came from DorkOS. DorkOS now answers only to the address you actually use, so that page gets turned away (DOR-532)
Reach DorkOS by another name, like dorkos.example.com behind a proxy? Set DORKOS_TRUSTED_HOSTS=dorkos.example.com and it works again. Turning on login skips the check entirely, and the official Docker image is unchanged (DOR-532)
Stop a stranger from installing software on your machine through DorkOS. The buttons that install Ollama, Codex, and OpenCode are meant for you, sitting at your own computer. They trusted headers that any caller can set, so anyone who could reach your instance could start an install. DorkOS now checks the network connection itself, which nobody can fake. Docker is unaffected, because there the container already controls who gets in (DOR-532)
Worth knowing if you leave Require login off, which is the default. Two of the rules above work out who is writing: the reply limit that your messages reset, and the rule that only you change who is in a room. Both need DorkOS to tell you apart from a program running on your own computer, and with login off it cannot — a program that simply does not mention it is an agent looks exactly like you. Read those two as shaping how a room behaves, not as limits on what it can spend.

The hourly limits are the ones that hold either way, because they never ask who is calling. The per-room limit caps what any one room runs; on its own that is not a cap on your bill, because a program that keeps making new rooms gets a fresh allowance each time. The total limit is the real ceiling: 240 automatic replies an hour across everything, however many rooms exist. Both reset if DorkOS restarts.

None of this gives a program on your machine anything it did not already have — anything that can send these messages can run an agent directly. What these limits are really for is stopping well-behaved agents from talking each other in circles by accident, which is the common case and worth having on its own. Turning on Require login is what tells you and a program apart (DOR-526, DOR-505)
A settings block that was missing the feature-usage entry no longer counts as permission to send those events. A missing answer is never treated as a yes (DOR-584)
A message from Slack or Telegram can no longer run a shell command on your machine without asking you. A chat message started an agent turn, that turn landed at a trust level nobody had chosen, and at that level every tool — including the one that runs shell commands — was approved automatically. Now anything that reaches DorkOS for a decision asks you first, whatever level the turn is at. The one exception is Full autonomy, which is what that setting means and says (DOR-604)
"Accept edits" now does what it always said it did: accept edits. It promised "auto-accept file edits; still prompt for other tools" and then approved everything, shell commands included. It also no longer waves through a file edit that tried to write outside the folder the agent was working in — something like your ~/.ssh keys or your shell profile — which is exactly the case worth stopping to look at (DOR-604)
Only people you name can approve a tool call from chat. When your agent asks permission to run something, it posts an Approve/Deny card into the conversation — and anyone who could see that card could press Approve, including the person whose message set the whole thing off. Now Slack and Telegram integrations each have an "Approvers" list, and only the people on it can answer. It starts empty, which means nothing gets approved from chat until you say who may — and it is deliberately a separate list from who can message your agent, because talking to it and letting it run a command on your machine are not the same permission (DOR-609)
A new Slack integration only answers direct messages from people you name. It used to accept a DM from anyone in the workspace, and a DM starts an agent turn on your machine. Integrations you already set up keep working exactly as they did, and DorkOS now says so at startup if one of them is open to your whole workspace, so it stays your choice rather than an accident (DOR-604)
The timers a Shape sets up can no longer start themselves, or hand themselves a free pass. A Shape's setup file lists recurring tasks it wants for you, and until now that list could say two things nobody had agreed to: start the moment this Shape is applied, and run with every approval prompt turned off. Both are the kind of thing you should decide, not the package. Now one of those timers arrives turned off unless the Shape's author asks for it to start, and a request to skip all approvals is refused: DorkOS sets the task up asking, and leaves you a note saying the Shape wanted more than it got. You can still turn the timer on, or raise what it may do, on the task itself once you have read what it does. This covers the timers a Shape asks for in its setup file; a package that ships a task file of its own is separate work, still to come (DOR-607)
Ask before an installed package adds commands to your coding agent. Some marketplace packages ship hooks: commands your agent runs on its own, before or after it does things. Until now, installing one was enough to put those commands in place, with nothing shown and nothing to click. DorkOS now shows you each command and when it would run, and waits for your answer. Say yes and they go in; say no and the rest of the package still works. Your answer is remembered per package and per project, and DorkOS asks again if a later version wants to run something different, or wants to run the same thing at a different moment (DOR-522).
Stop an agent package from taking over the folder you install it into. Installing an agent package into a project treated the whole project folder as the package: DorkOS moved your folder aside, put the package in its place, and deleted the folder it had moved. It also meant the package could drop files anywhere, including places DorkOS reads. An agent package now installs into .dork/agents/<name>/, the same way plugins do, and everything already in your project stays where it is (DOR-522).
Your agent can no longer set up recurring background jobs on your machine without asking you. Switching to a Shape does more than rearrange the cockpit: it turns on every scheduled job that Shape comes with, and each one runs later, on its own timer, with nobody watching. A Shape can also say that its jobs should skip every safety prompt. Because switching Shapes was filed under "moving things around on screen", an agent could do all of that in one step and you would never see a prompt. Now an agent that wants to switch Shapes has to ask you first, and you see which Shape before you answer. Clicking a Shape yourself is unchanged: no extra prompt, it just switches (DOR-625)
The rest of what an agent can do to the cockpit is untouched. Opening a panel, showing a file, throwing confetti, switching which project you are looking at: all still instant, no prompt. Only the one action that reaches past the browser and onto your machine asks (DOR-625)
Messages other members wrote now reach an agent inside a clearly marked block that says they are information, never instructions. The markers around that block carry a one-time code, so nobody can end it early by typing the closing line into a message and having the rest read as trusted. (DOR-622)
Names, room topics and agent handles are cleaned before an agent sees them, using the same check that already protects messages arriving from Telegram and Slack. Someone cannot use their own display name, or the message a thread was started from, to slip an extra instruction into what an agent reads. (DOR-622)

Note for people upgrading

Extensions you installed before this update start out not allowed, and they wait for you the first time. This is deliberate: DorkOS will not treat "you switched this on once" as "you read this code". Open Settings → Extensions and allow the ones you want. It is one click each, once. Until then an extension you have not allowed will not show up in DorkOS at all, so if something you use has gone missing, that is where it went.
Nothing changes until you choose an account. Until then DorkOS works the way it always has. Before this release, DorkOS used whichever account the terminal you launched it from happened to point at. That meant sessions from your other accounts were quietly missing from your list.

For contributors

This cycle changed how work lands in DorkOS itself. main now merges through a GitHub merge queue, so a pull request is tested against main plus everything queued ahead of it and nobody has to keep a branch up to date by hand (ADR 260728-112203). Database migrations picked up their own required checks in continuous integration, so a schema change cannot merge without one. And the changelog became audience-aware: an entry ships only when someone running DorkOS would notice it, which is why this release note is shorter than the commit log behind it.

Install / Update

npm install -g dorkos@0.57.0