This release is about looking at the same thing. A room now has its own canvas and its own browser, so you and every agent in it see the same document, diff, or web page — live, and still there after a reload. Agents can use those pages, not just read them. And DorkOS will now tell you, plainly, which of your coding tools can see each of your skills.

Highlights

A shared canvas and browser in every room

Documents, diffs, and web pages belong to the room now, not to one browser tab. Everyone sees the same thing at the same time, you can pin what matters, follow a teammate's browser, and review and merge an agent's work without leaving the room.

Your agents can use the page, not just look at it

Ask an agent to try your signup form and it clicks, types, scrolls, and reads the page back to you. It can record what it did as a short slideshow you can watch afterwards.

See what each of your coding tools can see

The Skills page lists every skill your agent has, with a tag per tool saying who reads it, who has an out-of-date copy, and who cannot see it at all. Where one is stranded, a button moves it somewhere they all read — and dorkos harness sync says the same sentences in your terminal.

All Changes

Added

Send account events to an agent, room, Slack channel, or Telegram chat after choosing the exact account and event. Agents can also ask for the service access they need, while the owner keeps the final choice of account, actions, and notifications.
dorkos harness sync now lists everything else in your .claude/ folder, not just the parts it already knew how to copy. Rules in subfolders, subagents in subfolders, and whole folders you have linked in from elsewhere are all counted, and a subagent is listed under the name you invoke it by rather than its file path. Your rules, your subagents, your MCP servers, the hooks you keep to yourself in .claude/settings.local.json, and any hooks a skill declares in its own front matter each get a line saying they stay in Claude Code — and, for every other agent you run, where that agent would keep the same thing. Before this, a project with 13 rules, 7 subagents and an .mcp.json was told about none of them, which reads exactly like a project that has none (DOR-1845)
Your subagents already work in Cursor, and your skills in .claude/skills already work in Cursor, OpenCode and Copilot — the report now says so instead of calling them dropped. All four read those folders themselves, so nothing is written for them. That includes the skills you marked Claude-Code-only: marking one says what you meant, not what OpenCode reads, and OpenCode reads that folder
When a skill in .claude/skills has a name an agent would not accept — capitals, an underscore, or a name inside the file that does not match its folder — the report no longer says it works there. It says which rule the name breaks and that the agent's own docs do not say what happens next, so you can rename it or leave it knowingly (DOR-1845)
dorkos harness sync now looks at which coding agents your project uses every time you run it. Start using Cursor next month and it tells you Cursor is not turned on yet, instead of quietly leaving it out (DOR-1851).
dorkos harness sync --fix --enable cursor turns an agent on and sets it up in one command. It is the only thing that writes to your .agents/harness.manifest.json, and all it does is add the name to the list — your own formatting and key order stay exactly as you left them (DOR-1851).
Some of what DorkOS writes belongs to your computer rather than your project: links into installed packages, and the hooks files it rebuilds on every sync. If your .gitignore does not cover them, dorkos harness sync now prints the exact lines to add, and --fix --write-gitignore adds them for you. It only ever appends, under a comment saying where the lines came from (DOR-1851).
If you keep .agents/ out of git, dorkos harness sync explains what that means: your skills stay on this computer, while the links DorkOS writes into .claude/skills still get committed — so anyone who clones your project gets links pointing at files they do not have (DOR-1851).
A skill your agent writes while it works now shows up in your other coding tools within a few seconds, instead of waiting for you to run a command or restart DorkOS. Most tools read the skills folder directly and see it the moment the file lands; Claude Code reads a different folder, so DorkOS puts a link there for you (DOR-1850)
DorkOS now tells you when a Claude Code session you already have open needs a restart to see new skills, and only when that is actually true — Claude Code watches the skills folder, but only if the folder was there when the session started (DOR-1850)
dorkos harness sync now names the plugins you turned on in Claude Code, which your other agents cannot see. Each one comes with the repository it came from and the command that installs it here, named by your project's full path, so every agent on the project gets it. Nothing is installed for you, and the report says which settings file it read (DOR-1921)
The same report says how many commands your personal Claude Code settings run on their own, and that only Claude Code runs them. If part of that file is written in a way DorkOS cannot read, it says which part rather than guessing at a number (DOR-1921)
Tell you when the same package is installed twice, once for all your projects and once in this project. The line says what Claude Code and Codex each do with the pair, and how to remove either copy (DOR-1922)
Your agent's Skills page can now fix what it finds. When some of your agent files are out of date, a line at the top says so and offers a Sync now button that writes them, and the page updates to what the sync actually did rather than to a guess. Syncing sometimes also removes files — a link to a skill you deleted, the copies a package left behind when you uninstalled it — and the page names every one of those files, with a plain sentence saying why each is going, before you click, then lists them again afterwards so they do not vanish into a toast that fades. One line in that list is not a deletion at all: your own .claude/settings.local.json keeps every setting you wrote and loses only the entries DorkOS added, and it says so. If a package wants to run commands automatically, syncing does not wait for you to decide — the files that do not run code are shared straight away, an approval card goes up for the ones that do, and the page tells you a package is waiting. Only you can press the button: an agent asking on your behalf is turned down (DOR-1895)
Point a DorkOS agent at a project and DorkOS sets that folder up straight away, instead of waiting for you to run anything — whether you named the folder yourself or added one you already work in. It only adds files: it never deletes anything and never asks you to approve anything on that pass. A brand-new agent's own folder is still set up by the step that builds it, exactly as before (DOR-1901)
A skill that runs on a timer inside a package you installed for all your projects now actually runs. dorkos harness sync --global puts those skills where DorkOS looks for timed work, so a daily job in a package you installed once shows up for you to approve like any other. It works from any folder and needs no project (DOR-1923)
Before it removes a link, --global prints every path it is about to remove — each with one plain sentence saying why — and prints them again once they are gone. It only ever removes links it made itself: a folder you made, or a link you made yourself, is left exactly where it is. Run it twice and the second run does nothing (DOR-1923)
The Skills page now lists the skills in your all-projects packages alongside your project's own, tagged "for all your projects", with the same sentence about who can see them — and the count above the list counts both (DOR-1923)
Skills that only live in another agent tool's folder now show up. .opencode/skills, .cursor/skills, .gemini/skills, .github/skills and .codex/skills are read alongside your own, so a project whose skills live in one of them sees them on the Skills page and in dorkos harness sync instead of an empty list. Each one says which tools read it where it is, which do not, and says to move it somewhere every tool can read — it is a sentence, not a button, and nothing is moved for you (DOR-1902)
An MCP server list in another tool's config file is named as something DorkOS does not carry. If your servers are declared in opencode.json, .codex/config.toml or .cursor/mcp.json, you now get one line saying how many are in there and that DorkOS only passes on the ones in .mcp.json. It counts them and reads nothing else, so nothing from those files — no server name, no key — is ever printed or stored. Every ordinary way of writing that list is counted the same, including the shorthand forms, and a file your editor saved with a byte-order mark is read rather than called broken (DOR-1902)
A package you installed for all your projects can now be shared with your other agent tools. Run dorkos harness sync --global and DorkOS asks once: it shows the two folders in your home directory it would use, names every link it would add, and writes nothing until you answer. Say yes with dorkos harness global --enable <tool>, once per tool you want (DOR-1924)
dorkos harness global --list shows what you chose and where the links go. --disable <tool> stops sharing with one tool and removes the links that tool's folder no longer needs first. Five tools share one folder, so turning one off while another still reads it removes nothing (DOR-1924)
DorkOS only ever creates links in those two folders, never files, and it only ever removes a link it made itself. Your own skills, and shortcuts you made yourself with the same shape, are left exactly where they are. If you uninstall a package later, DorkOS removes its links too (DOR-1924)
The line about a package you installed for all your projects now says it is shared once you have shared it, and tells you which command shares it until then (DOR-1924)
A skill your agent wrote inside one tool's folder can now be moved to where every agent reads it, with one command: dorkos harness adopt <name>. It moves the folder to .agents/skills in one step — either the whole skill arrives or nothing happens — and, if your project uses Claude Code, leaves a link at .claude/skills so Claude Code still finds it. Add --check to see what it would do without writing anything, or --claude-only to say the skill belongs to Claude Code and should stay put (DOR-1944)
DorkOS tells you when it will not move a skill, and why. A skill whose settings only Claude Code understands, one whose text points at a Claude Code path, a name already taken in .agents/skills, a folder that is really a link somewhere else — each gets one plain sentence naming the thing in the way and what to do about it, and nothing on disk is touched (DOR-1944)
Every dorkos harness sync now names the skills that live where only some of your agents look, one line per folder, with the command that moves each. It says which of your tools cannot see them — worked out from what each tool documents about itself, not from a list DorkOS wrote down — and stays quiet when every tool you use can already read them (DOR-1944)
The Skills page can now move a skill for you. A skill sitting in one tool's own folder — where the rest of your agents cannot see it — gets a Share with every agent button. Pressing it asks first, naming the folder it moves from, the folder it moves to, and the link it leaves behind so Claude Code still finds it. Say yes and the row redraws on the spot: the tools that could not see the skill now say they read it. The command that does the same thing from a terminal is still printed right beside the button (DOR-1946)
If DorkOS will not move a skill — its settings are Claude Code's own, something already sits in the way, the folder is really a link somewhere else — the row says so in one plain sentence, in the place the advice was, and nothing on disk is touched. Screen readers are told the sentence as it arrives (DOR-1946)
DorkOS can now move a plainly-portable skill into the shared folder every agent reads, on its own — but only inside the agent folders and room folders DorkOS made, only when you turn it on with dorkos config set harness.autoAdopt true, and only for a skill whose settings hold nothing one tool alone understands. Everything else is reported, with the one sentence saying why, and left exactly where it is (DOR-1945)
Every server start writes a line into the DorkOS log for each agent folder holding a skill only some of your coding tools can see. It names the skills, says which tools cannot see them, and gives you the command that moves each one — with your agent folder's full path in it, so it means the same thing wherever you paste it. You get that line whether or not you turned the setting on, because knowing is the point (DOR-1945)
dorkos harness adopt now knows when you are standing in a room's own folder, and refuses to move a skill whose name matches one DorkOS puts in every room folder — that folder gets cleaned up, and the skill would go with it. It tells you to rename yours and adopt it under the new name. The same skill in one of your own projects still moves (DOR-1945)
If you turn the setting on and then run dorkos harness sync in one of your own projects, it tells you in one line that the setting does nothing there and that dorkos harness adopt <name> is how you move a skill yourself. Nothing in your own repositories is ever moved for you (DOR-1945)
Attach a screenshot when you send feedback — paste one, drag it onto the dialog, or pick a photo on your phone. The picture is shrunk before it goes so your report stays small, and if it is still too big to send you are told, rather than the picture quietly going missing. You see exactly what you are attaching, and one click removes it (DOR-1955)
Browse Composio’s full service catalog in Connections and use its built-in sign-in where supported. Existing custom setups keep priority. Services that need an API key or account details open a secure hosted form; unsupported methods explain what is missing. Connecting an account still grants no agent access until you choose it (DOR-1958).
Capture the app in one click when you send feedback. The feedback dialog gets out of the way, takes the picture, and attaches it — so a bug report shows what you were looking at without you having to take a screenshot yourself. It captures only the app, never the rest of your screen. In the desktop app the picture comes from the window itself, so it is exactly what you see (DOR-1956)
Point at the part that looks wrong. In the feedback dialog, "Point at element" gets the dialog out of the way and hands you a crosshair: the app dims, whatever you hover lights up, and one click sends a report cropped to just that piece — with the name we use for it in the code, so we know exactly which one you meant. Press Esc, right-click, or Cancel to back out; anything you had already typed is still there. It needs a mouse and a bit of room, so you will see it in a full-size window on a computer, not on a phone or a narrow one (DOR-911)
You can now change what kind of work you do any time, in Settings › Profile. When DorkBot asks the question, it tells you where the answer is kept and links you straight there.
If you run Claude Code with more than one account, you can now see which one a chat is using without leaving it. Hover the runtime chip above the message box, or open the session details panel on the right.
See the widgets your agents post in a channel or a direct message. A widget an agent writes into a room message now renders as the real card, table, or chart it describes, instead of a block of raw code. Buttons that open a link, or change something small and visible in DorkOS like a panel or the theme, work the same as they do in a session. Buttons that would send a note back to the agent — or open a page, file, or terminal in your workbench — are shown but switched off, with a note when you hover them: a room message has no session behind it to answer into, and it can come from an agent you don't run or be relayed in from a Telegram or Slack room by someone you've never met. If a widget is broken, you get a short "this widget couldn't be rendered" card with the reason and the raw text, the same as in chat, and the rest of the message reads normally (DOR-1997)
A Browser tab in the workbench, next to Canvas. Web pages open there — a local file you are building, a dev server you are running, or a site your agent wants you to see — while files, documents and diffs stay in Canvas.
Each of the two tabs keeps its own set of open documents and remembers the one you were reading. Switch to Browser and back, and the file you had open is still the one on screen.
Agents in a room can now put documents and pages on a shared canvas — a file, a change to a file, a web page, a note — and everybody in the room sees the same one. It survives a reload, because the room owns it rather than one browser tab.
Agents can read the canvas too, so one can look at what another put up without you relaying it. Every agent in the room is told what is on the canvas at the start of its next turn.
Putting something on the canvas interrupts nobody. The room's log gets one quiet line per turn saying what changed, and that is all — if an agent wants you to look now, it says so in a message.
A new setting, rooms.maxCanvasOpsPerTurn (3 by default), caps how much of the canvas one agent may rearrange in a single turn.
Rooms now have a Canvas and a Browser tab, and what is on them belongs to the room rather than to your browser. When an agent puts a document there, everyone in the room sees it — at the same moment, without reloading — and it is still there tomorrow. Each tab says who put it there (DOR-2000)
You can put things on the table too: type an address in the Browser tab, pick a starting point in an empty one, or press "Put on the canvas" on a file in the Room tab's Files section. Pin the ones that matter so they stay at the front, and close the ones that do not — for everybody
Markdown the room owns can be edited right there, and your save reaches everyone. While you are typing, an agent's change to that same document is held rather than dropped on top of you; every other document stays live
A document that arrives while you are looking somewhere else lights a small dot on the tab it landed on. Nothing ever moves the tab you are on, and a brief drop in your connection never takes away what you were typing
When the room turns something down — it has been archived, or the document is already gone — it says so where you pressed, and nothing you wrote is thrown away on the way: a save the room would not take leaves your words in the editor, and an address it would not take stays in the box
Pin a document on a room's canvas to keep it at the front. Hover its tab and press the pin. A room holds twelve documents and drops the one nobody has touched for longest, but a pinned one is never dropped — and a pin sticks, so reloading the page or opening the room on your phone finds it still first. Anyone in the room can pin and unpin.
See who is looking at what. A small face sits on the tab somebody is reading. An agent's face shows up while its turn is really reading that document and goes when the turn ends, so it tells you what the agent is working from — it is never something an agent decides to show you. None of it is saved: close the window and your face goes with it.
A room that has files of its own now starts with ROOM.md pinned to its canvas. Those are the notes everyone in the room shares, so they get a tab that nothing can push off.
#team starts with a board on its canvas — a short checklist of what to do next, which any agent in the room can rewrite as things change. It is an ordinary pinned document, so you can make one in any room; close it and it stays closed.
Your agent can now use the page in the Browser tab, not just look at it. Ask it to try the signup form and it will: it reads the page to see what is on it, clicks buttons, fills in fields, presses keys, scrolls, and waits for the page to catch up — then tells you what happened, in the tab you are watching. It never pastes the page's HTML at you, and when several things match what it was looking for it says so and asks which one instead of guessing (DOR-2007).
Every one of those answers names the page it acted on and where that page is now, so an agent with three previews open can tell you which one it used.
Your agent can record what it does in the Browser tab. Ask it to show you rather than tell you, and it films the steps: one frame per action, saved as a small animated picture in its own working directory. You get back where the file is, how many frames it kept, and how long it covers — and the agent gets the last frame as a picture, so it can reason about where the page ended up. Open the file and watch the form fail for yourself (DOR-2008).
An agent can put a file it made into a room. A screenshot or a recording goes on the message like a file you sent yourself: everyone in the room can open it, and every other agent there finds its own copy of it on its next turn. It beats a paragraph describing what a page looked like.
Follow somebody's browser in a room. Pick a person on the Browser tab and your panel goes where theirs goes — the same page, the same place on it — until you turn it off. It's people only, it's off until you ask for it, nothing about it is recorded, and it stops on its own when you look away or the person you're following goes quiet. A room where nobody is following anybody sends nothing extra at all. (DOR-2010)
Talk about one document on a room's canvas. Press Discuss on any tab and a thread opens on it, with a short line in the room saying you started one. Press it again next week and you land in the same conversation, and so does everybody else — there is one discussion per document. Asking an agent something in it tells the agent about that document and no other. (DOR-2010)
Review an agent's work from the room's canvas and merge it there. When an agent puts a review of one of the room's files up, and its copy is ahead of the room, you see that file the way the agent has it beside the way the room has it. Turn down the parts you don't want — they go back in the agent's copy — then press Merge into the room. The room gets one line saying what landed, and nobody is interrupted.
Merging stays yours, and so is the review itself: reading and changing somebody else's working copy is something a person does, and an agent asking is turned down. Only you see the merge button, so no agent can sign off its own work. If the room has moved on since the agent last caught up, the button is replaced by the reason and a note to ask that agent to catch up.
An agent can put something on a room's canvas from a one-on-one chat with you. Ask for a chart and say which room it belongs in, and it lands on that room's table for everyone. It has to be a member of the room, it can do it three times per room per turn, and one line saying what it put there posts when the turn ends.
Your Codex and OpenCode agents can now use the canvas and the browser the same way your Claude Code agents always have. They can put a document up, open a file or a diff beside your chat, point the Browser tab at a page, read its console and its network log, take a screenshot, use the page — click, type, scroll, wait for something — and record what they did. Turn on DorkOS tools in every runtime in Settings under Experiments, and their next turn has all of it. Until now a Codex agent in a room could not see a console error while the Claude Code agent beside it could (DOR-2009).
Before starting a long job in a room, an agent now puts 👀 on your message, then swaps it for ✅ when the job is done. So you can tell "seen and working" from "did not notice". Quick replies skip the signal, so rooms stay quiet.

Changed

Pending raw MCP connection checks now survive a DorkOS restart.
Some packages ship hooks: commands your coding agent runs on its own. dorkos harness sync --fix used to install every one of them, even from a package you had turned down. Now it holds those back, sets up everything else, and prints each command it did not install, so you can see what it skipped and why (DOR-1849).
Say dorkos harness sync --fix --allow-hooks <package> to install that package's hooks. DorkOS remembers your answer, so you only say it once. dorkos harness hooks --list shows every package you have decided about, and dorkos harness hooks --revoke <package> forgets one so you get asked again (DOR-1849).
When you turn a package down, DorkOS now remembers that too. It used to forget on the next restart (DOR-1849).
If DorkOS cannot read your settings file, it says what is wrong with it and holds every package's hooks back, instead of telling you that nothing has been decided. It will not write over a file it cannot read (DOR-1849).
Connections now stay available while Claude Code, Codex, or OpenCode keeps the same long-running turn active. Ending the turn closes access. If supervision stops unexpectedly, that access still expires within four hours.
Your project's .agents/harness.manifest.json can say what to do with your hooks for each agent, and DorkOS now does what it says. none means that agent's hooks file is not written, and the report says so instead of quietly writing it anyway; generate is what DorkOS has always done; say nothing about an agent and nothing changes for it. If DorkOS had already written that file, dorkos harness sync --fix clears it away — and never touches one you wrote yourself. For Claude Code, which reads your hooks straight out of .claude/settings.json whatever your manifest says, none means one thing: hooks that came with an installed package stop being added for it.
Allowing a package's hooks no longer records an answer that quietly comes true later. dorkos harness sync --fix --allow-hooks <package> stops and explains itself when nothing in your project can take those hooks — whether that is because you told DorkOS not to write them, or because none of the agents you use has anywhere to put them. Saying yes was being saved either way, and would have installed them the day you changed that, without asking. When only some of your agents are covered it saves your answer and tells you which ones miss out.
Four keys in that same file are no longer read by anything: skillWrappers, commandMappings, instructionProjections and skillBundles. Your file still works if it has them, and dorkos harness sync names each one so you can delete it. A manifest DorkOS writes for you from now on has only the three keys that do something.
Your agent's Skills page now shows every skill it has and which of your coding tools can see each one, with a reason when one can't. It used to list only the skill packs you had installed from the marketplace, which is how an agent with thirty-one skills came to be told it had none. Each skill is one line with a small tag per tool — reads it, has a copy, out of date, can't see it, or needs you to decide something — and where a tool can't see one, the page gives you the same sentence dorkos harness sync prints in your terminal, word for word, so the two can never tell you different things about the same file. Under the list there is a panel per tool holding every agent file that tool cannot see — skills, rules, commands and more, so that count is usually bigger than the number of skills — and a line when DorkOS finds files for a tool in your folder that it is not sharing to, with the one command that turns it on. Reading this page never writes anything (DOR-1894)
Harness Sync now says what a package you installed for all your projects actually holds — its skills by name — and that only the Claude Code sessions DorkOS runs can see it. The old line told you to "run a global sync", a command that has never existed (DOR-1922)
Say so when one of those packages has a hooks file DorkOS cannot read, instead of reading it and saying nothing (DOR-1922)
dorkos harness sync now says why each file it removes is going, on the line for that file, in both --check and --fix. It used to print the paths under one heading — "what they came from is gone" — which was true of most of them and not all: a skill link, an uninstalled package's command, a hooks file nothing writes to any more and a settings file that survives are four different things, and now each says which it is. The app shows the same sentences, word for word (DOR-1895, DOR-1906)
The line about a package installed for all your projects now ends with "Its skills that run on a timer now work" once those skills are actually linked, and tells you which command links them until then. Packages with no timed skill say nothing new (DOR-1923)
If DorkOS cannot read the folder your all-projects packages live in, --global stops and removes nothing instead of treating the folder as empty. A package that is still installed also keeps its links when DorkOS cannot make sense of its settings file (DOR-1923)
The advice on a skill that only some of your agents can see now names the folder it is really in, instead of always saying .claude/skills (DOR-1902)
If you told DorkOS to stay inside one folder on this machine, it does not put links in your home directory. It says so, names the folder you set, and your timed skills keep running (DOR-1924)
Saying no is remembered. DorkOS asks the question once, and a no means it does not ask again (DOR-1924)
If one of those folders is a file, or DorkOS may not write in it, the run says which folder and what to do about it. It used to stop with an error nobody can read, after it had already recorded your answer (DOR-1924)
The Skills page prints the command that moves a skill, right under the line saying where it lives. It carries your project's full path, so it means the same thing wherever you paste it (DOR-1944)
Bug reports now say which page you were on more precisely — not just /session but which conversation. The address is filtered first: the folder you are working in and anything you typed to an agent are stripped out before it is sent, and you can read the exact address in the preview before you send (DOR-1960)
Bug reports can also carry your window size, browser, and light/dark setting, so a layout problem can be reproduced without us asking what you were looking at. These ride under the same Diagnostics switch as before — turn it off and none of them are sent — and the preview lists every one (DOR-1960)
Codex agents now run on Codex 0.154.0, which carries upstream fixes for connected tool servers and for picking up skill and plugin changes in a session that is already open. Context readings refresh themselves within a few minutes of the update. If you never picked a model for an agent, Codex now chooses your account's default, which may not be the model it picked before.
An OpenCode subagent whose last tool call failed now shows as failed. It used to hand back whatever the subagent had written up to that point and read as finished.
The context meter counts every part of the conversation the runtime reports, so the number matches what the model actually sees
A session's cost now tells you how sure it is. If DorkOS has no published price for the model that ran, the figure says it is an estimate instead of standing there like a fact. A cost charged at your company's own rates says that too. You will see it in the cost tooltip and in the /context panel.
If you export traces of your agent runs, each turn now also reports how many of its output tokens the model spent thinking.
DorkOS now knows exactly which of your messages a reply answered, so nothing is left hanging when you send several at once. Claude Code reports the whole list instead of just the last one, and DorkOS reads it — a reply that covers two messages closes both, and a message it already answered can no longer be mistaken for one it still owes you.
A message you send mid-reply is less likely to get a silent answer. When Claude Code says it still has one of your messages waiting, DorkOS now waits longer for that answer before it ends the turn. It never cuts the wait short, so an answer that was already on its way still reaches you.
If Claude takes a long time thinking about something you sent mid-reply, that answer now reaches you. DorkOS used to give up waiting after five seconds and the whole answer went nowhere.
When Claude ends a turn nobody asked for — it re-ran one that was cut short, or it ran a slash command on its own — the log now says which, instead of reporting it as a surprise.
When an agent opens a page for you, DorkOS brings up the Browser tab instead of the Canvas tab, so a page it sends never takes over the file you were reading.
A page that is open but cannot be driven now says so in one sentence, straight away — including a preview you navigated away from, to a page DorkOS is not serving. A page loaded straight from the internet is shown, not driven — and until now asking an agent to look at one meant an eight-second pause followed by a note about opening a preview that was already open.
With the same conversation open in two windows, only one of them acts: the one that most recently brought a preview to the front. The other sees nothing, and a window you close hands the page back right away, and a window that stops responding hands it back after about a minute and a half. Screenshots follow the same rule, which settles a long-standing surprise where whichever window answered first won.
Background chores your agent runs for itself no longer crowd the task bar. They show in the expanded panel, and any that fail still show up like other failures.
In auto mode, Claude Code is told which DorkOS safety tier a tool call already passed, so it asks you less often about things that were already decided. It can still ask whenever it wants to. Set DORKOS_CLASSIFIER_CONTEXT=0 to turn it off.
A task running on its timer no longer waits ten minutes for an approval nobody can give. It moves on without that tool right away, and the run tells you what it skipped. Only runs the clock starts skip the asking — press Run now and you are watching, so that run keeps its approval cards and you can answer them.
A finished run leads with the tools it could not use, and each one gets its own line in your activity feed. Nothing pings your phone about it.
Installing a plugin while agents are busy no longer makes them re-read their whole conversation right away. An expensive reload waits, and DorkOS keeps checking back until the agent says switching the plugin on is free — or gives up waiting after fifteen minutes and switches it on anyway.
A reload you ask for by hand still happens straight away, whatever it costs. Reloads that cost something now show up in your Activity feed, with how big the conversation was and whether the wait paid off.
Your canvas now lives on your DorkOS machine instead of in one browser. Open a file on your laptop and it's already open when you pick the session up on your phone; close it there and it closes on the laptop. Clearing your browser data no longer costs you your tabs, and two windows on the same session show the same set instead of drifting apart. Anything you had open is carried over the first time you open that session (DOR-2006).
Your agent can now name which canvas tab it means. Asking it to change or close "the chart" used to act on whichever tab was at the front, so it could only ever work on the one you were looking at; it can now pass the id of any document on the canvas. Leave the id out and it still acts on the front tab, exactly as before (DOR-2006).
Your agent can see what's on your canvas, and read it. Ask "what have we got open?" and it gets the real list — every tab, what it is, what it's called, which one is at the front, and how many windows are watching — instead of guessing from whatever your window last mentioned. It can read one of those documents back too, like the chart it drew for you last turn, and a document backed by a file is read off disk so you get what the file holds now (DOR-2006).
Codex sessions now say what the permission setting lets Codex do, in plain words. The default setting lets Codex read files but not change them, and Codex has no way to ask you to approve one, so asking for a change used to get a confusing "I can't do that" with nothing on screen to answer. A Codex session that starts in that setting now says so once, above the chat box, with a link to the picker. The three Codex settings read the same way wherever they appear (DOR-2019)

Fixed

Keep security audit records when you delete an account or an admin changes one (DOR-1874)
dorkos harness sync --check no longer crashes on a broken link. If a file DorkOS writes for an agent — .codex/hooks.json, or the .claude/CLAUDE.md pointer — had been replaced by a link to something that is no longer there, the check stopped with a stack trace instead of telling you what was wrong. A broken link is now just one more thing to fix: the check names it, and --fix puts the real file back. Anything else that goes wrong is reported as one line, and you can ask for the details with LOG_LEVEL=debug (DOR-1843)
A skill you removed or renamed no longer leaves a dead link behind. Deleting .agents/skills/my-skill used to leave .claude/skills/my-skill pointing at nothing, which Claude Code cannot follow — and the check called it clean. The next sync now names those links and clears them away. Links you made yourself, real folders you put there, and links that still work are all left alone (DOR-1843)
DorkOS will not write over a folder, or through a link, where one of its own files belongs. A folder sitting where .codex/hooks.json goes used to be reported as something a sync would repair, and the sync then stopped with an error; a link pointing outside your project could have the file at the far end quietly rewritten. Both are now reported as blocked, with a line saying exactly what to move (DOR-1843)
If you use Cursor, Gemini CLI or GitHub Copilot, dorkos harness sync no longer tells you your skills were left behind. All three read the shared .agents/skills folder, so they had your skills the whole time — the report was wrong, not your setup (DOR-1847)
A package you install now puts its skills in that shared folder no matter which agents you have turned on. Before, only turning Codex on put them there, so a project running just OpenCode or just Cursor got none of them (DOR-1847)
More of your Claude Code hooks travel to the other agents. Codex now gets the "session ended" hook, and Copilot gets five more — including compaction, permission requests and notifications — instead of being told they do not exist (DOR-1847)
dorkos harness sync no longer claims an agent is reading a file you do not have. With no AGENTS.md, no hooks and no commands folder, it says so plainly rather than listing them as working (DOR-1847)
Skills you deliberately keep for Claude Code only now show up in the report as kept, with a line per agent that does not get them. They used to be missing from it entirely (DOR-1847)
When a command cannot travel to an agent, the reason now names that agent's own command folder — .cursor/commands, .gemini/commands, .github/prompts — instead of saying it has none (DOR-1847)
A project with no slash commands and no hooks is no longer told, five times over, that its commands were left behind. If you never wrote one, dorkos harness sync says nothing about them (DOR-1847)
A skill you keep only for Claude Code is now looked for where your settings file says it is, instead of only in the usual folder — so a skill that is really there is no longer reported as a leftover entry (DOR-1847)
If you list a skill as Claude-Code-only when it is really in the shared folder, you are told the first time you check, on a fresh copy of the project — not only after a sync has already run (DOR-1847)
Room work folders stay clean when the room's project has a package installed. The links DorkOS makes for it no longer show up as your unsaved changes, which used to stop the folder being tidied up or merged (DOR-1880)
A SKILL.md whose front matter will not parse is now reported the same way every time, by every part of DorkOS that reads one. It used to be called broken the first time it was opened in a session and something else entirely after that, so which answer you got depended on which reader looked first — the marketplace preview, a scheduled task, the skills list, or the harness report (DOR-1845)
dorkos harness sync now explains a checkout that cannot make symlinks. On Windows, and in any clone where symlinks are turned off, git writes each skill link out as a plain file — and the report used to call that "drift" and tell you to run --fix, which then refused it without saying why. It now says in one line that symlinks are off in this checkout, and gives you both ways out (DOR-1855).
Every blocked skill link now says what is in the way, not just that something is. When the name on disk differs only in case — a Foo where the plan wants foo, on a Mac or Windows filesystem that does not tell the two apart — the message names the difference, instead of leaving you looking at a folder you believe is called something else (DOR-1855).
On Windows, the file paths DorkOS writes into a plugin's hooks and command wrappers are now spelled one consistent way instead of half one way and half the other, which is easier to read and safer for the shell that runs them. Because that changes the exact command text, DorkOS will ask you once more about plugin hooks you have already approved on Windows; approve them again and it settles (DOR-1855).
dorkos harness sync no longer hangs if a named pipe is sitting where a skill link belongs. It now says a file is in the way, like it does for anything else it did not put there (DOR-1855).
Projects can now be added when their own folder is the scan root. If adding a project fails, it stays in the list with a clear retry action (DOR-1897).
The files DorkOS writes for your coding agents now land in one step. If an agent reads one while a sync is running, it sees the whole old version or the whole new one — never an empty or half-written file (DOR-1854)
Two syncs into the same project no longer trip over each other. Installing two packages at once could leave one of them waiting on a half-finished picture of your project, or fail outright with an error there was nothing you could do about (DOR-1854)
The X that closes a dialog is back in its top-right corner. In Settings and the other dialogs with a sidebar it had slipped to the bottom-left, below the tab list, and in the plainer dialogs it sat too low and pushed the heading down with it.
Show your API keys after you create them, so you can recognize and revoke each key.
Scheduled tasks now start in the right folder when you run DorkOS from source. They were starting one folder too deep, so a task with no workspace of its own could not see the project it was meant to work on.
Set up Gmail notifications when the service supplies suggested values and examples. Review or edit the suggestions before approving; examples are never selected for you. Keep blank filters unchanged when saving (DOR-1899).
dorkos harness sync --check now lists every file a --fix would remove, not just the broken skill links. Uninstall a package and the check names the links, slash commands, hooks files and settings entries it left behind — before you run the command that deletes them (DOR-1889)
A project is no longer called clean when a sync would delete files in it. Removing a package used to leave the check saying "no drift" while the next sync quietly took nine files out of the project (DOR-1889)
dorkos harness sync no longer stops with a system error when something unexpected sits where a commands folder should be — a stray file at .opencode/commands, or a folder your account cannot read. It tells you about the rest of the project instead (DOR-1889)
dorkos harness sync now lists files it could not read — a .mcp.json with a typo in it, a rule file whose header will not parse, a stale entry in your manifest — under a heading that says this project, instead of blaming whichever agent tool happened to be named first. A project that only runs Codex used to be told Claude Code had a problem, narrowing the report to one tool hid the warning completely, and turning on a plugin was never involved even though the old heading said "plugin layers".
Refreshing the page no longer opens on "DorkOS can't reach its server" for a few seconds when the server is running fine. DorkOS was remembering an old connection hiccup and treating it as proof the server was down right now. It only says the server is unreachable when this visit's own attempt fails.
Your API keys stay listed in Settings → Access after you turn "Require login" back off. Turning login off never revoked those keys — they kept working for MCP clients and scripts — but the list disappeared, so there was no way to see them or revoke one.
Opening DorkOS no longer shows remote access as on, or offers a link and QR code for it, when the tunnel stopped since you were last here. DorkOS was reading what your browser remembered about remote access as if the server had just said it.
No more "Remote access turned off" alert on a visit where nobody turned anything off. That message now only appears when remote access actually drops while you are looking.
DorkOS now refreshes itself when its live connection comes back. After a dropped connection (a sleeping laptop, a restarted server, a moment of bad wifi), rooms, sessions and agents could keep showing what they showed before the drop until something else happened to refresh them. The catch-up that was meant to run on reconnect never did.
Signing back in now clears the "your sign-in stopped working" banner. Before, the banner only went away once something happened to run on the exact account that broke — so if you signed in, sent a test message, and it ran on a different Claude account, the warning stayed up and survived a page reload. Signing in to a different account still leaves the warning up, because that credential really is still broken.
Agents you talk to in a room now start at the power level you picked. If you set your power to Full autonomy, an agent you @-mention in a room used to ignore it and stop to ask permission instead. That is the one place nobody is watching, so the agent just waited. Now the room reads the same setting your other chats do, from the agent's very first reply. Rooms were the last place this setting did not reach: chats and scheduled tasks already followed it. If you have not set a power level, nothing changes. A room conversation that is already going keeps the settings it started with. And a message from someone in a linked Telegram or Slack chat still starts an agent at the careful setting, so a stranger cannot start one at full power (DOR-1917)
Keep newly received chat tasks visible when an older history request finishes. Clear the list when a newer history response confirms it is empty.
A scheduled skill you add to a new folder is picked up within seconds instead of up to five minutes. If the folder DorkOS reads schedules from did not exist yet — a fresh project, or an agent you just added — the first schedule you put there could sit unnoticed for as long as DorkOS kept running, and only a restart would find it. Now DorkOS starts reading the folder the moment it appears (DOR-1908)
Folder-watching can also go quiet in two other ways: a busy machine running several agents at once can use up the operating system's supply of folder watches, and a schedule saved in the first moment after DorkOS starts watching can slip past. In both cases DorkOS now checks the folder itself every ten seconds for as long as it needs to, so the schedule still starts on time. When everything is working normally, nothing changes (DOR-1908)
Codex now uses a current version and offers the models available to your signed-in account. New Codex agents start with the runtime you selected.
Rejected models explain what to change, with a button that opens the model menu. Informational warnings no longer appear as errors.
Codex and OpenCode agents can use their DorkOS tools while app login is enabled. Each turn keeps the permissions it started with.
Codex’s context gauge now shows the current conversation size and effective limit reported by Codex, instead of counting earlier requests again.
Collapsed tool results now show an arrow and an ellipsis, so a result with hidden contents no longer looks empty.
The Skills row in an agent's profile no longer says "Skills 0" about an agent with thirty-one of them. It says how many there really are once you have opened the Skills page, and says nothing at all before that. Counting them means reading your project folder, and doing that every time a profile opens would slow every chat down for a number you had not asked to see (DOR-1894)
Approval cards now name the thing they would act on. Asking to remove an agent used to show only its id — a line like agentId: "01KXQ3P7ADJY9DSXMZW1XGWCV4" — so four requests in a row looked identical and there was no way to tell which agent was which. The card now leads with the agent's name, keeps the id underneath so you can still check it, and does the same for a scheduled task it would delete. If DorkOS can't look the name up, the card shows the id exactly as before.
A request DorkOS can't put a name to now says where it came from — "Asked from a session on this computer", or "Asked by an app connected to DorkOS" — instead of the old "Requested without an agent identity", which sounded like the request came from nowhere.
When you approve or refuse an agent's request to remove an agent or delete a scheduled task, the agent now finds out on its own and carries straight on. Before, those two requests ended the agent's turn: you would approve the card, nothing would happen, and you had to go back to the agent and tell it yourself. Every other kind of request already worked this way; these two were the stragglers. If nobody answers within ten minutes, the agent falls back to the old behaviour and the card stays on your screen, so nothing is lost either way.
Turn on the agent DorkOS itself runs your sessions on, even when your project shows no sign of it. A project that has only ever used OpenCode or Codex has nothing of Claude Code's for DorkOS to find, so DorkOS used to leave it off — and the session it then started had never read the AGENTS.md you keep in that folder. Now it is turned on, DorkOS says so in one plain line, and the one file it writes is a .claude/CLAUDE.md pointing at your own AGENTS.md (DOR-1901)
Say so when a project was set up before that, and does not list the agent DorkOS runs. dorkos harness sync and the app both name it and give you the one command that turns it on. Your manifest is still never rewritten behind your back (DOR-1901)
One line on your agent's Skills page had gone stale. Some packages bring along a part that connects DorkOS to Slack or Telegram, and the line explaining why that part stays inside DorkOS instead of travelling out to your coding tools still used an old name for it. It says Messaging now, which is what it is called everywhere else. DorkOS also checks its own wording from here on: a test reads every sentence the file-sharing engine can print — why a tool cannot see a file, what is in the way of writing one, what a sync would delete, what is out of date in the file that lists which tools you share to — and fails if one of them slips back into a word the product has stopped using, so the next stale line gets caught before you ever see it. The page itself is now opened and clicked through in a real browser on every run, against a real folder on disk (DOR-1896)
If a plain file sits where DorkOS needs a folder — a commands file where your agent tool keeps a commands folder, say, or a folder nobody has permission to read or write in — syncing your agent files no longer stops partway through with an error. It sets up everything the folder is not in the way of, leaves the folder exactly as you left it, and lists the one thing it could not do with a line naming the folder and how to clear it. Checking first says the same thing, so you are never told to run a fix that was going to refuse (DOR-1882)
If DorkOS cannot read the folder your skills live in, it now leaves every skill shortcut alone instead of treating the folder as empty and tidying them away. It says which folder it could not read and that it removed nothing, so a folder with the wrong permissions costs you a warning rather than your skills (DOR-1882)
Syncing no longer rewrites the command files DorkOS generates when nothing about them has changed. Only the ones that are actually different get written — the same now goes for the settings file DorkOS merges your packages' hooks into, which Claude Code re-reads every time it changes — so your editor and your agent tools stop being told a file changed when it did not, and a folder you have made read-only no longer turns a sync that had nothing to do into an error (DOR-1882)
When your agent asks to do something that cannot be undone, it waits about ten minutes for you to say yes or no. You get two hours to answer. Answer after that ten minutes and, until now, nobody told the agent — you had to open its chat and pass the message on yourself. Now DorkOS tells it for you. Your answer arrives in the agent's own chat as a note DorkOS wrote and signed, so it always reads as a decision you made in the approvals panel and never as something you just typed. A "no" reaches it just as quickly as a "yes", along with the reason you gave. If the agent is busy, the answer waits its turn instead of getting lost; if its chat has ended for good, DorkOS says so in the log rather than failing. You are only ever told once — an answer that reaches the agent while it is still waiting is not repeated afterwards — and restarting DorkOS mid-decision no longer swallows the answer. This works for agents you run in DorkOS chats today (DOR-1931)
On Windows, dorkos harness sync now makes real skill links whenever your account is allowed to — with Developer Mode on, or as an administrator. Before, it always made the one kind of link Windows allows without permission, and git commits a copy of every skill's files instead of the link, so a teammate who pulled got duplicated skills nobody meant to add (DOR-1883).
If your account cannot make real links, DorkOS says so once per sync — in the terminal and on the Skills page — before you commit anything: what is on disk, what git would do with it, and the two ways out. Nothing is treated as broken, because the links still work on your own machine.
Keep sign-ins separate when you run DorkOS with different data folders on different local ports. The default port keeps existing sessions. Other ports require one sign-in after this update. (DOR-1953)
Managed services now return when DorkOS can reach them again. A temporary outage during startup could hide them until you restarted or linked your account again.
Messaging now says when it is off or when its options could not be loaded. It no longer suggests choosing an unavailable option or says every kind is already in use when the list failed to load.
A bug report's attached server log now keeps the lines from just before the problem, instead of the oldest ones. On a busy machine the log was long enough to be trimmed, and it trimmed from the wrong end, dropping exactly the lines that explain what went wrong (DOR-1976).
The composer status line no longer shows your model's name twice. It now shows up once, right where you'd expect it.
Opening an agent's session from inside a channel now takes you to the conversation that agent is having in that channel, instead of an unrelated one.
You can type spaces again when you rename a session from the session list. The space key was being read as a click on the row instead of a character in the name.
Running out of disk space no longer shuts DorkOS down mid-conversation. It now keeps going, hands scheduled tasks to another DorkOS process if one is running, and writes a line in the log telling you the disk is full. It picks scheduling back up on its own once you free some space.
Find DorkOS account setup directly from Connections, and refresh available services after linking or unlinking your account.
Make Gmail send and draft actions available to review. Actions with uncertain effects require the stricter approval level.
Keep agent commands on the DorkOS version running your app. Unknown commands stop before opening settings, and agents prefer their built-in tools over an older installation on your computer.
Help agents find their granted accounts and notice access changes in existing conversations. Account guidance now matches Claude Code, Codex, and OpenCode.
Agents can discover services across the full Connections catalog and ask for the next page, instead of missing services when the catalog is large.
When this instance loses its DorkOS account link, service actions now explain that nothing was sent and point to Settings to reconnect. Actions with an uncertain remote result remain protected from automatic retries.
Reconnect disconnected accounts through a fresh sign-in. If disconnection still needs to finish, Accounts now explains the next step. Old agent permissions stay revoked (DOR-1993).
Keep disconnected accounts in their own section and let you remove them from Accounts after disconnection finishes. Past usage remains available (DOR-1994).
Stopping an OpenCode subagent now shows as stopped instead of failed. OpenCode changed the wording it sends when a subagent ends early, and DorkOS was reading the new wording as a crash.
If you reported a bug or asked for a feature and left your email, you now actually get the "your report shipped" email when we ship it. Before, that email only went out if the report carried a version number, and none of them ever did, so nobody got one. The email now links to the changelog so you can see what changed.
Claude Code sessions keep showing their task list and to-dos after the runtime update
You now get a clear message when your Claude account is on hold, needs verification, or its cloud credentials were refused, instead of a turn that just stops
Sessions with a lot of plugins installed start reliably
DorkOS replaces an outdated copy of the Claude Code command it downloaded for you, so sessions keep starting after an update
Lowering MCP_TOOL_TIMEOUT to cut off a slow outside tool server works again. DorkOS used to raise your value back up, because a short one would also cut off a tool call that was waiting on you to approve it. DorkOS now sets its own time limit on its own tools, so your setting is left alone and reaches the server you meant it for.
When an agent changes a document while you are editing it, the canvas now tells you and lets you pick. Your edit was always protected, but the agent's version used to be thrown away without either of you being told. You get a quiet notice with two buttons: Reload shows their version and ends your edit, and Keep mine throws theirs away. Your agent is still told the change went through — it has no way to know you were typing — so for now the notice is only on your side.
Agents now know about everything they can put on the canvas. What they were told listed 6 of the 14 kinds, so files, side-by-side changes, web pages, 3D models, sound, video and CSV tables were all things an agent could open and had never heard of. The command that applies a saved layout was missing too, and could not be run at all.
Lines the room writes about you — a merge, a change to the canvas, the one that opens a document's discussion — now show your name and your face. They used to be signed "Unknown", which read as if nobody wrote them. (DOR-2014)
Asking an agent for the console at a particular level, or for only the failed requests, works again. Both reads were quietly ignoring every filter you gave them and answering with the default instead (DOR-2009).
Your agent gets told when an approval times out. When an agent asks to do something that needs your sign-off and you never get to it, the request quietly stops being valid after two hours — but until now nothing said so. The agent was left waiting on an answer that could no longer come, and you had to go and tell it yourself. Now the request closes itself on time and the agent is told, in its own words: nobody answered, the request is dead, ask again if it still matters. You get no extra ping — it was not your action to be reminded about, and the request had already disappeared from your approvals list on its own.
A tool waiting for your approval no longer looks like it already ran. While Claude Code asked "can I write this file?", the file showed as written — the whole time you were deciding. Now it stays marked as in progress until it really finishes, and a tool you turn down is marked as refused instead of done.
The OpenCode model list no longer offers models OpenCode cannot run. A model you pulled with Ollama used to show up in the menu even when OpenCode knew nothing about it, so picking it was accepted and then the next message failed with "That model isn't available" — pointing you back at the menu that offered it. The menu now shows only models that will actually work.
"Run now" can ask you a question again. When you run a task by hand and the agent needs your go-ahead for something, the request now shows up where all your other requests do — the tray at the top, the Pulse panel, the home page — and you can answer it there. Say yes and the task carries on. Before this, the request went nowhere at all: nothing appeared, nobody could answer, and two minutes later the run gave up and blamed a schedule you had not used. A task the clock starts is unchanged — nobody is watching one of those, so it still gets on with what it can do without you and tells you afterwards what it had to skip.
Every task run now opens to its own conversation. Click a run in a task's history and you land in the session it actually had, instead of an error.
Stopping a task run also takes away the question it was waiting on. Before, the request sat in your list for hours pointing at a run that had already finished.
The composer says why a message did not send. When the server turns a message down for a reason — "Choose a registered agent before starting this session", say — you now read that sentence instead of "HTTP 400".
An agent that rewrote its own personality file could switch its personality off by accident. The top of that file is written by DorkOS from the six personality dials you set, and an agent saving the file without it left the dials showing your choice while none of it reached the agent again. DorkOS now keeps that part of the file whatever an agent sends.
Reloading the page while a tool is waiting for your approval no longer shows it as already done. The live view was fixed first; rebuilding the conversation from its saved history still showed a finished tool, so a refresh mid-decision put the old answer back on screen.
Extensions are no longer told a tool finished while you are still being asked whether to allow it.
Opening a message-search result now takes you to the conversation it came from, whichever agent ran it. Results from Codex and OpenCode carried the id those tools use internally, which DorkOS could not open, so pressing Enter on one led nowhere.
A result from a conversation you had at the command line, which DorkOS never ran, now says so instead of offering a link that opens an empty screen. The message is still found and still shown.
When part of DorkOS fails to load, the "Something went wrong" screen now always shows, with its Try again and Back to home buttons. Before, some unusual failures could crash that screen too, and you saw nothing useful (DOR-2032)
Desktop: a slow start no longer makes the app reload its window over and over, losing unsent messages and half-filled settings each time. The shell was reading the old page's late check-in as the new page coming up, so it kept retrying the same first step instead of trying the deeper fixes (#1840, DOR-2034)
The "DorkOS can't reach its server" screen now only appears when nothing answers at all. When a request for your settings comes back with an error instead, DorkOS says that and shows the status code it got, rather than telling you the server is down (DOR-2035, #1841)
When DorkOS will not answer to the address you reached it on, it now says so in words you can act on, instead of a bare error code (DOR-2035)

Security

Keep raw MCP server URLs out of shared configuration snapshots, where embedded credentials could be exposed.
Stop passing the full DorkOS server environment to coding agents and their setup commands. Standard model sign-ins and operating system settings remain available. Custom tools that need extra variables now require an owner-approved list of names. Restart DorkOS after updating that list (DOR-1904).

Note for people upgrading

DorkOS adds these links while you work and never removes them on its own, which is deliberate: it will not delete files in a folder you may be editing right now. So a skill you delete leaves a dead link behind. dorkos harness sync --check lists them and dorkos harness sync --fix clears them out (DOR-1850)
This only ever touches projects you have already set up for syncing, and only inside the folder your DORKOS_BOUNDARY allows. A project DorkOS has never synced is left completely alone (DOR-1850)
Showing a page needs a server to serve your files and reach your dev server, so the Browser tab is part of the web app and does not appear in the Obsidian plugin. Everything you had open is still open — pages just moved one tab along.
A recording is a slideshow of the steps, not a video of them — two frames a second, and at most sixty frames. Past sixty it stops filming and everything the agent is doing keeps working; the answer says so.
An agent can only attach a file from its own working directory. It cannot reach into another agent's copy of the work, and the size and count limits are the same ones your own uploads follow.
One thing an agent reaching in from outside the DorkOS app still cannot do: apply a Shape. It writes to your machine — files, settings and scheduled work — and there is no way to put that question to you from a Codex or OpenCode session, so it is refused with a sentence telling the agent to ask you to do it in the app. Your Claude Code agents still ask you the normal way.
Nothing changed about what your Claude Code agents can do, or what any of these tools are called. They are the same names, the same arguments and the same answers; there is just one copy of each now instead of one per runtime.