Skip to main content

Workbench app — in-VM desktop UI

The workbench is the only window the user sees inside the Sandbox VM. It's a Wails v2 (Go + Preact) app that mirrors the design of the host-side Kenaz product surface. It runs as a systemd service inside the VM, started automatically after greetd autologs in.

🚧 This page is a stub. Flesh out as the workbench app matures.

Source​

  • Repo: sigil-tech/kenaz-sandbox
  • Subdirectory: workbench-app/
  • Stack: Go (backend, Wails bindings) + Preact (frontend) + Tailwind (styling)

Responsibilities​

  • Render the user-facing UI for a Kenaz session.
  • Talk to the host-side Kenaz Harness over a vsock socket. The protocol is documented in docs/vsock-protocol.md (kenaz-sandbox repo).
  • Execute user-approved actions inside the VM (run a command, open a file, invoke a tool) under the constraint that everything still goes through the harness audit log.

Responsibilities the workbench does not have​

  • 🚫 Inference is not performed by the workbench. The harness brokers all inference (Bedrock today; pluggable per-org for enterprise). The workbench sends "render this prompt" / "this tool was invoked" events; the harness handles policy + provider routing.
  • 🚫 Persistent storage is not the workbench's responsibility. Anything that needs to outlive the session goes through the harness's audit-logged storage layer.

Local development​

📝 TODO: document the wails-dev-loop with the in-VM service, plus the host-side mock of the harness for offline UI work.

Tool app IDs​

The workbench identifies tools (browser, terminal, code editor, etc.) by a stable app ID. The catalog lives in docs/tool-app-ids.md in the kenaz-sandbox repo. Add a new tool there before wiring it in the workbench UI.