---
title: Limitations
description: What this sandbox doesn't do, and what breaks if you expect it to.
sidebar:
  order: 7
---

## No isolation

Nothing sits between the agent and your machine. It runs as your user, can read and write any file you can, and inherits your environment variables, including `ANTHROPIC_API_KEY`. The harness logs a warning that credential brokering is unavailable and forwards the key into the process environment, because there is no boundary to broker across.

A prompt injection in a file the agent reads has the same reach you do. Use this where you would run the CLI yourself, and use a remote sandbox for untrusted input.

## No resume

A harness session can't be resumed across processes. The bridge the harness starts is a child of your process and exits with it, so there is nothing to reattach to. The provider omits `resumeSession`, and resuming through `HarnessAgent({ sandbox })` throws `HarnessCapabilityUnsupportedError`.

## No network policy or port control

Nothing local can enforce outbound network rules, and every port is already leased per session, so the sandbox has no `setNetworkPolicy` or `setPorts`. Code that calls them optionally, as the harness does, gets no effect.

## POSIX only

Commands run through `/bin/bash`, so macOS and Linux are supported and Windows is not.

## One process, one port registry

Ports are leased from a registry inside your process. Two separate Node processes can be handed the same port, and a program outside the registry can take a port between the lease and the moment the bridge binds it.

## Adapter coverage

Claude Code, Codex (`gpt-6-luna`), and pi (`xai/grok-4.3`) were run end to end against this sandbox. For OpenCode, the bootstrap and session creation were verified, but a full turn is still unverified because the only available xAI login was a stale v1 one.

## Shutdown is partial

`stop()` and `destroy()` send `SIGTERM` to each tracked process and its current descendants, then return without waiting for the processes to exit, don't touch processes started after they are called, and never delete the directory. A process whose parent already exited can't be found, so it is not signalled. Details are in [Sessions and processes](/sessions-and-processes#stop-and-destroy).

The OpenCode adapter currently leaves `opencode serve` running after `session.destroy()`, because its bridge exits without stopping it. That is upstream adapter behavior, and the orphan is out of reach of `stop()`, so kill it yourself if that matters.