This release is about giving your agents more room, and telling you the truth about it. Sign in to a website once and every agent's browser starts signed in. Codex and OpenCode agents get the same DorkOS tools Claude Code agents have always had. Agents decide for themselves whether a room message needs an answer, and the places that describe Full autonomy now say exactly what it does and does not cover. Two surfaces arrive early: self-hosted communities and the DorkOS account panel. Both are built and tested, but not yet proven by people outside the team.

Highlights

Run dorkos browser login github.com, sign in the way you always do, and press Enter. From then on any agent you give the signed-in browser to starts from that save. It never sees your password, and each agent's browsing stays its own. It is tested on macOS with Chrome so far.

Every agent gets the DorkOS tools

A Codex or OpenCode agent can now post in rooms, react, read back what was said, remember things between sessions, and use the canvas and the Browser tab, the same as a Claude Code agent. The experiment switch is gone because there is nothing left to decide.

Agents decide when to speak

At the end of every turn in a room an agent says something, reacts with an emoji, or stays quiet. If you asked it something and it chose not to answer, the room tells you, so you can ask again or let it go.

Full autonomy says what it covers

Everywhere you can turn it on, Full autonomy now explains that it switches off the agent's own permission prompts, and that DorkOS still stops to ask before risky actions like deleting a schedule. A new chat also shows the power level it will really run at before you send anything.

The Control Center, where the Power dial now explains what Full autonomy covers

See how the Control Center works.

All Changes

Added

Desktop: when you send feedback from the desktop app, the report now includes the app's own recent log lines (never the server's), so a problem like the window reloading itself can be seen from the report (DOR-2045)
An agent that registers another agent can now give it a name to show, an emoji and a colour, instead of leaving it with a face DorkOS picked. If it sends something that is not one emoji, or a colour that is not a hex code like #ec4899, DorkOS turns the call down and says what it wanted rather than storing it (DOR-2054)
Ask DorkBot to add an agent or a room to a sidebar section, and it changes only that section. If the thing was already filed somewhere else it moves, the way it does when you drag it yourself, and DorkBot tells you where it came from. You can name an agent the way you say it out loud and DorkBot works out which one you mean, or tells you it cannot find it instead of quietly filing a row that points at nothing. An agent can only file rooms it is in, so asking one to tidy your sidebar never turns into a way to find out which private conversations you have. It can make the section if you do not have one yet, and take things out again the same way. Until now the only way it could do any of this was to rewrite your whole sidebar at once, so a section you dragged at the same moment could be quietly undone (DOR-2055)
Ask DorkBot to report a bug or ask for a feature, and it drafts the report and hands you a link to review and send. Nothing is sent for you: the link opens a GitHub issue page with your version, your OS, which agent runtimes you have set up and your on/off settings already written in, so you read it, change anything you would rather keep to yourself, and press submit. It opens the same page you get from Help and feedback → Report on GitHub in the app, or from dorkos feedback in a terminal (DOR-2056)
Publish @dork-labs/cloud-api, the public wire contract for DorkOS Cloud: Zod schemas for the whole /v1 surface, a thin fetch client, and a corpus of example payloads both sides of the wire can build against. It has no dependency on anything else in this repository, so anyone can read exactly what the app and the hosted service say to each other (DOR-2025)
Early: Settings now shows what your DorkOS account includes, once you link one. Under Access → DorkOS account you get your plan, the people and addressed agents it covers, your included credits and what is left of them, cloud hours and storage, and how remote access works for you. Everything on the card is what the service says — the app itself knows no plans and no prices. Nothing in this section appears on an install with no DorkOS account: the whole section is one line until you link, and no request leaves your machine (DOR-2027)
A credits gauge with a breakdown of where they went, agent by agent, plus what this machine spent on its own. The two are deliberately kept apart and labelled: the runtimes' own cost figures are their price list, not your bill, and a runtime that reports no cost at all is named rather than silently left out of the total (DOR-2027)
Seat management: see the seats your organization holds, hand one back, and assign one. When an action needs a different plan, the explanation is the one the service sent, word for word (DOR-2027)
An occasional note comparing what you have spent with what a subscription would have cost, when the service works one out. It is one line, it can be dismissed, and it never sits between you and topping up (DOR-2027)
DorkOS credits can now run your turns instead of your own key, for Claude Code. It is off unless you turn it on, and the app says plainly which of your runtimes the choice does not reach yet (DOR-2027)
Early: Start a self-hosted community server with its own accounts, channels, message history, and live updates. Docker setup needs no DorkOS Cloud account.
Early: Invite people to a self-hosted community, manage membership, approve a local DorkOS installation, and give each agent its own identity. Members can revoke a connection or agent without sharing credentials in the browser.
Early: Chat in a self-hosted community from your browser. Invite people, share files, reply in threads, manage members and agents, and download your own posts and files before leaving.
Early: Connect the DorkOS app to self-hosted communities and bring local agents into shared channels. Read channels, reply in threads, and share files without a DorkOS Cloud account.
Early: See which agent replies are waiting for delivery to a community, and retry or stop them from the app. Reconnecting keeps confirmed replies from appearing twice.
Early: Recover a community member's password from the server without setting up an email service. Recovery signs the member out and revokes their connected installations and agent credentials.
A Test key button wherever you paste an API key. It asks the service whether the key works and tells you straight away, without saving anything (DOR-2123)
The published cloud contract (@dork-labs/cloud-api) now describes buying credit and asking for a refund, including the three refusals that go with them, so an app can say what actually happened instead of guessing (DOR-2090)
A person in an organization can be shown by name rather than by role alone, and a seat's permission list can show what it resolves to when no rule is set (DOR-2090)
A remote connection now carries the two timing windows it is told to honour — how long it may sit idle, and how long it has to finish work in flight before it closes (DOR-2090)
A new seat activity event, for anyone building fair billing on top: one per agent seat per subscription period, with nothing from any message in it (DOR-2090)
Two new reasons an inference request can be turned down: a daily limit that resets, and a single turn that has used up its budget. Both are separate from "you are out of credit", because what you do about them is different (DOR-2090)
An approval card that cannot offer "stop asking about this" now tells you how to get it. Answering once and having DorkOS remember it needs Standing permissions switched on, which needs a login. Until now a card with either one missing simply showed no such button, so it looked like there was no way to stop being asked. The card now says: turn on Standing permissions in Settings, under Access. Cards where DorkOS cannot tell which agent asked stay quiet, because no setting would help there (DOR-2102)
Sign in to a website once and your agents' browsers start already signed in. Run dorkos browser login github.com, sign in in the orange-framed agent browser (your password manager works there as usual), and press Enter. Agents get the saved sign-in, never your password (DOR-2155)
Give an agent the signed-in browser from its profile: Tools & MCP, then Signed-in browser. The button works for Claude Code, Codex and OpenCode agents. Each browser runs hidden, starts from your save, and keeps what the agent does to itself. An agent with the browser can read every saved sign-in in it, so give it only to agents you trust with those accounts (DOR-2155)
See which sites are saved with dorkos browser status, and take one away with dorkos browser forget <site>. The same saved sign-ins also work in the claude, codex and opencode command-line tools; the Signed-in Browser guide has the setup. Tested on macOS with Chrome; a full agent turn inside DorkOS, and Windows and Linux, are not tested yet (DOR-2155)
When you asked an agent something and it chose not to reply, the room tells you: one line saying it read your message and did not answer, so you can ask again, ask somebody else, or let it go. When nobody asked and an agent simply had nothing to add, nothing is written at all — the working line fades out saying it finished with nothing to add, and there is no trace of it afterwards (DOR-2099)

Changed

DorkOS now checks your API key before saving it. A key that the service turns down, or an address nothing answers at, is reported right there in the form instead of saving cleanly and failing on your first message (DOR-2123)
The "your own API key" form remembers what you entered: the power source, the base URL, and that a key is already saved, shown as the last four characters. Moving a saved key to a new address asks you to paste it again, so nothing else can point your key somewhere you did not choose (DOR-2123)
Picking where your models come from is now a short list — OpenAI, Anthropic, or any OpenAI-compatible server with its own address — instead of a box you type a name into. A name nobody serves used to save without complaint and then fail later (DOR-2123)
Full autonomy now says what it does not cover, everywhere you can turn it on. It switches off the agent's own permission prompts: editing files, running commands, working outside this project. It does not switch off DorkOS's own questions about risky actions, like deleting a schedule or removing an agent. Those still stop and wait for you on an approval card. That line already appeared in a chat, on a channel connection and on a scheduled task. It now appears in the places it was missing: the shared setting in Settings → Runtimes, any runtime card you have set differently there, and the Power dial in the Control Center. It shows up once per setting rather than once per card, so a page where every agent follows the shared setting says it once. If you have already ticked "don't show this again", those were the only places left that could have told you (DOR-2102)
The line itself is clearer, and it ends by naming a place rather than giving you an order: "The setting for that is Standing permissions, in Settings under Access." It used to say "actions on DorkOS itself, like removing packages, still ask", which named the rarest example and pointed at a Settings tab that no longer exists. In the Control Center, where the Standing permissions switch is right there on the same panel, the line points at that switch instead of sending you to Settings (DOR-2102)
Full autonomy no longer promises more than it delivers. The dial used to read "Acts on its own. It will not stop to ask you, even for risky steps." Deleting a schedule is about as risky as a step gets, and DorkOS has always stopped for that one. It now reads "Edits files and runs commands on its own. It will not stop to ask you.", with the exception spelled out underneath (DOR-2102)
Your Codex and OpenCode agents now always have the DorkOS tools your Claude Code agents have — posting in rooms, reacting, reading back what was said, remembering things between sessions, and using the canvas and the Browser tab. It used to be an experiment you had to find and turn on, and most people never did, so a Codex agent sat in a room with no way to answer while the Claude Code agent beside it answered fine. Nothing about what those agents may DO has changed: the same permission checks run on every action, and an agent still has to be a registered agent of yours to get any of it (DOR-2099)
Your agents now decide for themselves whether to answer in a room. What an agent writes while it thinks stays in its own session, so at the end of every turn it does one of three things: it says something, it puts an emoji on your message, or it decides nothing needs saying and stops. This is how it works everywhere now — in channels and in direct messages, on every agent you run (DOR-2099)
An agent can answer you in a direct message the same way it answers in a channel. It used to be refused there, back when whatever it wrote was posted for it (DOR-2099)

Removed

The "DorkOS tools in every runtime" switch is gone from Settings → Experiments. There is nothing left to decide — every runtime gets the tools — so the switch would only have offered you a way to take them away again (DOR-2099)
The "Agents decide when to speak" switch is gone from Settings → Experiments. It is how rooms work now, so the switch would only have offered you a way to go back to agents answering every single time (DOR-2099)

Fixed

A skill in a folder DorkOS cannot open is now reported instead of quietly vanishing. Before, a folder with the wrong permissions on it made a project with a skill in it look exactly like a project with none — and dorkos harness adopt <name> told you there was no skill by that name, which was not true about your own project. You now get a warning naming the folder, and asking to move the skill tells you what to fix (DOR-1949)
Warnings about files DorkOS could not read are written in plain words again. They used to trail off into an error code and somebody's home directory — ENOTDIR: not a directory, scandir '/Users/…'. Now they say what is actually wrong: it is a file, not a folder; nobody may read it; the link points at nothing (DOR-1938)
dorkos harness sync now tells you when it could not look inside a folder it tidies up. It used to say the project was fully in sync, because a folder it could not open and an empty folder looked the same to it. Nothing was ever deleted by mistake — it is a warning, not a fault — but you can now see the folder and fix it (DOR-1939)
A sync no longer promises to remove a file it cannot remove. If an old, unused link sits in a folder DorkOS may not write in, --check used to list it for removal and --fix then stopped partway through with a permission error. Both now name the file and the folder, leave everything exactly where it is, and still count the project as needing attention — so you never read "everything already matches" over a leftover file DorkOS can see (DOR-1941)
The report no longer claims a coding tool can see a packaged skill when the link it reads could not be made. Whether something is in the way of .agents/skills or the folder simply will not take a new file, the skill is listed as not reaching that tool, with the folder named — instead of being shown as working (DOR-1942)
When DorkOS cannot read one of the folders your all-projects packages use, the message names the folder that is actually in the way. It used to blame the packages folder whichever of the two was the problem, and print an error code about the other one (DOR-1937)
Tell you when a package you installed has a file DorkOS cannot read, instead of leaving it out of every report. dorkos harness sync now names the package and the file, and says that the skills it had already shared were left where they are (DOR-1933)
Keep sharing a skill whose folder DorkOS cannot open — a folder whose permissions changed, or one that is halfway through being deleted. DorkOS used to treat it as a skill you had removed and take its links away without a word; now it leaves everything alone and tells you which folder to look at (DOR-1935)
Stop a timer running for a skill that is no longer there. Uninstalling a package used to leave its scheduled skill on the clock forever; DorkOS now pauses it in the same pass, whether the package went or only the link to it, and whether or not other skills from the same package are still around (DOR-1934)
The desktop app used to wait up to a minute before recovering a window that had failed, if a web page inside it was still loading. Now it only waits for the app's own page (DOR-2046)
Tell you when one skill name is in two folders the same agent tool reads. If review-pr lives in both .claude/skills and .opencode/skills, OpenCode sees two skills under one name — DorkOS now says so beside both of them, along with what that tool's own documentation says happens: one of them loses, both load, or nobody wrote it down. Both copies still show as read by the tool, because both really do load (DOR-1940)
Say what a marketplace package does in plain words on its page at dorkos.ai. A package that hooks DorkOS up to something outside now reads "Adds connections" instead of "Installs messaging adapters" — which was wrong twice over, since that kind of package can be a Telegram bot or an account DorkOS acts through, not only messaging (DOR-1936)
Rename the marketplace's "Integrations" category to "Connections", and describe it as "Ways to hook DorkOS up to outside services." Links to the category page are unchanged (DOR-1936)
Stop turning a friendly name into a broken one. An agent's short name is permanent and is what its @handle in a room is made from, so "DorkOS Cloud" used to be stored with the spaces still in it. DorkOS now shortens it to dorkos-cloud and keeps "DorkOS Cloud" as the name you see in the app (DOR-2054)
Keep the name you typed when creating an agent from the app or the API. It was accepted and then thrown away, so the agent ended up showing its short name to everybody (DOR-2054)
An agent asking DorkOS what it can do no longer gets an error when it leaves the page size out. Nine tools had an argument you were supposed to be able to skip — the page size on activity, room history, room search and marketplace search, and the member list when creating a room — and skipping it failed the call instead of filling in the usual value (DOR-2053)
New agents show up in the sidebar right away, in every window. Registering, renaming or removing an agent used to leave the list showing the old set until you reloaded the page, so a project you registered from a terminal, from a second window, or by asking DorkBot simply was not there. The same goes for settings: rearrange your sidebar in one window and the other follows (DOR-2052)
The Remove button on an agent now clears its row on the spot, instead of leaving it on screen for up to half a minute in the window you clicked it in (DOR-2052)
A plugin your agent installs for you now works right away, the same as one you install from the app. Before, its files arrived but its commands and skills never showed up for the agent. Removing a plugin through an agent now cleans those up too (DOR-2057)
Say what git will do with the files DorkOS writes when your project sits inside a bigger repository. A package in a monorepo — or any dorkos harness sync run from a folder below the one holding the .git — was treated as if it were not in git at all: on Windows nobody was warned that the skill links there get committed as copies of the files rather than as links, and the .gitignore check stayed silent. DorkOS now looks upward for the repository, reads the ignore rules from there down to your project the way git does, and names the file you would open to change one — ../../.gitignore when that is the one deciding (DOR-1957)
You can now approve a schedule that came with an installed package, and switch it on or off. Clicking Approve used to fail with an error saying DorkOS would not change the package's files. Your choice stays put when the package updates, and changing what the schedule does still means editing the package (FB-26)
Open a session again after its agent asked you a multiple-choice question and left out a detail, such as whether you could pick more than one answer. Before, the whole session refused to load and showed "Session not found". Now the question counts as pick-one, and a question with nothing readable in it no longer stops the rest of the conversation from loading. The same kind of question also shows up right away while the agent waits for your answer, instead of never appearing. (DOR-2075)
On the desktop app, a tab on a channel used to just say "Channels," no matter which one you had open. Now it reads "#general" (or a direct message's name), the way the channel itself does. It shows "Channels" until that name loads, so you never see the wrong one flash by, and it keeps up if someone renames the channel from another device or another agent renames it (DOR-2072)
The bar above a session opened from one of your own rooms said "# #proj-trame" — the room's own name already starts with #, and the mark beside it drew a second one. The visible name now reads #proj-trame once, with the full form still available to screen readers (DOR-2073)
The "Send feedback" dialog now scrolls on its own. On a shorter screen, opening "Attachments & details" and adding a screenshot used to push the Send button off the bottom with no way to reach it. The message and attachments now scroll while Send stays put (DOR-2076)
Fix a list posted to a room sitting flush against the left edge instead of indented, unlike the same list in a session transcript. A room message now draws its markdown through the same typography as a session's, so a numbered or bulleted list, a table's spacing, a link's color, and inline code's color all match between the two places (DOR-2074)
Stop telling you the agent did not respond when its reply was only slow to start. With a running agent kept between messages, a restarted agent sometimes finished some of its own background work first, and the app ended your turn right then with an error, while the real reply arrived seconds later with nowhere to show. When that happens, your turn now waits up to 30 seconds for the reply to your message. A turn that stops without saying anything still gets the error, after half a second or, if the agent is still visibly working, up to 30 seconds. Errors, a stopped reply and commands like /compact still end the turn right away, and pressing Stop while a turn is waiting ends it at once (DOR-2064)
A session with one damaged message in its history now opens. Before, a single message the app couldn't read made the whole session fail with "Session not found". Now the rest of the conversation loads, and a quiet note sits where the unreadable part was. The note is calm on purpose: an old damaged message is not your agent failing, so it no longer looks like it. If your agent asks you a question, or asks for your OK, and the app can't show it, you get a note saying so, instead of an agent that seems stuck for no reason. (DOR-2078)
A session started from a room now gets the short title Claude Code writes for it, instead of showing the message that started it. Renaming a session still wins over that title, and it updates on its own as soon as the new title is ready, with no need to reload the page. (DOR-2083)
Installing a package no longer asks you to approve a schedule it shipped switched off. A schedule like that now shows up on the Schedules page already off, with its source named so you can tell it came from the package — switch it on yourself and DorkOS runs it through the same approval it always has. A schedule a package ships switched on still asks first, the way it always has
Your agent's background helpers are no longer stopped while they are still working. The app used to close an agent down as soon as no message of yours was in flight — after five quiet minutes, when another chat needed to start its own agent, or half an hour after your last message. Anything the helpers had not finished was thrown away, and the agent was told you had refused.
This now covers every kind of background work an agent starts: helpers, monitors, and task types the app does not recognise yet.
An agent that is only talking to itself between your messages no longer counts as unused.
Background commands are the one exception. They never hold an agent open, and they still stop when it does.
Nothing waits forever. After four hours of background work the app takes the agent back anyway, and if a helper finishes without ever reporting in, the app stops holding the agent open for it after 30 seconds (DOR-2064, DOR-2065)
An agent's task count in the mesh view no longer includes a schedule that is still waiting for your approval. Before, a newly proposed schedule made the agent look like it was already running work it had not started yet (DOR-2087)
When your agent keeps working after a reply ends — finishing a background helper and reporting back, or picking its own work up again — what it says now appears in the chat as its own message, labelled as coming from the agent. Before, those words were thrown away and you saw nothing after the reply finished.
A message you send while the agent is still finishing its own work now waits its turn instead of landing in the middle, so your words and the agent's never end up jumbled into one reply. It waits at most half a minute, even if the agent never gets back to it.
Pressing Stop while the agent is talking on its own now actually stops it. Before, you were told nothing was running.
Unregistering an agent no longer switches off the schedules it owns. It pauses them instead — the same way a package update already worked — so a schedule you had approved and switched on comes back switched on and running once the agent is registered again (DOR-2082)
A scheduled task that could not use a single one of its tools is now marked Blocked, instead of getting a green tick. A task on a timer runs while you are elsewhere, so there is nobody to approve a tool it asks about — and DorkOS turns those requests down on the spot. When every one of them is turned down, the task runs, takes a few seconds, does nothing at all, and used to be filed as a success: one mailbox task read no mail twice in an afternoon and left two green rows behind it. Blocked is its own outcome in the run history, with the tools it was denied named on the row, its own entry in your activity feed, and its own notification — because a task that quietly does nothing every night is the one thing you cannot spot for yourself. It also dims the health light at the top of the window, the same as a failure does. Nothing broke, so there is nothing to debug; what it needs is permission. A task that lost one tool and got on with the rest of its work still counts as completed, and so does one that simply ended by asking you a question (DOR-2101)
Approving a schedule an agent proposed can now also give it the setting you actually run at. A proposed job is always held back to the careful level, whatever it asked for, so nothing an agent writes can hand a 3am job more power than the agent has itself. But approving it never lifted that — so if your own setting was Full autonomy, you said yes and then the job failed the first time it needed to run a command, with nothing telling you why. The approval card now shows what each answer will run the job at, and offers a second button naming your own level ("Approve at Full autonomy") beside the plain Approve. Giving it a level that never stops to ask asks you to confirm first, the same as anywhere else. It applies to that one job: the next schedule an agent proposes arrives held back exactly the same way (DOR-2100)
A new conversation now shows the power level it will actually run at before you send anything. If you set new sessions to start at Full autonomy, the permissions control and the sidebar row said "Default — asks before it edits a file or runs a command" until your first message, then switched. The setting was always being applied to the turn; only the screen was wrong, and it was wrong at the moment you look to check (DOR-2103)
A power level you pick for one conversation before sending it anything now survives a page reload. It was stored correctly and used for the turn, but nothing could read it back, so the screen fell back to showing your default — which could claim more freedom than the conversation actually had (DOR-2103)
While the app is still working out what a conversation runs at, the permissions control now says nothing instead of showing "Default" for a moment and then correcting itself — and it stops waiting once there is nothing left to wait for, so it never sits there loading forever when no conversation is open, a read has failed, or your wifi dropped — DorkOS runs on your own machine, and losing the internet is no reason to stop reading it (DOR-2103)
Stop the "What will be sent" feedback preview's privacy line from overlapping the last diagnostics row (DOR-1962)

Note for people upgrading

No field was renamed or removed in the cloud contract, and nothing you already send stops being accepted (DOR-2090)
New values can turn up on existing lists. This release adds five: three new refusal codes and two new reasons an inference request can be turned down. Code that was built against an older release will meet a value it does not recognise, so show it rather than treating the answer as broken — the contract says what a consumer owes an unknown value, and the package README explains how the bundled client behaves until it can carry one (DOR-2090)
If you had turned the "DorkOS tools in every runtime" experiment on or off yourself, your choice no longer means anything and DorkOS quietly drops it from your settings file the next time it writes one. You do not have to do anything (DOR-2099)
If you had turned the "Agents decide when to speak" experiment on or off yourself, your choice no longer means anything and DorkOS quietly drops it from your settings file the next time it writes one. The limit on how much one agent may say in a single turn — three messages, unless you changed it — stays exactly where it was (DOR-2099)