Remote workspaces

Choose, prepare, operate, and retire a remote environment for agent-driven development.

A workspace is the machine context in which Jio reads files and runs tools. It may be a VM, container, dedicated host, or another environment with enforceable isolation.

Choose a workspace type

Type	Best for	Tradeoff
Long-lived	Ongoing product work	Faster iteration, more accumulated state
Task-scoped	Pull requests and bounded features	Cleaner state, more provisioning overhead
High-compute	Builds, tests, and model workloads	Higher cost and stronger quota requirements
Untrusted-code	Unknown repositories and experiments	Tighter networking and disposable state

Machine baseline

Before connecting an agent, establish:

a dedicated non-root workspace identity;
one explicit project root;
the runtime and build tools the project requires;
CPU, memory, storage, and process limits;
an outbound network policy;
a retention policy for files, logs, and credentials;
a reliable way to rebuild or replace the environment.

Workspace lifecycle

Provision

Create the machine or container from a known base and apply operating-system updates.

Materialize

Clone or upload the project, then install only the dependencies needed for the task.

Operate

Connect Jio, observe tool activity, and keep policy failures visible to the agent.

Collect

Preserve the intended code changes, test results, and any diagnostics needed for review.

Retain or destroy

Keep a trusted project workspace, or destroy an ephemeral one and revoke its credentials.

Prefer machine images, container definitions, or provisioning scripts over manually repaired hosts. A reproducible workspace is easier to audit and lets you replace a suspicious environment instead of trying to clean it in place.

Separate persistence from trust

Dependency caches can speed up ephemeral workspaces, but do not share writable caches across trust levels without a cleanup and integrity strategy.