Marketplace

The DorkOS Marketplace is a curated catalog of pre-built agents, plugins, skill packs, and adapters. Install one with a single command and it runs locally, on your machine, under the same permission model as the rest of DorkOS.

What is the marketplace?

The default marketplace is named dorkos-community inside DorkOS. Its packages live in the dork-labs/marketplace repo on GitHub, and every one is reviewed before it is listed. A few examples:

• Agents that review your PRs
• Plugins that surface Linear issues in your sidebar
• Skill packs for security auditing or release automation
• Adapters that connect more messaging services to your agents
• Shapes that set up your whole workspace for a job in one click

Browse the full catalog at dorkos.ai/marketplace without installing anything.

Every entry in the registry is a real GitHub repository. You can read the source before you install it, fork it, or submit improvements upstream. Nothing is hosted, executed, or transformed by a third party: DorkOS fetches the package directly from its repo and validates its manifest (a small file describing what the package needs and what permissions it wants) against the same schemas as your local extensions.

Installing a package

You can install a package from the command line or from inside DorkOS.

dorkos marketplace install flow

dorkos marketplace installed                    # list what you have, and where
dorkos marketplace outdated                     # list only what has an update
dorkos marketplace update flow                  # check one package for an update
dorkos marketplace update --apply               # apply every available update
dorkos marketplace uninstall flow

Extensions that run separately

Some extensions ask to run on their own, apart from DorkOS. Before you let one run, its card lists exactly what it can reach:

• Runs separately from DorkOS. Its server part runs as its own program. If it crashes, freezes or runs out of memory, the rest of DorkOS keeps working.
• Can connect to: the sites it may reach. DorkOS refuses any other connection. An extension that lists none says "Can't connect to the internet."
• Can run: programs it may start on your computer. A program it starts can do anything you can do, so a shell or a language like Python can run any program. The card says so when that's the case.
• Can message your agents and start chats. Shown only when it asks for this.

If a later version asks for more, DorkOS asks you again before it runs. If it asks for less, it just updates.

What running separately does not cover:

• Its screens. The parts of an extension you see in DorkOS run with your access, like any extension's.
• The programs it may run. Each one has your full access, as above.
• A firewall. The list of sites is a check DorkOS puts inside the extension's own program. It is not a firewall on your computer.

If it stops on its own, DorkOS starts it again after a second, and waits longer each time it stops again. If it stops 3 times within 10 minutes, it stays off and its card says why. Click Reload on its card in Settings > Extensions to try again. If the card says it "can't run with its limits on this computer," DorkOS left it off rather than run it without them.

Running separately has been tested on macOS and Linux. In the desktop app, DorkOS has checked that the limits hold, but a whole extension hasn't been run there yet. It hasn't been confirmed on Windows yet.

An extension that runs separately can give your agents tools, just like one that runs inside DorkOS. Your permissions are checked inside DorkOS before a call reaches the extension. If the extension stops or freezes, its tools disappear until it is running again.

How large a package can be

DorkOS won't install a package larger than 250 MB in total, with more than 20,000 files and folders, or with any single file over 50 MB. It checks this before showing you what the package will do, so you never approve something it then refuses. Real packages are far smaller: the largest we've seen is about 12 MB.

If you install from a folder on your computer, DorkOS copies the folder as it is, including any node_modules folder inside it. A project with its libraries installed can pass these limits. The message says how much of it is in node_modules, so you can remove that folder or install from the package's repository instead.

Browsing in DorkOS

Marketplace is the in-product browse experience. It mirrors the public catalog but adds the install machinery, so you can go from "interesting package" to "running on my machine" without leaving the app.

The browse surface has three sections:

• Featured rail: a curated row of agents the maintainers have highlighted. Rotates monthly, so it's not the same three agents forever.
• Package grid: every package in every registered marketplace, ranked by featured weight and install count.
• Detail sheet: opens when you click a package. Shows the permission preview, install instructions, and related packages.

The install confirmation dialog always shows you exactly what the package wants to do (which files it will write, which network hosts it needs to reach, which permissions it will request) before any state changes. You can deny at any point and DorkOS leaves your installation untouched.

That includes commands written into a skill or command's text. A skill can ask Claude Code to run a shell command the moment it is used, before the agent reads it, so each of those commands is listed with the skill it comes from. A new version that adds or changes one asks you again.

Keeping packages up to date

The Installed tab of Marketplace lists every package you've installed, in every place it's installed. When you open Marketplace, DorkOS checks all of them for a newer version at once. The Installed tab shows how many have an update waiting, so you can see it from Browse too.

Each package says where it stands:

• Update available: v1.2.0 → v1.3.0. Its Update to v1.3.0 button installs the new version in the same place. If the new version runs commands or programs of its own, the button first shows you what they are and asks you to confirm.
• Up to date. There's nothing to install, so there's no Update button.
• Couldn't check for updates, and why. For example, "couldn't reach github.com" when you're offline, or "linked install — update its source instead" for a package linked to a folder on your computer. DorkOS never calls a package up to date when it couldn't check it.

While the check runs, each package says Checking for updates…. It can take a moment when many packages are installed.

Update all… opens a list of every package it will update, where each one is installed (all agents, or a named agent), and which version it moves to. Under each package it lists what the new version runs on its own: each command and when it runs, each server or program and whether it starts in every chat. What is new or changed since the version you have is marked and comes first; what is the same is folded under a count you can open. A line at the top says how many of the packages run things on their own and how many add something. Nothing changes until you confirm, and then only those packages are updated, exactly as listed. If a package changes what it runs after you opened the list, DorkOS updates nothing and asks you to review it again. If one fails, the others still update, and the failed one shows why. Check again runs the check again whenever you like.

A package whose files you or an agent changed since it was installed says how many, for example 3 files changed since install (2 edited, 1 added). Open it to see which ones, grouped as edited, added and removed. When an update is waiting, it also says what the update will do: it replaces files you edited and keeps your copies beside them, keeps files you added, and puts back files you removed. Update all… says the same for each package it affects.

A package installed by an older version of DorkOS says Installed by an older DorkOS, because that version didn't record which files were the package's. DorkOS checks them for you in the background after it starts: it compares the package with the exact version you installed, and records its files only when every file still matches. If that couldn't happen, for example because you were offline, press Check files to try again. It compares this package with the version you installed, so updates keep your edits. If the files differ, the package says so, with Try again for when you've put things back; its next update still keeps your copies either way. A package installed from a folder on your computer has no version to compare with, so reinstall it to start tracking its files.

If you update or remove such a package when DorkOS can't get the version you had, for example because you're offline, DorkOS can't tell which of its files are yours. It keeps every one it can't account for, never deletes them, and tells you which files they are. After an update, the package says Kept 2 files DorkOS couldn't sort after an update. Open it to see the files. Once you're online, press Check files. It sets aside the files that are exactly what the earlier version shipped, which the update would have replaced anyway, by renaming each to end in .dork-old so it no longer runs, and keeps the rest as yours. Nothing is deleted. Until you do, the package keeps listing those files, even through later updates. A package installed from a folder on your computer, or one whose earlier version DorkOS couldn't download when you pressed Check files, can't be sorted that way, so its note also offers Keep these as mine. DorkOS shows you the files, marks the ones that still run, and asks first; after that they're yours, updates keep them, and nothing is moved or deleted. Only you can do this, not an agent. If some of them sit where a package keeps what it runs, such as an old skill or command, the note says 2 of them still run and lists them apart, because they still work in your chats. A package installed for all projects that still runs such a file won't load until you approve it; its note names the files and points you to Check files. Keeping the files as yours also shows you everything that package runs, and approves what it discloses now, like a Review. After removing a package, the kept files are simply yours: delete any you don't need.

Managing installed packages

A package can be installed in more than one place: globally, and separately on individual agents. When you open the detail sheet for a package you've installed, the Installed panel lists every installation, one row per scope:

• All agents (global): installed globally, active everywhere.
• A specific agent, shown by name: installed only for that agent's chats. If the same package is also installed globally, the agent row is marked Overrides global, meaning that for that agent, the agent's copy takes precedence.

Each row manages its own installation independently:

• Reinstall re-runs the install for exactly that scope. The confirmation dialog opens already pointed at the same agent (or global), so you never reinstall into the wrong place.
• Uninstall removes just that installation. It asks for a quick confirm first, and the confirmation message names the scope ("Uninstalled flow from Release Bot") so it's clear which copy went away. Uninstalling one agent's copy never touches the global install or any other agent's.

To add the package to another scope (for example, you have it globally and want a pinned copy on one agent), use Install… at the bottom of the panel to open the dialog and pick the new target.

What updating, reinstalling and uninstalling keep

A package's folder can hold your own files as well as the package's: settings you filled in, notes, a folder an agent works in. DorkOS keeps track of which files the package itself put there, and only ever replaces or removes those.

• Updating or reinstalling keeps every file you or your agents added. The package's own files are swapped for the new version's.
• If you changed one of the package's own files, the new version replaces it and your copy is saved next to it with .dork-old on the end, for example SKILL.md.dork-old. Some packages mark a file as yours to edit, such as a settings file. For those, your copy stays, and if the package changed its default, the new default is saved next to it with .dork-new on the end. A saved copy never runs: DorkOS turns off its permission to run as a program. If an update has to set aside a whole folder, such as a skill folder of yours where the new version puts a file, or a program from the package's bin/ folder, it is saved in the package's .dork/saved/ folder, where nothing runs or loads it. The update tells you about each of these.
• Uninstalling keeps the files you and your agents added or changed and lists them. Installing the package again later picks them up. dorkos uninstall <name> --purge deletes them too.
• Uninstalling a marketplace agent also removes that agent from your team, as removing any agent does. Its rooms, schedules, sign-ins, access tokens, space memberships and connection access go with it. Its memory and persona files stay in its folder. Reinstalling the same package brings back the agent's identity, but not those things; you set them up again.

When a new plugin switches on in a chat that's already open

Installing a plugin doesn't interrupt anything. Chats that aren't open pick it up the next time you send a message. Chats that are already running usually pick it up right away, and you'll see the new commands without doing anything.

Sometimes a chat takes a few minutes longer, and there's a good reason for it.

An agent keeps a copy of your chat ready so it doesn't have to re-read the whole thing every time you speak. Adding a plugin can change the tools it has, and when that happens the copy is thrown away — so your next message makes it read the entire chat again. You pay for that reading, and you wait for it. On a long chat it's the most expensive moment of the day, and one install can trigger it in every chat you have open at once.

So DorkOS asks first, and keeps asking. If the chat is short, or switching the plugin on wouldn't disturb anything, it happens immediately. If it would be expensive, DorkOS waits and checks back every few minutes: the agent's ready copy expires on its own after a while, and once it has, switching the plugin on costs nothing at all. How long that takes isn't something DorkOS guesses at — it asks the agent each time, because the answer depends on how you're signed in. If the copy never expires, DorkOS stops waiting after fifteen minutes and switches the plugin on anyway, so nothing runs on yesterday's plugins for long.

Two things you can always do:

• Don't want to wait? Reload the plugins for that chat by hand. A reload you ask for happens straight away, whatever it costs.
• Want to know what happened? Every reload that cost something shows up in your Activity feed, with how big the chat was, whether it waited, and whether it ended up being free.

Sharing an all-projects package with your other agent tools

A package you install for all your projects starts out visible to one thing: the Claude Code chats DorkOS runs. Codex, Cursor, Gemini CLI, Copilot, OpenCode and the claude you type into a terminal yourself cannot see it.

You can change that. Run this in a terminal:

dorkos harness sync --global

The first time, DorkOS asks. It shows the two folders in your home directory it would put links in, names every link it would create, and stops. Nothing is written until you answer.

To say yes, run this once per tool you want:

dorkos harness global --enable codex
dorkos harness global --enable claude-code

DorkOS then puts a link to each skill where that tool looks. Five tools share one folder, ~/.agents/skills: Codex, OpenCode, Cursor, Gemini CLI and Copilot. Claude Code reads its own, ~/.claude/skills. Restart Claude Code after the first time, and in Gemini CLI run /skills reload.

Two commands manage it afterwards:

dorkos harness global --list              # what you chose, and where the links go
dorkos harness global --disable codex     # stop sharing with one tool

--disable removes the links that tool's folder no longer needs before it forgets the tool. If another tool still reads the same folder, nothing is removed, because the same links serve it.

Marketplace sources

The default registry is dorkos-community, but you can add your own. Personal marketplaces are useful for sharing internal packages across a team without publishing them to the public registry.

# Add a marketplace source
dorkos marketplace add https://github.com/my-team/marketplace --name my-team

# List configured sources
dorkos marketplace list

# Remove a source
dorkos marketplace remove my-team

Adding a source also fetches its listing, so you can install from it straight away. If DorkOS can't reach it right then, the source is still added: dorkos marketplace add tells you why the listing isn't there yet, and dorkos marketplace refresh my-team tries again. On the sources page in the app, the same reason shows on the source's row, with a Try again button beside it.

A refresh always checks the source again. If DorkOS can't reach it but has an earlier copy of its listing, it says so and tells you when that copy is from, rather than calling it refreshed.

DorkOS remembers how each source's last check went, whether it came from adding the source, a refresh or browsing. dorkos marketplace list shows how many packages each source has, or that they didn't load and why. The sources page in the app shows the same, even after you reload it or open it in another window.

A source's name can use letters, numbers, dots, dashes and underscores, and starts with a letter or number.

A source address is either an https:// link to a git repository, or a folder on this machine written as file:///path/to/folder. Nothing else works: DorkOS reads a marketplace's listing over the web, so SSH-style addresses like git@github.com:org/repo have no listing to read. Anything else is turned down when you add it, with a note saying so — which also keeps out the exotic addresses git accepts that run a command instead of fetching a repository.

You can also manage sources in DorkOS, at /marketplace/sources on your own DorkOS address. On the default port that is http://localhost:4242/marketplace/sources; if you changed the port, or the desktop app had to move off 4242, Settings → Advanced → Server shows the address to use. Sources are merged into a single browse surface: packages from your team's marketplace appear alongside community packages, with the source clearly labeled on each card.

Telemetry consent

DorkOS can report anonymous install events to dorkos.ai to power the public install counts and ranking on the marketplace browse page. This is opt-in: the channel is off by default, and DorkOS never reports anything until you turn it on in the Privacy & Data settings tab or with dorkos telemetry enable --channel install.

When telemetry is on, each successful install sends a single event containing:

• The package name and marketplace source
• The package type (agent, plugin, skill-pack, adapter)
• The outcome (success, failure, cancelled) and duration
• A random per-install UUID, not tied to you or your machine
• The DorkOS version, for compatibility analytics

No IP addresses, no user identifiers, no package contents, no file paths. Your address is used for one thing only: our server counts how many requests come from it in the last few minutes, so nobody can flood the endpoint. That count lives in memory for a few minutes and then it is gone. Your address is never saved, never written to a log, and never passed to anyone else. The full privacy contract, including what we store, who can access it, and how to opt out, is documented at dorkos.ai/marketplace/privacy.

To enable telemetry:

dorkos telemetry enable --channel install

Or toggle the Help improve the marketplace switch in the Marketplace settings panel.

Submitting a package

Anyone can submit a package. If you've built something useful (an agent that automates a workflow, a plugin that integrates a new service, a skill pack that codifies your team's conventions), you can submit it to the registry via a PR. See Publishing a package for the full walkthrough. The short version:

dorkos package init my-package --type agent

dorkos package validate

The repo's checks run on every pull request and test each manifest against DorkOS's own rules. A pull request that fails them can't merge, so make sure dorkos package validate passes on your machine first.

Next Steps