Run AI agents on your machines,
from anywhere.

What is Mycolab?

A control plane for AI agents. Your laptop or server runs a small connector daemon; Mycolab registers it on Hypha Mesh as a machine you can reach from any browser. From there you start agent sessions, drive them, and collaborate — while the code, files, and processes stay on your own hardware.

Everything in one workspace

The pieces compose: an agent can serve a report, expose a dev server, file an issue, and kick off a workflow — all from the same session.

How it works

Mycolab is built on a deliberately small contract — client→server unary calls and server→client streams — anchored by one Durable Object per workspace.

• The mesh. Each workspace is a single Cloudflare Durable Object that owns auth, service discovery, authoritative presence, RPC routing, and ordered event streams.
• The connector. A small daemon on your machine holds one hibernation-safe WebSocket to your workspace, registers its services, and answers calls routed to it.
• Sessions. Each agent session syncs its metadata (a Doc) and its chat/output (a Log) over the mesh, so any client gets a consistent, replayable view — and cheap re-subscribe after reconnect.
• Security. Passwordless email-code or passkey login; every call carries a workspace-scoped, server-attested identity; machines are private to your workspace by default.

Two things you can connect

Mycolab runs on hardware you already own. Attaching it is the only setup there is, and there are exactly two kinds of thing to attach — a computer, and a browser. Both join the same workspace, and every session in it can reach both.

Connect your browser

A browser joins the mesh as a node, the same way a machine does — it is an extension you install once and approve from a page. Nothing is scraped or proxied through us: the agent drives the browser you are already signed into, on your own computer.

Setup lives on the mesh, because the browser node belongs to the platform rather than to Mycolab — but Mycolab is what you will use it from.

Installation ~2 min

On a Mac, and never used a terminal? Download Mycolab for macOS, drag it to Applications and open it. It puts a small icon in your menu bar with a status, a start/stop button and the log — no commands to type. One download, both Apple Silicon and Intel. The app contains the same myco command as below, and can install it for you from its own window.

First launch may say the app is from an unidentified developer — right-click the app and choose Open once, and macOS will remember it.

Everyone else: the Mycolab connector is a single self-contained binary (no Node, no npm) — download it for your platform from the mesh's public mirror, then sign in and start the daemon.

# 1 · install the myco connector — the installer picks the right binary (overwrite-guarded)
curl -fsSL https://hypha.run/install.sh | sh

#   …or download a single binary directly:
#   macOS (Apple Silicon)
curl -fsSL https://hypha.run/download/myco-aarch64-apple-darwin.tar.gz | tar xz && sudo mv myco /usr/local/bin/
#   macOS (Intel)
curl -fsSL https://hypha.run/download/myco-x86_64-apple-darwin.tar.gz | tar xz && sudo mv myco /usr/local/bin/
#   Linux (x86_64)
curl -fsSL https://hypha.run/download/myco-x86_64-unknown-linux-musl.tar.gz | tar xz && sudo mv myco /usr/local/bin/
#   Linux (ARM64)
curl -fsSL https://hypha.run/download/myco-aarch64-unknown-linux-musl.tar.gz | tar xz && sudo mv myco /usr/local/bin/

# 2 · sign in to Hypha Mesh (opens a browser; passkey or email code)
myco login

# 3 · start the background daemon — registers this machine on the mesh
myco daemon start

# check it's connected
myco daemon status

Prebuilt macOS & Linux binaries publish with each connector release at the same https://hypha.run/download/myco-<target>.tar.gz URL (aarch64-apple-darwin, x86_64-apple-darwin, x86_64-unknown-linux-musl, aarch64-unknown-linux-musl), alongside Mycolab.dmg. There is no Windows build — the connector is unix-only today.

That's it — open mycolab.hypha.run/start in any browser, sign in with the same account, and your machine appears online, ready to run sessions.

Setup & first session

Tutorial: from zero to a shared app

Prefer the terminal? The same things work from the CLI.

# spawn an agent in a project and give it a task (runs autonomously)
myco session spawn claude -d ./my-app --message "create a hello-world Vite app and start the dev server"

# list your sessions
myco session list

# share a folder of static output as a managed link
myco serve my-report ./my-app/dist

# expose a running dev server to a public https URL
myco service expose my-app --port 5173

# track work as an issue (self-triages: title, labels, verify)
myco issue add "add unit tests for the cart module"

# automate: run a check every morning
myco workflow add nightly --on schedule --cron "0 9 * * *" \
  --run "myco session query ./my-app 'run the test suite and summarize failures'"

Command reference

Run myco --help, or <command> --help, for the full surface. Everything listed here is in the shipped binary — there are no preview flags.

Your sessions, and what happens to them

A session is not a terminal window that dies when you close the tab. It is a durable object in your workspace, and knowing what survives what is most of knowing how to use Mycolab.

• History is durable and server-side. Every message is appended to an ordered log with a gap-free sequence number. Reload the page, switch device, or come back next week — you get the same conversation, and re-subscribing after a disconnect resumes from where you were rather than refetching everything.
• The daemon restarting does not lose sessions. On start, the connector reads your workspace and re-adopts every session belonging to that machine. A session that was mid-turn when the daemon died comes back idle rather than stuck pretending to think.
• Continuing is genuine continuation. Send a message to an idle session and the agent is re-spawned against its original conversation, in its original directory — it remembers what you were doing, rather than starting over with a transcript it cannot see.
• Offline is visible, not silent. A session is shown as working only when its machine is actually reachable and the session says it is running. Close your laptop and sessions on it go offline honestly; the history stays readable from anywhere.
• You can take it with you. myco session export writes a session to a directory of plain files — a metadata document and one JSON object per message. Nothing about reading your own history requires us to be running.

Good to know

The things worth knowing before you rely on something, stated plainly rather than discovered later.

• An agent session is not sandboxed. It runs as a normal process, as your user, with your files and your tools — that is the point of running it on your own machine, and it is also the risk. Treat starting a session on a machine as equivalent to handing someone a shell on it, and share machines accordingly.
• A link is a capability. By default a served mount gets an unguessable hostname and anyone holding the URL can read it — including anyone it is forwarded to. That is the right trade for a build report and the wrong one for anything confidential; use --owner or --access for those. The hostname is not secret from DNS resolvers or TLS SNI.
• Exposed services are single-port. One service, one port. There are no service groups and no health checks on this plane; a supervised process has keep-alive and a restart policy, not a readiness probe.
• Scheduled work is timed by the machine. A workflow cron is matched against the host's local clock, so a machine that is asleep at the scheduled minute does not run it then.
• Agents cost money. Sessions run real models against your own account. A loop left running is a loop that keeps spending — myco session list is the cheapest habit in the product.