> ## Documentation Index
> Fetch the complete documentation index at: https://nativeharness.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Requirements

> Node, a container engine, and a model — and how to check each before you depend on it.

## Node 22 or newer

Every package declares `engines.node >= 22`.

## A sandbox provider

Every command an agent runs happens in a sandbox, and the harness will not let a model's
commands run anywhere that does not isolate. The default provider is
[nativesandbox](https://nativesandbox.dev): containers through Podman or Docker, needing no
nested virtualisation and no `/dev/kvm`.

So the host needs a container engine reachable over its socket. On Linux, rootless Podman is
the recommended engine:

```bash theme={null}
sudo apt-get install -y podman
systemctl --user enable --now podman.socket
loginctl enable-linger "$USER"     # so the socket survives logout
```

Prove it rather than assume it — a limit the kernel *accepts and ignores* looks identical to
one it enforces until you read it back from inside:

```bash theme={null}
npx nativesandbox doctor --deep
```

The [nativesandbox requirements](https://nativesandbox.dev/getting-started/requirements) cover
Docker, macOS, cgroup delegation and the socket resolution order in detail.

<Note>
  `@nativeharness/sandbox-local` runs commands on the host with **no isolation**. It exists for
  tests and for trusted, deterministic scripts. The agent refuses to use it with a real model,
  and that refusal is enforced in code rather than documented.
</Note>

## A model, or none

The `core` layer has no model in it and needs no key. The `agent` layer needs one
`ModelAdapter`, and the five that ship read their keys from the environment:

| Adapter             | Key                                                                                                       |
| ------------------- | --------------------------------------------------------------------------------------------------------- |
| `adapter-anthropic` | `ANTHROPIC_API_KEY`                                                                                       |
| `adapter-openai`    | `OPENAI_API_KEY`, or `XAI_API_KEY`, `DEEPSEEK_API_KEY`, `GROQ_API_KEY`, `MISTRAL_API_KEY`, … per provider |
| `adapter-google`    | `GEMINI_API_KEY` or `GOOGLE_API_KEY`                                                                      |
| `adapter-cohere`    | `COHERE_API_KEY` or `CO_API_KEY`                                                                          |
| `adapter-ollama`    | none — a local server                                                                                     |

A `ScriptedAdapter` also ships: a deterministic model for tests and demos, which is how the
harness's own suite runs a whole turn with no key at all.

## Check everything at once

```bash theme={null}
nhar doctor
```

Reports the workspace root, the acting user, and whether the sandbox provider's engine answers.
It exits non-zero when it cannot, so it works as a deployment gate.