v0.9.0

Upload a local harness to a hosted workspace

Build a harness here, send it to a HarnessRouter cloud workspace. One way: this instance is the source of truth and the hosted copy is a deployment target, so an upload replaces it and nothing is pulled back. The harness keeps its id, so re-uploading updates the same cloud copy rather than piling up duplicates, and links and API callers on the cloud side keep working.

Store as many workspaces as you hold keys for and pick one per upload: Upload to Cloud on a harness, or tick rows on the Harnesses list for a batch. Keys are stored encrypted on your instance and never reach the browser; a revoked one says so instead of failing quietly.

What travels: instructions, model, limits, disabled tools, MCP servers, and skills with their files. What never travels: provider keys, tasks, produced files. Nothing uploads on its own and nothing reminds you to.

Claude Code plugins

Contributed by @aug2uag. A harness can carry Claude Code plugins: commands, hooks, subagents, and a plugin's own MCP server over stdio. They are materialized per turn and passed to the CLI with --plugin-dir, with the executable bit preserved on bin/* and hooks/*.sh. The runner also emits stdio MCP servers now, not only http and sse.

Skills reach each agent through its own loader

Codex reads them from CODEX_HOME/skills and Hermes from HERMES_HOME/skills, beside the paths Claude Code and Pi already used. Before this both got a directory of our own invention plus a paragraph describing it, and a weaker model would read a skill's SKILL.md and then run its script against the workspace root instead of the skill's folder. A skill also keeps the name its author gave it: test-skill is no longer materialized as test_skill.

Also

• Share links work on a self-hosted instance: the page and its data are public, as a shared task is meant to be, and revoking one takes effect at once.
• UHP conformance: full class, 52 of 52.

Images: harnessrouter/harnessrouter:0.9.0 (amd64, arm64); latest points here.