This release is about honesty. DorkOS now tells you when a sign-in breaks, when a run fails, and what a picture your agent made looks like — and it lets you set a hard limit on what any agent is ever allowed to do.

Highlights

DorkOS warns you three days before your Claude login runs out. It tells you the moment any sign-in breaks — even when the work was a scheduled task nobody was watching — and can push that to your phone. Best of all, you can sign back in right from the error card in the chat, and your message sends itself again once you do.

Cap what an agent is ever allowed to do

Give any agent a ceiling of observe, act, or destructive. Anything past that line is refused, and no approval unlocks it. That is how you get an agent that reads your repos and can never uninstall anything.

See the pictures your agents make

Screenshots, generated images and pictures a tool hands back now appear in the conversation on Claude Code, Codex and OpenCode — and they are still there when you come back days later. Before, they were thrown away in silence: you paid for the turn and saw nothing.

Remote Access actually works

The Mac app was shipping without the piece of ngrok that does the real work, so turning Remote Access on always failed. It now works, survives a restart, says what went wrong when it fails — and can no longer be switched on by anything but a person.

Every agent gets a face

New agents are born with their own color and emoji, so your team reads as a row of characters instead of a row of letters. Agents you install from the marketplace arrive wearing the face their author gave them.

The Team page, with each agent wearing its own color and emoji

Scheduled tasks tell the truth

A run that hit an error now says so instead of showing a green tick. An agent's edit to your task really lands — and if it changes what an approved task does, the task pauses and waits for you to approve the new version. The edit screen shows the agent a task runs as, instead of offering a choice that was silently thrown away.

A scheduled task's edit form, showing which runtime and model it runs on

All Changes

Added

You can now cap what an agent is ever allowed to do. Pick its limit in the agent's Tools settings, or run dorkos agent update --path <dir> --ceiling <observe|act|destructive>: observe reads only, act changes things but never deletes them, and destructive is no extra limit. Anything past the line is refused, and no approval unlocks it — so this is how you get an agent that reads your repos and can never uninstall anything. Every agent starts with no extra limit, so nothing you already run changes until you set one. An agent can tighten its own limit; only you can loosen it. This covers what an agent asks DorkOS to do — one that can run terminal commands can still act outside DorkOS, and turning on Require login (Settings, under Security) closes that door too (DOR-486)
Find out when an agent's sign-in stops working, even when the work was running on its own. Before, a scheduled task, a room reply, or a message from a connected chat would just fail quietly. Now DorkOS notices and tells you which sign-in it was — Claude, Codex or OpenCode — and, if you run more than one Claude account, which account. You get one note about a sign-in, not one for every job that failed because of it, and opening it takes you straight to the place to sign in again (DOR-1654, DOR-1682)
Agents you reach through a connected chat, like Telegram or Slack, tell you the same way. Before, those agents were the one case that stayed quiet and left you guessing why they had stopped answering (DOR-1654)
DorkOS now tells you when your Claude sign-in is about to run out, three days before it does, on the Claude card in Settings. It keeps saying so through the last few hours, when signing in again is most urgent. Doing it when you choose takes a moment; being caught out used to cost you a failed turn (DOR-1653)
If you work through an API key instead, DorkOS stays quiet. It only mentions a sign-in that is actually doing your work, so a stored login you no longer use never nags you (DOR-1653)
A sign-in that stops working can now reach your phone. If a scheduled task or an agent reply fails because Claude, Codex or OpenCode needs you to sign in again, DorkOS puts a note in your inbox right away, and if nobody has dealt with it after a couple of minutes it pushes to any device you have subscribed and to your connected chat apps. Tapping it opens the page where you sign in. Change that wait, or turn it off, under Settings › Notifications (DOR-1657)
When a runtime's sign-in stops working, the app now shows a banner across the top naming the runtime, with a button that takes you straight to signing in again. Before this, a browser tab told you nothing — a dead sign-in reached you only through the bell, a phone notification, or the desktop app, while your scheduled tasks and agent replies quietly failed. The banner clears itself on the next task, message or reply that gets through on that runtime, since trying is the only way DorkOS can tell that a sign-in works again (DOR-1680)
See the pictures your agents make. When an agent generates an image, or a tool hands one back — a screenshot, an image from an MCP server — it now appears in the conversation where it happened, and it is still there when you come back to it days later (DOR-1663)
Images from tools now work on all three runtimes. Ask Claude Code to read a PNG and the picture appears right under the step that read it, and Codex shows images that come back from a connected app. Before, this produced nothing at all on the runtime most people use: no picture, no error, no hint that anything had happened. If the only thing an agent produced was an image, the whole turn used to vanish (DOR-1663, DOR-1664)
When a picture cannot be kept — it is too big, or a kind DorkOS does not store — the conversation says so instead of showing you nothing, and that notice is still there after you reload (DOR-1663, DOR-1671)
Two gaps worth knowing: images an OpenCode model draws itself are dropped by OpenCode before DorkOS ever sees them (anomalyco/opencode#46600), and Codex has no way to send an image its own model drew. DorkOS is ready for both the day they are fixed (DOR-1663, DOR-1664)
New agents now show a face. Each one gets its own color and emoji the moment you make it, so your team reads as a row of characters instead of a row of letters (DOR-949)
An agent you install from the marketplace now arrives wearing the face its author gave it (DOR-949)
When DorkBot picks the name DorkOS calls you — usually because you told it "call me Dorian" in a chat — your team page, your account menu and Settings › Profile now say "Suggested by DorkBot" under that name. Save a name yourself in Settings › Profile and the note goes away for good, even if you save the same name it picked. Names already on your machine keep working exactly as they do today and get no note, because DorkOS only started recording who picks a name in this release (DOR-1022)
Ready-made agents from the Marketplace now tell you up front if they come with work on a timer. Before you create one, DorkOS names the job, when it runs, and how much it can do on its own — the same plain-language wording every other kind of package already shows. Ready-made agents were the one kind that skipped the install screen, so this was the one place that fact went unsaid (DOR-644)

Changed

When an agent's sign-in stops working mid-chat, you can now sign back in right there in the conversation. The card shows the sign-in running and tells you when it lands, so you no longer have to open Settings, find the right agent, and press Reconnect. If you would rather use an API key, that link is still there, one quiet tap away. On a computer with more than one Claude account, it signs you back into the account that chat is actually using, so you never fix the wrong one (DOR-1651)
Sign in once from the card and your message goes again on its own. No retyping, and no Retry button to hunt for (DOR-1650)
It stays out of the way when you have moved on. Started typing something else while signing in, or already have a message running or waiting in line? Then nothing is sent behind your back — the card just says you are signed in and leaves the Retry button there. Whatever you typed is left exactly where you typed it, and if you tried again while signing in, it is the newer message that goes (DOR-1650)
When you open DorkOS on your phone and an agent's sign-in has stopped working, the card now tells you plainly that signing in needs the computer DorkOS runs on. Before, it showed a Sign in button that always failed. Settings says the same thing on the same screen where you would otherwise press Connect, so the app no longer tells you two different stories two clicks apart. The card keeps its Retry button, so once you have signed in over there you can send your message again from your phone with one tap (DOR-1655)
DorkOS now stops telling you about a broken sign-in once it is working again. It watches for the next piece of work that gets through on that sign-in, then files a second note saying it came back. If the same sign-in breaks again later, you hear about it again straight away. Notes are written in the past tense now ("Your Claude sign-in stopped working"), because a note you read the next morning should still say something true (DOR-1657)
Pressing Stop now tells you what actually happened. Before, every ending looked the same: the agent hearing you and winding down, DorkOS killing the process because it never answered, the reply having already finished, and the agent refusing to stop all came back as the same yes or no. Now each one is its own answer, and the app only says an agent "stopped" when it really saw it stop. If the agent did not confirm, you get "Stop requested" and the Stop button stays there so you can press it again — instead of being told it worked while the agent keeps going (DOR-1015)
Stopping a background task answers with what happened rather than a plain yes or no, and no longer reports "already stopped" for a task it could not confirm, because that task is probably still running (DOR-1015)
"Always Allow" on a permission card now says how far the permission reaches — this session, this project, or all your Claude sessions — right on the button. Some of these grants get written to a settings file, so they outlive the chat you gave them in; now you can see that before you tap, not after (DOR-1462)
The Workspaces page now shows the copies of your code that actually exist. It reads your workspaces folder directly, so the worktrees your agents really work in finally show up, grouped by project, with the branch, how many files hold unsaved edits, how far ahead of or behind the remote each one is, and when it last got a commit. Before this, the page could only list copies DorkOS had made itself, and it had never made one, so it sat empty while dozens of real worktrees sat in the very same folder. Worktrees you reach through a shortcut (symlink) are included, and a broken shortcut is called out rather than skipped (DOR-1056)
The page only reads. It never creates, changes, or deletes a copy, so a stray click can't take a folder out from under a running agent (DOR-1056)
It also refuses to guess. A copy whose branch was merged and deleted says so, rather than claiming it's in sync with a branch that no longer exists. A folder DorkOS can't read gets a row marked "Can't read" instead of quietly disappearing, and if a whole folder or the scan itself fails, you're told the list is incomplete instead of being shown an empty page that means "you have none" (DOR-1056)
Picking a color or an emoji for an agent yourself still wins. DorkOS only fills in the half you left blank, and it never changes a face you already set. Clearing a color or emoji puts back the face the agent started with, instead of a different one (DOR-949)
Approval prompts, sign-in receipts, and the notices a room posts on its own now read as plain sentences, without a stray dash in the middle (DOR-1261, DOR-611)
Install screens no longer say a package's scheduled job "starts switched on" — in the app or in the terminal. Nothing a package brings ever starts on its own: DorkOS parks every new schedule until you approve it, so all three screens now say that instead of promising the opposite (DOR-644)
Asking the dead-letter list for an empty endpoint name is now an error rather than a way to get the whole list. Leave the filter off entirely to see everything

Removed

The "Scheduled run notifications" setting is gone. It promised a toast when a scheduled task finished, and nothing ever showed one (DOR-1522)

Fixed

Reopen a chat that stopped because your sign-in ran out, and you now get the same "Sign in again" card you saw at the time, with the button that fixes it. Before, reloading turned that failure into a line that looked like your agent had said it. Other stop notices from Claude, such as hitting a usage limit, come back the same way: as a notice you can read, not as words your agent said (DOR-1649)
Search stops filing those notices as things your agent said. This applies to conversations indexed from now on; notices already in your search index stay there until you delete it, which rebuilds from scratch (DOR-1649)
When a Codex or OpenCode sign-in dies in the middle of a turn, you now get the "Fix sign-in" button instead of a generic crash message with no way forward. Codex trouble is caught on the path it actually takes — before, a live Codex run that lost its sign-in showed the raw text the tool printed and offered nothing to click — and whatever the agent's own tool said is kept under "Details" instead of being dropped (DOR-1656)
A Claude sign-in that had already run out no longer shows as "Ready". DorkOS was only checking that a sign-in was stored, not that it still worked, so a run-out sign-in looked fine until a turn failed. It now offers you the sign-in button instead (DOR-1653)
On a machine with more than one Claude account, "Fix sign-in" now signs back into the account DorkOS runs new sessions on, instead of whichever one the server happened to be pointed at (DOR-1652)
When an OpenCode turn failed, reopening the chat used to show your question and nothing after it. The failure is now there where it happened, in plain words with the fix to try, and the provider's own wording tucked behind Details — the same thing you were told while the turn was running, instead of raw error text on reload (DOR-1666, DOR-1678)
A chat turn that fails now says so. Some failures used to look like a clean finish: the session went quiet, the text explaining what went wrong disappeared, and you got a "finished" note instead of a warning. This happened whenever Claude Code named its own reason for stopping, like a model error, a problem reaching the service, or a prompt that ran too long. Now the session is marked with the error and keeps the explanation on screen, and if you are away from your machine DorkOS starts trying to reach you about it (DOR-1676)
Stopping a turn and a turn crashing no longer look the same. When a turn was cut short, DorkOS said you stopped it, whether or not you had touched Stop — so an agent that hit a refusal from the service and gave up on its own was filed as a session you ended on purpose, and the message explaining what went wrong was wiped off the screen. A turn nobody stopped that ended with a real error is now marked as an error and keeps its explanation. A turn you stopped still shows as stopped, with no red mark and no scary text. Scheduled runs get the same fix, where it mattered most (DOR-1681)
Pressing Stop no longer looks like the agent crashed. When an agent does not answer a stop quickly enough, DorkOS ends it — and that ending was reported as a failure, with a red error on the reply you had just stopped. It now shows as what it was, including when you stop a message the moment you send it (DOR-1302)
Stopping two replies in a row no longer makes the third message refuse to send with "This chat's agent keeps stopping". That count is meant to catch an agent that cannot stay running, and a stop you pressed yourself no longer counts against it (DOR-1302)
A scheduled run that hit an error now says so. Run history used to mark those runs finished, with a green tick and no explanation, so a task that died overnight on an expired sign-in looked like it had worked. Now the run is marked failed and shows what went wrong, an expired sign-in leads with what to do about it, and the failure reaches your notifications and your daily report like any other (DOR-1658)
Scroll back to something that went wrong earlier in a chat and its Retry button is gone. That button always re-sent your newest message, not the one that failed, so pressing it on an old error sent the wrong thing without saying so. The error itself still shows, and you can always type again (DOR-1677)
An old card about a sign-in that ran out keeps its sign-in button. Your login really is broken, whenever it broke, so fixing it there still works (DOR-1677)
The model menu now says which models can't do the job, instead of letting you find out after you send a message. Models that can't use tools are grouped under their own heading, and a model that answers with pictures says so (DOR-1660)
Models that no longer exist are gone from the OpenCode menu. The list is checked against what OpenRouter actually serves, so a model quietly retired upstream is no longer offered. If that check can't be reached — on a plane, or behind a firewall — you get the full menu instead of a wait (DOR-1660)
Choosing a model your runtime can't run is refused right away with a clear message, rather than saved and failed on your next message. A shortened, unconfirmed list never turns your choice down, though: with no OpenCode provider connected, a model you can really run may sit outside that list, so only a confirmed list refuses anything (DOR-1660, DOR-1688)
The model menu refreshes when you connect a provider, sign in, or install a local model. It used to keep showing the old list for up to half an hour (DOR-1660)
When OpenCode can't find any of your credentials, the menu no longer dumps thousands of unchecked models into the picker. It shows a short list and says plainly that nobody has confirmed you can run any of them — and the lists in Settings › Runtimes and on an agent's settings now say the same thing, instead of looking complete when they aren't (DOR-1660, DOR-1674)
You can read the whole model name in the picker. The panel is wider, so a long name like "Qwen: Qwen3 Coder 480B A35B Instruct" and its note both fit, and when an id is too long the picker trims the front and keeps the end — because two models can share everything but their last few characters (DOR-1673)
Picking a model on a brand-new session works again. If you started a session, switched it from Claude Code to OpenCode, and then chose a model, DorkOS refused with "The claude-code runtime cannot run model …" — naming a runtime you had not picked. It now checks against the runtime you actually chose, and saves your choice when nobody has decided yet
/compact now works on OpenCode sessions. It had been failing every time with a "bad request", because DorkOS never said which model should write the summary (DOR-1668)
A conversation that had a permission mode saved under a name one agent tool uses but another does not no longer breaks the next reply. It starts in the careful "ask me first" mode instead, and your saved choice is left exactly as you set it (DOR-885)
Come back to an OpenCode session after a restart, change just one setting — the model, say — and it now keeps everything else you had chosen. Before, the settings you did not touch quietly reverted: a session you had trusted to work on its own dropped back to asking before every action. The settings panel kept showing your real choices the whole time, so there was nothing to see until you noticed the agent behaving differently (DOR-1152)
Changing a setting on a chat no longer answers as if DorkOS already knew which agent tool would run it. A chat records its tool when you send it your first message, and until then the answer says outright that it is a guess (DOR-1693)
A session running a runtime's own default model no longer shows a meaningless "· default" after the runtime name, including in the moment right after startup (DOR-1279)
OpenCode agents no longer start every reply by reciting the setup notes DorkOS gives them, followed by a copy of your own message. The reply now begins with what the agent actually says, in chat and in rooms — where those notes had included what other people in the room had said. Summaries of scheduled runs show the agent's answer rather than its setup notes (DOR-1659)
When an agent is created it is asked to introduce itself. That request came from DorkOS, not from you, and search now leaves it out on every runtime — so searching your history no longer turns up DorkOS's own instructions as though they were your words. Turns already indexed stay until the index is rebuilt (DOR-1669)
Links in error messages are now clickable. When a provider's message points you somewhere — "add credits at …" — that address is a real link you can open, not text to retype. The same goes for tunnel, marketplace, connector and page errors (DOR-1661)
Errors no longer hide what actually went wrong. A failed turn could show "An error occurred during execution." in place of the real explanation, and a sign-in failure could throw the provider's message away entirely. Now the real explanation is what you see, with the provider's exact words under Details (DOR-1661)
The server log is quieter. Every time your agent reached for a DorkOS tool, the log gained a bogus "Invalid API key" error — around four per turn, burying the real problems. Genuine key failures still show up (DOR-1661)
Links in chat now follow the same safety rules as everywhere else in DorkOS, and DorkOS tells you when it refuses one. Before, a link an agent wrote was checked against a looser list than a link on any other screen. When a link can't be opened, the confirmation box explains why and offers to copy the address instead of showing an "Open link" button that would do nothing — and it says which rule stopped it, so a link that works in your browser but not in the desktop app reads that way (DOR-547)
Message search no longer confuses a literal <mark> someone typed into a message with its own highlight markers (DOR-1552)
Claude Code sessions you started in a subfolder now show up under the project they belong to. If you ran claude in something like my-app/packages/api, that conversation was missing from my-app. Each session still shows the folder it is actually running in, and an agent whose open conversation runs in a subfolder now lights up in the sidebar instead of looking closed (DOR-1550)
An agent can now see what happens in a preview it opened in the browser app: console messages, network requests and screenshots reach the conversation, so asking about a page's errors no longer comes back empty. It only worked inside Obsidian before. Switching conversations while a preview was busy no longer files its last console messages under the wrong chat (DOR-1305)
A session's task list no longer loses tasks that were just created when the task history finishes loading late (DOR-1632)
Answering a request again after the server refused your first answer — because another window already answered it — no longer makes its confirmation card disappear too soon (DOR-1633)
Answering the last permission request no longer makes the "Allowed" or "Not allowed" confirmation flash and vanish; it stays long enough to read, in the Inbox, on the home screen, and on your phone. A request you have answered no longer offers you the buttons again a moment later (DOR-1411)
Denying a tool on an OpenCode session no longer offers a reason field that went nowhere. The field appears only when the agent can actually receive it — in the conversation itself as well as in the Inbox (DOR-825)
The Permissions status item judges a mode by what it actually does, not by whether its name happens to be "default". Switching a session to its safest mode no longer shows a false warning, and the item appears only when the agent really is acting with less oversight (DOR-820)
A session running at full power says so the same way everywhere. The details panel used to call it "Bypass All" while the mark on the row called it "full power" (DOR-1499)
When an agent sends a helper off to work in the background and that helper needs your permission, the request has to be turned down for it — and that used to happen in silence, leaving a conversation where the agent quietly stopped making progress. The conversation now says so, names the helper and the tool it lost, and the note is still there when you come back later (DOR-795)
The "working on it" line shows its timer the moment the number is due, instead of occasionally waiting a whole extra second (DOR-1729)
Agents no longer go silent in direct messages when you let them decide for themselves when to speak. An agent would work out a good answer, write it somewhere nobody could read, and send nothing — then reply to a plain "thanks" with a pleasantry. Now the answer it works out is the one you get, and a thanks can just sit there (DOR-1643)
Changing which program an agent runs on no longer moves its running room conversations onto the new one mid-chat, where it kept answering from a blank slate. Stop had the same problem and quietly stopped nothing. A change now applies to the agent's next conversation; to move a room the agent is already in, remove it from that room and add it back (DOR-764)
A busy thread no longer comes apart. A room loads its most recent 50 messages, so once the message a thread started from was older than that, every answer showed up as its own separate line. The room now brings that first message along, and the "60 replies" line counts every answer in the room, not just the ones on screen (DOR-690)
You can no longer end up with two direct messages holding exactly the same people — two rows in the sidebar for one conversation, with half the history in each. Asking for a conversation you already have always brings back the one you already have, and a change to who is in a group message that would create a copy says so instead (DOR-1616)
Renaming an agent, or changing your own name, photo, or handle, now updates right away in any room you already have open (DOR-1114)
Agents working on a room's files can now use their own DorkOS skills there, including the one about how to work on a room's files. A copy an agent has been working in for months picks up newer skills the next time the app restarts (DOR-1640)
Turning an agent's tool groups off now sticks. An agent could quietly turn its own back on, undoing the change you made on its Tools page. The same goes for a handful of other settings that are yours to decide: its short name, the namespace that decides which agents it can reach, whether it speaks in a room without being asked, and which account pays for its work. Agents still edit everything that was always theirs (DOR-1506)
Changing an agent's safety boundaries — its NOPE.md, the list of things you told it never to do — now asks you first. An agent could rewrite that file through its own update tool with nothing shown to anyone, and could switch the whole list off without touching a word of it. Both are now one action that waits for your approval, and the card shows the full new text rather than the first line (DOR-1698)
Adding an agent by folder no longer writes a brand new agent file over one the folder already had. Point it at a project you keep in git and DorkOS quietly rewrote a file your repository owns — and removing the agent afterwards deleted it. DorkOS now takes on the agent the folder already describes, and never deletes a tracked file: removing that agent leaves the file alone and blocks the folder from scans instead, and says so. Adding the folder again brings the agent back (DOR-1019)
An agent's own thinking or progress updates can no longer be mistakenly re-delivered to it as a new message — closed for every kind of update this can happen to, not just the ones already seen (DOR-804)
Two unrelated projects with the same folder name no longer share one internal messaging identity, and a session's origin still shows its project name (DOR-514)
Deleting or unregistering an agent now actually turns off its identity, instead of leaving its access tokens valid until they expire on their own (DOR-490)
An agent or person avatar with no real color on record no longer risks an invisible letter; it shows a soft tint instead (DOR-998)
Profile photos load faster and update reliably when changed (DOR-1008)
The Team page no longer flashes "Nobody to show yet." for a moment on startup before your team appears (DOR-1419)
The team table's column headers no longer overlap into garbled text, like "Manaigedy by", when the table is narrowed (DOR-1287)
Closing a profile returns keyboard focus to whatever you opened it from — a mention, a name, a face — instead of dropping it (DOR-1274)
On a phone, swiping the room sheet closed no longer accidentally opens a member's loudness scale or asks to remove them (DOR-1275)
The New Agent dialog opens your agents folder even when DorkOS is limited to a single project folder, for example in Docker with DORKOS_BOUNDARY set (DOR-437)
When an agent changes one of your scheduled tasks — its prompt, its schedule, its name, or which runtime and model it uses — the change now sticks. It used to disappear within five minutes, even though the agent was told it worked, because DorkOS wrote it to its own records and never to the task's file (DOR-1625)
Because those edits now really land, one thing follows: when an agent changes what an approved task does, the task pauses and waits for you to approve it again, since you never saw this version. Your agent is told and asked to tell you. Changing anything else, including switching a task on or off, leaves your approval alone (DOR-1625)
Editing a scheduled task no longer lets you pick a different agent. The pick was always thrown away when you saved, and while it showed on screen the permission setting below it described the wrong agent — so you could move the dial a step and never be asked about it, then save a task that runs without stopping to ask. The edit screen now shows the agent it runs as and says the agent is set when a task is created. At creation, picking an agent that would stop the run pausing for permission asks you first (DOR-1694, DOR-1637)
While your list of agents is still loading, the edit screen no longer claims the task's agent is gone. If the list can't be read at all, it says that instead of blaming the task (DOR-1694)
Manually running a scheduled task now updates its "last run" and "next run" times right away, instead of leaving them stale (DOR-1492)
Copy one of a Shape's scheduled tasks to use as a starting point and it is yours to keep. DorkOS now remembers exactly which files it wrote when you applied a Shape, so removing that Shape removes only those, and re-applying it never writes over your copy (DOR-1524)
When an empty folder sits where one of a Shape's scheduled tasks would go, DorkOS says so on the apply screen and names the folder, instead of quietly skipping the task on every attempt (DOR-1524)
A Shape-installed schedule can no longer start with every approval prompt turned off instead of the normal, safer defaults (DOR-823)
Scheduled runs no longer fail with "No receiver for the scheduled run" when the agent-messaging connection they were handed to was switched off or failed to start. DorkOS now checks that something is really listening, and simply runs it itself when nothing is (DOR-1636)
Closed a hole where an agent running on Codex could switch your Shape on its own. Switching a Shape writes files into your skills folder, changes which Shape is active, adds, moves and removes scheduled tasks, and turns extensions on and off. Agents on Claude Code have had to ask you since 0.57.0; Codex agents were never asked, because a Codex session has no way to put a question in front of you. They now refuse and tell the agent to leave it to you (DOR-639)
Installing a marketplace package from a folder on your own computer now works when the folder name has a space in it (DOR-412)
Installed connector packages show the same cyan CONNECTOR badge Browse already shows for them, instead of the generic ADAPTER badge (DOR-710)
Installing or removing the same package in two places at once is safe. Before, a package could silently go back to an older version — one install failed, undid itself, and put the old files back on top of the other one that had just succeeded (DOR-711)
One package with a broken hooks file no longer stops every other package from reaching your coding tools. Syncing used to fail outright on it, so nothing got set up. DorkOS now skips only the parts it cannot read and sets up everything else — which also means the install screen and the sync agree about what a package will run (DOR-646)
When you approve an agent's request to install a marketplace package, that approval now covers the commands and scheduled jobs the card showed you, not just the package name. If the package changes between the moment you say yes and the moment it installs, DorkOS stops, tells you what it declares now, and asks again (DOR-647)
The dead-letter list can no longer be asked for an endpoint name that points outside the relay's own mailbox folder, where it would read and return files from elsewhere on your machine. And a Shape from the marketplace can no longer name an extension in a way that reaches outside your DorkOS data folder; extension names now have to look like extension names everywhere DorkOS turns one into a file
Alt+F4 no longer quits the whole app on Windows
Labels, headers, and sidebar rows on Windows no longer act like drag-selectable web page text. Text in messages, code, and diffs can still be selected and copied
Full-screen mode no longer leaves an empty strip at the top of the window
The window's header and tabs dim slightly when it loses focus, like other native Mac apps; scrolling to the end of the chat or a sidebar list no longer bounces past it on a trackpad; and toast and error messages can be selected and copied
A dorkos:// link opened during a slow first boot now still opens once the app is ready, instead of silently doing nothing
The desktop app never told its window what it was allowed to ask your computer for, and a window that says nothing is treated as saying yes — camera, microphone, location and reading your clipboard could all be handed over without a prompt you would ever see. Everything is now refused except the two things the app really does: show you a notification, and copy text you asked it to copy. Even those are refused to anything that is not DorkOS itself, like a website you have open in a canvas (DOR-560)
The page the app runs on now carries a rule about where its code may come from: your own machine, and nowhere else. Nothing an agent writes into a message, a widget or a marketplace card can pull a script off the internet and run it there. Everything you already use works exactly as before, including 3D and PDF previews, embedded web pages and copy buttons (DOR-560)
Creating your owner login now works from any address you have allowed the server to answer. Before, the server would load the whole app and then turn the sign-up away, which blocked Remote Access setup (DOR-1744)
Sign-in and sign-up errors say what went wrong in plain words. A refused address used to show only "Invalid origin"; you now get a sentence, the address to allow, and the original wording underneath (DOR-1744)
Remote Access now works in the Mac app. Turning it on always failed — the switch flicked straight back off, no matter which ngrok token you used — because the part of ngrok that does the real work was missing from the app we shipped. It now ships with the app, and the Windows build is wired the same way (#1458)
Remote Access comes back when you restart the desktop app. Turning it on saved the setting, but only the command line ever read that setting back, so the desktop app started with the tunnel closed and nothing said why (DOR-1738)
DorkOS now notices when a tunnel drops. It was asking ngrok to tell it using a name ngrok does not answer to, so a dead tunnel was still shown as connected until you turned it off by hand. A tunnel that is briefly re-establishing itself now reads as on and says "Reconnecting" — with your address still there — instead of showing as switched off, and turning Remote Access off yourself is silent rather than raising a red warning (DOR-1738, DOR-1739)
A username and password you set for the tunnel in your environment is now actually used when you turn Remote Access on from the app. Before, the app started an open tunnel and then told you it was password-protected — the one direction that mistake must never point (DOR-1738)
Your saved tunnel address no longer reads as empty after a restart (DOR-1738)
When a tunnel fails to start or stop, the reason is written to the log. Someone who turned logging all the way up to find out why still saw nothing at all (#1458, DOR-1738)
Stopping a remote-access tunnel now always works, even if login is turned off on this instance (DOR-574)
Turning on Remote Access no longer looks like it did nothing. When the tunnel failed to start, the reason flashed on screen for an instant and vanished, taking the "Try again" button with it, and the switch snapped back off. The failure now stays on screen until you dismiss it, and "Try again" actually tries again (DOR-1739)
Saving your ngrok token no longer always says "Could not save token. Try again." no matter what happened; DorkOS tells you the real reason and what to do about it. A custom domain that fails to save now says so instead of sitting in the box as though it had been saved, and clicking into that box and back out again no longer erases a domain you had already saved (DOR-1739)
A tunnel that takes more than 15 seconds to start is no longer reported as timed out and then connected a few seconds later. A failure no longer sticks around for the rest of the session — closing Remote Access and reopening it, or saving a new token, clears it — and opening DorkOS while remote access is already on no longer announces "Remote access is on" as though it had just been turned on (DOR-1739)
The connected tunnel's speed check no longer keeps firing at an unreachable address with nothing to stop it, piling up requests for as long as the window stays open (DOR-1739)
The Remote Access setup note said to create your owner login first; it is the token first, and the login when you switch remote access on. The note now matches (DOR-1739)
Long file paths in Settings read the right way round again. The Server and Advanced screens shorten a path from the front, so you keep the folder name at the end — and they no longer move the leading slash to the far right, drawing /Users/kai/.dork as Users/kai/.dork/ (DOR-1686)
"Reset to defaults" on the Appearance tab now puts back the theme and text and nothing else. It used to quietly flip every switch on the Preferences tab and forget your sidebar, canvas, and panel layouts too. The clean slate lives in Settings → Advanced → Danger Zone as "Reset All Settings", and it asks first (DOR-923)
If you'd limited which kinds of files can be uploaded, resetting your settings no longer quietly allows every kind again (DOR-1505)
Saving a Slack per-channel override with a mistyped setting name now shows an error naming the problem, instead of silently saving an empty rule (DOR-655)
An API key no longer stops working after ten uses in a day. With Require login turned on, the dorkos command sends your key on every request, so the eleventh command of the day came back "unauthorized", as if the key had been revoked. Keys you already created start working again with no action from you (DOR-489)
The Name field lines up with its Add button when adding a Claude account on a narrow screen
On narrow screens, small buttons like "Try again" and "Create agent" are easier to tap — 44px tall, the minimum size Apple and Google both recommend (DOR-771)
Sidebar rows, channels and sections read correctly to a screen reader again. Making them draggable had wrapped each one in a second, invisible button, and a button inside a button is something screen readers skip or garble (DOR-1418)
Server log files now record what actually went wrong. When something failed, the saved line kept only the headline ("Failed to load workspaces") and threw away the reason, so the log often could not explain the failure it was written for. Every line now carries the error's message, its stack, and the chain of underlying causes (DOR-802)
Server logs also record it when an OpenCode agent's unanswered permission request times out, matching what already happens for Claude Code (DOR-803)
Fixed a rare first-start problem where two DorkOS processes opening the same brand-new data folder at once each made their own secret key and one was thrown away — leaving whatever it had locked up (saved connection credentials, signed-in sessions, browsers signed up for notifications) impossible to open. The first process to finish writing the key now wins. If a secret file in your data folder is empty, which only happens when a much older version was interrupted on its very first start, DorkOS stops with a message naming the file instead of quietly replacing it; move the file aside or delete it to have a new one made (DOR-712)
Awkward text can no longer stall the server. A handful of text patterns got dramatically slower as the text got longer, and a few were reachable from outside: a scheduled task's time limit, a crash report's stack trace, and a chat message carrying a wall of half-finished tags could each tie the server up long enough to stop answering anyone
Fixed a leak where the access token for a connected tool server showed up on the command line of the Codex program DorkOS starts, which meant any other program on your computer could read it. The token now travels out of sight, and your agents reach those servers exactly as before (DOR-993)
Release blog posts no longer show the install instructions twice near the bottom of the page (DOR-649)
A marketplace package page no longer shows the package's name as a heading twice — once as the page title, once again at the top of its README (DOR-725)
Text on the dark sections of the story page was nearly invisible: a dark gray meant for cream backgrounds, painted on near-black. It now uses the same light color the rest of those sections use (DOR-1512)
The "API Reference" link in the docs, from the rooms page and the integrations guide, no longer leads to a page-not-found error (DOR-611)
Session, scheduled-task, and subtask rows now light up when you hover or tab to them, so it's clear what you're about to click (DOR-1752)
The Activity feed now tells you when it can't reach the server, with a way to retry, instead of quietly showing "no activity" (DOR-1752)
The Team page now shows a placeholder shaped like your roster while it loads, instead of a bare spinner that pops into a full grid (DOR-1752)
The Team page's filters and search no longer jump down after your roster finishes loading — they now stay put while the roster fills in underneath them (DOR-1752)
On Connections, the built-in Claude Code card no longer has a dashed border, which used to make it look unavailable even while it was live and working (DOR-1752)
A conversation's scrollbar now lights up as soon as you move toward it, instead of only while you're actively scrolling (DOR-1752)

Security

Extensions that forward requests to an outside service (a "data proxy", like one that talks to GitHub for you) were also handing that service your DorkOS login — the cookie or key that proves the request came from you. It never needed to go: the extension already carries its own credential for the service it talks to. Your login now stops at DorkOS
Those proxies got three more limits. They can only reach the address the extension declared, so a crafted request can no longer walk up to a neighbouring part of that service with the extension's key attached. If the service answers with a redirect, DorkOS hands it back to whoever asked instead of following it with the key. And there is now a ceiling of 120 requests a minute, so nothing can quietly burn through your quota
DORKOS_CORS_ORIGIN="*" no longer opens the whole API to every website. Logging in is off by default, so a wildcard meant any page you happened to visit could read your sessions and files and start turns of its own. DorkOS now ignores the *, says so at startup, and tells you to list the exact addresses you want to allow. Listing real addresses works exactly as before
Every response now says it must not be second-guessed about what kind of file it is, instead of only the handful of routes that said it themselves
Sending data through an extension's proxy could also fail for a reason nobody could see: DorkOS passed along the size of the original request while sending a slightly different one, so the outside service either rejected it or waited forever for bytes that never came. DorkOS now states the size of what it actually sends
Closed a hole where an uninstall could reach outside the marketplace's own folders. A package name is checked before DorkOS turns it into a folder on your disk, so a name dressed up as a path — ../../something-else — is refused instead of pointing the uninstall's delete at a folder that was never a package. The same check guards the install cache
Installing a package from a folder on your own disk now has to stay inside the folder DorkOS is allowed to reach, the same limit every other file feature respects. Previewing a package is held to the same limit, so a preview can no longer be used to ask what is in a folder elsewhere on the machine
The marketplace_install and marketplace_uninstall tools an agent can call now check the project folder you point them at, which the web app has always done and the tools did not
Your agents can no longer publish your machine to the internet. Opening a tunnel is one of the settings reserved for a person, but the button's own endpoint asked nobody, so anything on your machine that could reach DorkOS could open one. Closing a tunnel is still open to everything, on purpose — shutting off access should never be the thing that gets refused (DOR-1738)
If you have Require login turned on, turning Remote Access on now takes a person signed in to DorkOS. A script holding one of your API keys is refused, because a key proves the account and not the person. This is a deliberate narrowing: a script of your own that used to turn the tunnel on will be turned down, and you turn it on from the app instead (DOR-1738)
Saving any setting sent your stored secrets back over the wire: the reply carried your ngrok token, your tunnel sign-in, your MCP key and your cloud token in plain text, even when the setting you changed had nothing to do with them. Replies like that get written to logs and browser caches, and they travel the public internet when you use DorkOS from your phone. Saving now replies with a summary that says whether a key is set without saying what it is (DOR-1740)