Skip to main content

Using the Workbench

Once you've opened a workspace, here's what working in it looks like.

:::note Preview The Workbench is still being finished. This describes the intended day-to-day experience; some surfaces below aren't wired into everyday use yet. :::

The control page​

The launcher's page (at http://127.0.0.1:8181) is your dashboard for the workspace itself. From here you:

  • Open a workspace — provisions the sandbox and brings it up.
  • Close a workspace — tears the sandbox down cleanly.
  • See the workspace status — whether it's starting, running, or stopped.
  • Glance at recent activity — a running log of what the workspace is doing.

You don't spend your day on this page — it's the on/off switch and status light. Your actual work happens in the surfaces it opens.

Your main surface: the Harness​

When the workspace is running, the Kenaz Harness is the surface you'll live in. Everything the Harness does on its own, it does here — just inside the sandbox:

  • Sessions — chat with the model, branch conversations, organize work into projects.
  • Providers — bring your own keys (Anthropic, OpenAI, and more). The first thing to do in a fresh workspace is add a provider.
  • Tools & MCP — run built-in tools and connect MCP servers, each gated by a permission prompt.
  • Context, memory, and an audit log — the same Harness features documented under Harness → Features.

If you've used the standalone Harness, this is identical — the Workbench just runs it in a contained environment.

Other surfaces​

Alongside the Harness you can open other tools, served right into the Workbench:

  • Code editor — a VS Code surface for editing files in the sandbox, handy when you and an agent are working on a project together.
  • Notebooks — a Jupyter surface for interactive analysis.
  • Headless browser — a sandboxed Chromium an agent can drive for web tasks, without touching your host browser or its logins.

Open these when you need them; the Harness is always the anchor.

The sandbox boundary​

The whole point of the Workbench is that your AI work is contained. Inside the workspace, agents and tools see an isolated Linux environment — not your host's files, network, or processes. That means:

  • An agent can't read your home directory, your SSH keys, or your other projects unless you deliberately share them.
  • Network access from inside the sandbox is mediated, not wide open.
  • What happens in a workspace stays in the workspace until you move it out.

When you want an agent to work on a real project, you bring it in on purpose rather than handing over your whole machine. For how files cross the boundary and what the guest environment contains, see Guest environment.

Opening and closing workspaces​

  • The first open on a machine is the slowest — the Workbench prepares the sandbox image. After that, opening is quick.
  • Close the workspace when you're done; it tears down cleanly. Keep anything you want to hang onto in a shared location rather than only inside a workspace you're about to close.

Signing in to Fleet​

If your team uses Kenaz Fleet, you sign the Harness in to Fleet from inside the Workbench exactly as you would in a standalone Harness — see Connecting to Fleet. It's optional; the Workbench works fully on its own.