One runtime.
In your terminal.

What you’re setting up

The official Claude Code and Codex clients run unmodified in an NVIDIA OpenShell sandbox. Each loads ToolsEnabled Fleet as an MCP server. They share a work record under /sandbox/.toolsenabled, while maintaining their own provider conversations.

Fleet coordinates tasks, memory, file observations, and worker agents. OpenShell enforces filesystem and network access around those processes. Read the boundary explanation before using the beta.

Work in progress. Public beta.

Beta 3 runs on Linux x86-64 and on Windows through WSL 2 with Docker Desktop’s Linux engine. The same Linux archive installs inside the OpenShell sandbox. There is no native Windows runtime.

The engine’s default branch is the beta source branch, which contains the adapter. No Fleet container image is published.

New in beta 3: a two-command install; upgrades from beta 2 keep your setup, state and registrations; a pinned uninstall --keep-state works after a sandbox restart; and stricter ownership and permission checks.

Tested on this exact archive, as the beta 3 release notes list:

• Full Linux installs under umasks 0022, 0002 and 0077: setup, status, upgrade, state-preserving uninstall, and refusal of a scope whose state was kept.
• A Linux two-hour soak: 37 complete rounds, each including a real beta 2 to beta 3 upgrade.
• The frozen hand test, run twice: 42 checks passed and 0 failed each time. Its one scripted pending item is covered by a separate passing proof with real Codex and Claude Code tool calls.
• A host rehearsal on a Linux host with a fresh sandbox: the exact host command, then the printed command pasted into the sandbox. Install, setup and status completed, and both CLIs showed the Fleet registration. After publication, the same install ran from the release page’s downloads into another fresh sandbox, and it completed.
• The Windows two-hour soak on Windows 10 with WSL 2 and Docker Desktop’s Linux engine: 32 complete rounds, 288 checks passed, 0 failed. Its long-running process series lasted 7,388 seconds on the system’s monotonic clock; the WSL wall clock showed 6,955 seconds for the same span, and the qualification record discloses that difference. The Windows hand-test pair is still in progress.
• A file-by-file check of the archive against the public source.
• An independent security review of the install, upgrade and uninstall changes. Findings were fixed and re-reviewed before this build.

These checks exercise the integration; they are not a benchmark of autonomous work.

Host and sandbox requirements

• On Linux x86-64, use Docker Engine for the local OpenShell gateway.
• On Windows x86-64, run the OpenShell CLI inside a WSL 2 distribution and the local gateway with Docker Desktop’s Linux engine. The Fleet archive installs inside the Linux sandbox.
• OpenShell 0.1.2 with a running local Docker-backed gateway.
• In the sandbox: Node.js 22.19 or newer, Python 3.9 or newer, and Codex and/or Claude Code, installed by you.
• On the host: OpenShell 0.1.2, Python 3.9 or newer, Bash and curl.
• For the development image: a checkout of the beta release tag, which contains adapters/openshell.
• git, jq, and the Codex CLI on the host if using the gateway-held Codex sign-in.
• Access to Claude Code and/or Codex, and a browser for the official sign-in flows.

On Linux, beta 3 was tested on the baseline above; see its release notes. On Windows, beta 3 passed its two-hour soak on Windows 10 with WSL 2 and Docker Desktop’s Linux engine (32 rounds, 0 failures; see current status). A Windows-hosted hand-test pair and real-provider sessions on Windows are still in progress. The Windows (WSL 2) setup guide walks through the Windows host; see the release notes for current results. Use OpenShell’s own documentation to install and configure it.

Install beta 3 with two commands

1. On the host (Linux, or Bash in WSL 2): run the release-pinned host command from the beta 3 release notes. It checks the helper and archive hashes and transfers the archive into your OpenShell sandbox.
2. Inside the sandbox: paste the command it prints. It installs Fleet, runs setup and shows the status.

The host command is long, so it lives in the release notes rather than on this page. Fleet installs the toolsenabled command; the archive, paths and environment variables keep the toolsenabled name. Upgrading from beta 2 keeps your setup, state and registrations. The install guide covers the details, upgrade and uninstall.

On Windows, run the host command in Bash in your WSL 2 distribution, following the Windows (WSL 2) setup guide (see the release notes for current results). The same Linux x64 archive installs inside the OpenShell sandbox. There is no native Windows runtime and no published Fleet container image.

Sign in through each client’s own login flow. Installation leaves your provider configuration and OpenShell policy in place.

Or build the development image in five steps

This optional Linux development recipe builds an image with the official clients and Fleet, then creates a sandbox from it. The Windows host route above uses the release archive.

1. Build the image.

Clone the beta release tag, then build the image into the container engine used by your gateway. The build uses committed files.

git clone --branch openshell-beta3-20261001 --depth 1 https://github.com/ToolsEnabled/toolsenabled-engine.git
cd toolsenabled-engine
adapters/openshell/image/build.sh toolsenabled-openshell:wip

2. Import the Codex provider profile.

Skip this and step 3 for a Claude-only setup. Review and import the profile from OpenShell’s versioned Codex example.

curl -fsSLO https://raw.githubusercontent.com/NVIDIA/OpenShell/v0.1.2/examples/codex-app-server/codex.yaml
openshell provider profile lint --file codex.yaml
openshell provider profile import --file codex.yaml

3. Create the Codex provider.

Follow the dedicated sign-in and refresh configuration in adapters/openshell/README.md at the beta tag. It creates an OpenShell provider named codex, using a separate host sign-in. Keep token values out of command-line arguments.

OpenShell’s Codex example describes the underlying provider mechanism. Complete this step before the next command uses --provider codex.

4. Create the sandbox.

Review adapters/openshell/policy/cli-sign-in.yaml first. For Claude-only use, omit --provider codex. The advisor setting may take about 30 seconds to become available.

openshell sandbox create --name te --from toolsenabled-openshell:wip \
  --policy adapters/openshell/policy/cli-sign-in.yaml \
  --provider codex --env CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 --detach

openshell settings set te --key agent_policy_proposals_enabled --value true
openshell sandbox exec -n te --tty -- bash

5. Sign in and add Fleet.

Run inside the sandbox. Skip codex-openshell-auth if no Codex provider is attached. In Claude Code, use /login, finish its browser flow, then /exit. Use only the client you need.

codex-openshell-auth
claude
toolsenabled setup --add
toolsenabled status

Add --agents to setup for worker agents, or --audit for the signed activity log. Check registration with claude mcp list and codex mcp list. Fleet’s setup does not perform provider sign-in or change sandbox policy.

Stay in charge from the shell.

toolsenabled ledger answer A3 Keep the existing API behavior

These controls run inside the sandbox and are available to processes sharing that user. Use OpenShell on the host for access approval.

Other models and your own endpoints

The development adapter can configure Codex to use a hosted compatible endpoint or a server on your machine, with credentials managed by OpenShell. Read adapters/openshell/MODELS.md at the beta tag.

Codex requires the Responses API. An endpoint offering only /chat/completions cannot serve this Codex configuration. Check the endpoint’s actual API support before using NVIDIA’s API catalog, NIM, vLLM, Ollama, or another provider.

This path has been tested with local stand-in servers. Hosted provider support is not established for every service named in the guide.

Use Fleet with DeepSeek Harness

ToolsEnabled Fleet is compatible with DeepSeek Harness. DeepSeek Harness connects to Fleet as an MCP server through its built-in MCP client, so a DeepSeek Harness agent can use Fleet’s shared work record, memory and the other tools your Fleet tier allows.

Run DeepSeek Harness in the same sandbox as Fleet. A helper writes a DeepSeek Harness overlay from your Fleet setup: copy it into the sandbox, run it once there, then start DeepSeek Harness with the overlay.

curl -fsSLO https://raw.githubusercontent.com/ToolsEnabled/toolsenabled-engine/openshell-beta-source-20260930/adapters/openshell/deepseek-harness/fleet-dsh-overlay.py
openshell sandbox upload YOUR_SANDBOX fleet-dsh-overlay.py /sandbox/

python3 /sandbox/fleet-dsh-overlay.py
dsh web --patch ~/toolsenabled-fleet.cordis.yml

The DeepSeek Harness guide covers the Python SDK, keeping Fleet across runs, and example sandbox policy rules.

Tested on 2026-10-01: Fleet 1.4.2 (beta 3) with the DeepSeek Harness Python SDK 0.1.5rc1, using DeepSeek V4.1 Flash through NVIDIA’s OpenAI-compatible endpoint, in a fresh OpenShell sandbox.

Limits. Tools follow your Fleet tier (the guided tier gives read-only task and memory tools), and DeepSeek Harness actions are recorded without an agent label for now. DeepSeek Harness is the lead agent, while Fleet’s workers are still Codex and Claude Code.

ToolsEnabled is not affiliated with or endorsed by DeepSeek. “DeepSeek Harness” is a trademark of DeepSeek.

A few practical questions