Release v0.1.0

Wysebee Desktop v0.1.0

First public release.

Wysebee Desktop turns your machine into a set of nodes — named bundles of tools —
and hands them to your own Claude or ChatGPT over an MCP server or a plain HTTP API.
It hosts no LLM and runs no agentic loop: your model decides what to call, this app
answers.

There is no sign-in, nothing dials out, and everything durable stays in two places you
control: a SQLite file in your per-user data directory and each workspace's folder.

---

Install

macOS 12 or later, Apple Silicon or Intel.

1. Download Wysebee-0.1.0.dmg from the Assets below.
2. Open it and drag Wysebee into your Applications folder.
3. Launch it from Applications.

That is the whole install. The app is signed with a Developer ID certificate and
notarized by Apple, so it opens normally — no Gatekeeper warning and no
right-click-Open dance. Nothing else needs to be installed first, there is no account
to create, and the app dials nothing out.

First launch is immediate. There is no image to pull and no server to wait for: the
database is a file created under your user data directory the first time you open the
app.

Docker Desktop is optional, and only sometimes. The app runs, serves nodes and
answers your Claude or ChatGPT without it. Docker becomes necessary the moment a node
needs to run a shell command — which means the moment you create a workspace under
Workspaces and connect it to a node. If you get that far without Docker installed,
install Docker Desktop; once a
workspace exists, Wysebee starts Docker for you in the background at launch and never
asks for your password.

Uninstalling is dragging the app to the Trash. Your data lives outside the app —
Settings → Desktop shows the database path, and workspaces are folders under
~/Wysebee/workspaces — so removing the app leaves both, and deleting those two
locations removes everything Wysebee ever wrote.

---

What's in it

Nodes, and the two ways to reach one

A node is a named bundle of tools with an entry_points list. Adding mcp_server
serves it at /node/{node}/mcp; adding node_api serves
POST /node/{node}/tools/{tool}/call (plus /call/stream for SSE, /tools to
discover and /ping). Neither means the node isn't served at all. New nodes turn MCP
on by default — point any local MCP client at the address on the node's Access tab
and its tools show up.

Tool types

Five templates, one picker group:

• JSON Response — a fixed or templated JSON answer.
• HTTP Request — call any HTTP API, with a stored credential in the header.
• Toolset — connect to an external MCP server as a client and re-expose the
  subset of its tools you pick. One config, N tools; the schemas are snapshotted at
  configure time, so listing needs no network and only a real call opens a connection.
• Bash Command — run a command inside the node's workspace container.
• Local Command — run a fixed executable on the host, where only the arguments come
  from the caller. Admin-only, argv-never-a-shell, allow-listed environment, with a
  background mode for things not meant to finish.

Plus two tool packs defined in code, with no rows to seed and nothing to configure:
bash / read_file / write_file when a node has a workspace, and load_skill when
it has at least one skill.

Skills

Give a node a skill — a SKILL.md of instructions the model loads on demand
through load_skill. Four templates ship with the app to start from: skill-creator,
summarize, diagram-maker and weather.

Workspaces

A workspace is a Docker container plus a folder, and it's a resource nodes reference
rather than something a node owns. Pick a base when you create one:

• Bare-bones — a plain Debian shell
• Python + Jupyter
• PostgreSQL and MySQL — a real server, port bound to 127.0.0.1, password
  generated into a credential, data in a named volume that survives a delete unless you
  ask otherwise
• Custom Dockerfile — your own

Every non-bare base is a Dockerfile you can read and edit. The build context is empty by
construction, so no application source is ever baked into your image. Workspaces carry
their own environment variables, each a plain value or a reference to an encrypted
credential; one container per workspace, cap_drop=ALL, no-new-privileges, and
nothing inherited from the gateway's environment. A command timeout ends the command,
not the container.

Publishing

Two ways to reach a node from outside this machine, both machine-wide switches in
Settings → Network:

• ngrok — records a domain and starts the tunnel for you.
• Your own proxy — nginx, Caddy, a Cloudflare tunnel, a port forward. Record the
  domain; the app runs nothing and trusts you about where you answer.

Both can be on at once (they terminate at the same port), and a display preference picks
which address a node's Access tab prints.

Sign-in for a published node

The Claude app speaks OAuth 2.1 or nothing, so a published node gets a real
authorization server: RFC 8414 metadata, RFC 9728 protected-resource metadata, RFC 7591
dynamic client registration, authorization code + refresh token. There is no
password — a person types a username and you click Allow in Settings → Users. An
unknown username is indistinguishable from a known one, so the page can't be used to
enumerate who has access.

Node-level access is a per-node Authorization tool that validates the caller's own
JWT. A published node with nothing gating it says so, in red, on its Access tab.

---

Security posture

• The gateway binds exactly one port, and only node surfaces answer on it. The admin
  API binds no socket at all — the SPA reaches it through a Qt WebChannel bridge into
  the same FastAPI app in-process. So no other program on the machine can reach your
  config API, and a tunnel aimed at the port has nothing to reach but nodes.
• The SPA is served off disk through a custom wysebee:// scheme, not over HTTP.
• No sign-in and no identity provider. The gateway runs as the machine's owner.
• Credentials are encrypted at rest and decrypted only at the moment of use — never
  logged, never returned, never placed on an LLM-visible surface.
• The macOS build is hardened-runtime, Developer ID signed and notarized. It is
  deliberately not sandboxed and not on the App Store: docker exec, ngrok, Local
  Command tools and a loopback socket are all things the App Sandbox forbids.

---

Known limitations

• Back up before you upgrade. This release has no database upgrade step. Settings →
  Desktop shows the database path — copy that file to take a backup.
• Publishing is all-or-nothing. A tunnel forwards a port and every node answers on
  one, so there is no per-node publish switch — by design, not as a simplification.
• ngrok allows one agent per machine. Starting a tunnel here may end one you have up
  for something else.
• macOS only in this release. Windows and Linux builds are not available yet.