Workspaces

A workspace is your own interactive dev environment, in the browser, running on your org's GPUs. Open it and you get JupyterLab, a full VS Code editor, a terminal, and a built-in coding agent, all sharing one home directory, one Python environment, one CUDA stack, and one GPU allocation. You launch it, work in it for hours or days, and delete it when you're done. Nothing you do in it, code, data, or model weights, leaves your infrastructure.

It's the place to prototype a model, explore a dataset on real hardware, or drive an AI coding agent against a repo, without setting anything up locally.

Where it lives

Workspaces in the sidebar app-nav, or /workspaces directly. The page lists every workspace you own plus any a teammate has shared, each row with buttons to open its surfaces and manage it.

Launching a workspace

Click New workspace and pick a few things:

Launch it and the workspace boots in under a minute (the CPU type is ready in seconds). A new workspace is private to you until you choose to share it.

Every type carries the same four surfaces and the same shell, so the tools and keyboard muscle-memory are identical whichever you pick, only the preinstalled science stack differs. The Python training SDK is preinstalled and pre-wired, so the first cell of a notebook can submit a training job or log to MLflow with no key to paste and no endpoint to configure.

The surfaces

Each workspace row has a button per surface. They all open the same files in the same environment, so you can start a script in the editor, run it in the terminal, and inspect the output in a notebook without anything getting out of sync.

The built-in coding agent

Open OpenCode drops you straight into a terminal coding agent that reads and writes the very same files as your notebook and editor. Because it lives in the same environment, it isn't looking at a copy of your repo, it edits your actual working tree.

The point of it: it runs entirely on your org's own models, through the platform. There's no API key to paste and no external provider, so a prompt, a file, or a token never leaves your infrastructure. The agent exposes your models under stable roles you can switch between, coding (the default), reasoning for whole-repo work, and fast for quick tasks, so you're always pointed at one of your own served models.

If you prefer your own machine, the same agent configuration is downloadable from the app so a local OpenCode talks to your models the same way. See Coding agents.

Sharing with your team

A workspace is private until you flip its visibility to shared, which makes it reachable by everyone in your org. Sharing changes only who can see it, never who owns it: there's no "claim this workspace" anywhere, so a dozen teammates can use a shared workspace without any of them quietly becoming its owner. Only you (or a compute admin) can change whether it's shared or private.

Because a single workspace is one environment on one filesystem, two people typing into it at once would collide. So a shared workspace hands out a single active session at a time:

• Open gives you the surfaces if the workspace is free, stale, or already yours. If a teammate is in it, you'll see In use by <name> instead.
• Take over (owner or admin) seizes the active session from whoever holds it.
• Release frees the seat for the next person when you're done driving.

A session you walk away from is reclaimed automatically after 30 minutes, so a forgotten workspace never blocks the seat forever.

Real-time collaboration on a notebook

For live co-editing, flip a workspace to Collaborative and several people can edit the same notebook at once, each with a named cursor and live selections. You'll see collaborators' initials in an avatar and their full names in the Online Collaborators panel and on their cursors as they type.

A few things to know:

• It's available on the lightweight CPU workspace type.
• Turning it on restarts the workspace to serve JupyterLab only, so the VS Code, terminal, and OpenCode surfaces step aside while it's collaborative (co-editing is a notebook feature). The restart clears running kernels, and the app confirms before it does so.
• The single-active-session lock is dropped while collaborative, since many people at once is the whole point.

Connect from your own machine (SSH)

You don't have to live in the browser. You can point your own machine's tools straight at the workspace, VS Code Remote-SSH, scp, rsync, and git over SSH, landing in the same environment on the same home directory. There's no VPN and no ports to open; the connection rides the same secure path the browser uses.

Set it up once:

1. Add your public key. Open the SSH Keys tab in the Workspaces pane and paste your ~/.ssh/id_ed25519.pub line, GitHub-style. One key set applies to every workspace you own, and adding or removing a key takes effect on your running workspaces without a restart.
2. Install the helper and sign in. The app serves a small CLI, pre-pointed at your deployment:
   shell Copy

   curl -fsSL https://privatemind.com/pm/install.sh | sh

   Then run pm login: it shows a short code, you approve it in the browser where you're already signed in, and you're set. Once per machine.
3. Connect. The Workspaces pane hands you a ready-made ~/.ssh/config block. Paste it in and connect with ssh <workspace>, or use VS Code → Connect to Host against the same alias. scp, rsync, and git all work with no extra setup.

Start directory and git identity

Two per-person conveniences make a fresh workspace feel like yours.

Start directory. By default the terminal, VS Code, and the coding agent open at your home directory. Set a start directory and they open into a specific project instead, so one workspace can serve several projects rather than being a single-purpose seat. A ready-made ~/projects folder is waiting for you to clone into; point the start directory there and the coding agent's @ picker immediately has real files to offer. JupyterLab is the exception: it lands focused on the start directory but still lets you navigate up to the rest of your files.

Git identity. Your name and email are seeded into git from your account at launch, so git commit just works, no Author identity unknown on your first commit. If you've already set your own user.email in the workspace, the seed leaves it alone, so a hand-set identity is never overwritten.

Where next

• Training: submit distributed training jobs to your GPU allocation and track every run in MLflow, from a notebook or a script.
• Coding agents: point OpenCode, Cursor, Cline, Continue, and other agents on your own machine at your org's models.