One session.
A whole fleet.

The default workspace is ~/work. Append --workspace ABS to the install command to select a project inside your account home, or your account home itself for a global workspace. Hidden top-level home entries, including dotfiles and dot folders, are never part of a workspace. Symbolic-link aliases are refused. For a global workspace, workers start in the lead's working folder, and the archive must sit outside the workspace: keep it outside your home folder or in a hidden folder such as ~/.cache.

Workers are experimental and off by default. To enable them, append --enable-workers at installation. They require Linux 5.3+, usable pidfd_open, process observation/signalling, subreaper support and a passing containment check. Fleet refuses if these are unavailable.

Installation creates a separate runtime and state and registers the Fleet MCP entry with installed described CLIs. Restart your agent sessions afterwards. The command is ~/.local/toolsenabled-host/toolsenabled-installer/toolsenabled; invoke it by its full path because setup does not add it to PATH. Use it for the status and agents commands shown on this page.

Install into an existing Linux x86_64 NVIDIA OpenShell sandbox. OpenShell provides filesystem and network confinement, access approvals and custody of the credentials it manages. Fleet does not install OpenShell or change its policy.

Install Node.js 22.19.0+, Python 3.9+ at /usr/bin/python3, and the agent CLIs you use in the sandbox image first. The documented compatibility baseline is OpenShell 0.1.2 with rootful Docker on Linux x86_64. The WSL 2 route with Docker Desktop's Linux engine is experimental; this is not a claim of qualification for every version or platform.

On the host, put SHA256SUMS and all archives it lists in the same directory, and check that its digests match the ones above. Continue to upload only after verification succeeds; replace YOUR_SANDBOX with your sandbox's name.

sha256sum -c SHA256SUMS
openshell sandbox upload --no-git-ignore YOUR_SANDBOX toolsenabled-openshell-1.9.2-linux-x64.tar.gz /sandbox/

Then, inside that sandbox:

cd /sandbox
umask 077
tar -xzf toolsenabled-openshell-1.9.2-linux-x64.tar.gz
bash toolsenabled-installer/install.sh --setup \
--archive /sandbox/toolsenabled-openshell-1.9.2-linux-x64.tar.gz \
--sha256 e000827eb09d0d737d87185ccfdb7551955cf905ede897b4a90e03e61c04fb44
source ~/.local/toolsenabled/env.sh
toolsenabled status

The installer runs setup for you: it registers Fleet with each installed described CLI, with workers on and every described worker agent allowed. Sign in through each CLI's own flow, then start a new agent session. To change those choices later, run setup again, for example toolsenabled setup --agents --providers AGENT[,AGENT...] --add with ids from toolsenabled agents, or toolsenabled setup --add for no workers. Setup replaces only the entries its own record shows it wrote. In a new shell, source the installed prefix's env.sh again.

The optional toolsenabled-authority service keeps settings, ledger and signed audit outside the sandbox on the machine running OpenShell. Its listener is loopback only, with separate per-agent grants held by OpenShell providers. You configure those providers and policy yourself. The source archive includes the setup guide at adapters/openshell/HOST-OUTSIDE.md.

Without that separate authority, Fleet's record and optional signed audit run as the same sandbox user as the agents. They are not tamper-proof against those agents. The outside authority does not control sandbox file access or anchor the sandbox's audit.

Start your own lead agent and connect Fleet as a stdio MCP server. Workers can use installed agent CLIs, your own API model connections, or local model servers you already run.

Agent CLIs

Bundled descriptors cover Claude Code, Codex, Gemini CLI and OpenCode. Any of them can be your lead, and any of them can be a worker, subject to their enforceable permission levels. You can add a descriptor for another CLI; worker support also needs a compatible protocol driver.

API models

Direct model workers support OpenAI Chat Completions, OpenAI Responses and Anthropic Messages formats, with your own keys and billing.

Local models

Connect an existing Ollama, LM Studio, vLLM, llama.cpp or SGLang server. Fleet does not install or start a model server. The exact endpoint and model must support structured tool calls; format support alone is not model qualification. Give a local model a context window of at least 16,000 tokens: Fleet's tool definitions do not fit Ollama's default of 4,096.

toolsenabled agents shows what Fleet found. It uses each CLI's own status command when available and labels unknown sign-in states. Local discovery asks loopback model servers which models they serve.

Google currently documents personal Gemini CLI sign-in, including eligible AI Pro and Ultra accounts. Fleet has not qualified personal-subscription workers, and one reported test of the official CLI rejected an existing individual login. These are compatibility limits, not evidence of a universal end to personal sign-in. Google’s FAQ prohibits OAuth credential harvesting or replay and directs third-party coding agents to API-key or Vertex AI authentication. Use a route permitted for your deployment; do not work around a rejected sign-in. Gemini also turns MCP servers off in untrusted folders; trust your working folder through Gemini’s own controls.

Codex and Gemini CLI do not pass your API keys or tokens to MCP servers unless you allow them. Fleet asks them to pass only the agents' profile folders, so workers use the same profiles as your lead. To let workers use a key from your environment, run setup with --pass-env NAME[,NAME...]. Fleet records the names only; the agent passes the values when it runs.

OpenCode workers need a lead started with its no-prompts setting (level 4), and a role that keeps that level. A headless worker cannot show approval prompts; Fleet refuses to start one if its CLI cannot enforce the inherited limits.

For another MCP client, toolsenabled setup --print-server-json prints the server entry. Fleet installs only Fleet. Install and sign in to agent CLIs through their own instructions, where Fleet will run.

You start your lead however you like. Fleet reads its command line to find the permission level. Every worker inherits that level, reduced by its role and every ancestor. Roles only take permissions away.

1. Read only

   Reads, without edits.

2. Asks

   The agent's normal approval mode. A worker declines anything that would prompt.

3. Edits on its own

   Edits within the agent's inherited limits without asking for each edit.

4. Everything

   The lead's no-prompts level, still subject to role limits and any outer sandbox.

If Fleet cannot read the lead's level, it uses level 2. If a worker cannot enforce its inherited level or tool removals, Fleet refuses to start it. Each worker's own sub-agent feature is switched off so delegation stays within Fleet's tree and limits.

Fleet sets no permission of its own, adds no permission grants to agent settings, and blocks nothing you chose for your lead. Its file tools still respect their workspace boundary and protected paths. Host mode supplies no sandbox; in sandbox mode, OpenShell supplies the confinement.

Host mode: close agent sessions and configuration writers. Keep the original approved archive and digest. Verify and extract that same archive into a fresh private stage outside the installed runtime, using the verification and extraction lines above, then run:

bash "$stage/toolsenabled-installer/install.sh" --uninstall \
--archive "$archive" --sha256 "$release_sha256"

Repeat the original --prefix, --state-root and --workspace arguments if customized. Removal verifies the matching Fleet entries and pinned runtime; shared state remains.

Sandbox mode: stop agent sessions and Fleet tree hosts using the installation. Inside the sandbox, with the original archive still at /sandbox:

toolsenabled uninstall --keep-state \
--archive /sandbox/toolsenabled-openshell-1.9.2-linux-x64.tar.gz \
--sha256 e000827eb09d0d737d87185ccfdb7551955cf905ede897b4a90e03e61c04fb44

Uninstall retains state. Changed files, unknown contents or registrations whose ownership cannot be proven can stop removal. Preserve reported recovery material for review. The source archive includes the full lifecycle guides at docs/HOST-MODE.md and installer/openshell/README.md.

Workers get their lead's level from Claude's native install

Claude's native installer runs a file named after its version, such as ~/.local/share/claude/versions/2.1.302. Fleet did not recognise that as Claude, so every worker it started fell back to level 2, where each file write needs a confirmation that a headless worker cannot show: the write timed out and the worker carried on without writing anything. Fleet now treats claude/versions/<version> as Claude. The level still comes only from the lead's own flags, a file that is not a version number is still not an agent, a lead Fleet cannot see is still level 2, and TOOLSENABLED_LEVEL_CAP still only lowers. Check a tree with each worker's permissionContext: source: ancestor-cli means Fleet found its lead.

A node recorded through a link works

When setup recorded node through a link to the binary, such as /usr/local/bin/node, every direct model worker was refused with HOST_CONFIG_MISMATCH. Fleet now compares the real paths. A link to any other program is still refused.

Clearer effort refusals, and Daybreak Blue

A model with no effort choices now says so, instead of "It accepts: none." Codex's gpt-daybreak-blue-latest is a worker choice, daybreak, with reasoning depths low through ultra.

Unchanged

Workers still run until they answer: no round cap, token budget, deadline or continuation turn cap. A request or tool call that gives no answer at all for 30 minutes ends the assignment and says so.

How 1.9.2 was checked

Automated tests

All 470 automated test files pass for the release source: 463 in a clean environment, and the seven that use the system keyring with a private one. New tests for a lead started from Claude's native installer and for the descriptor's launcher list fail on 1.9.1 and pass on 1.9.2, and breaking either check makes a test fail.

Real agent CLIs

Hand tests drive the real, unmodified Claude Code 2.1.305, Codex 0.162.1, Gemini CLI 0.58.0 and OpenCode 1.18.34 against a local model simulator, from a frozen copy of the release source. Three of four runs on the release commit passed all 90 applicable checks. The other, run while the laptop was heavily loaded, failed 10 checks for Gemini and OpenCode leads that passed in every other run. Six combinations are unsupported by design. Claude Code 2.1.305 defers MCP tools behind its tool search, which a real model uses on its own; the simulator cannot, so the hand tests set Claude Code's ENABLE_TOOL_SEARCH=false.

Exact archives

The published host archive was installed with workers and uninstalled in a separate account home with its own agent profiles. The sandbox archive was installed in a fresh OpenShell 0.1.2 sandbox, set up again with --pass-env, and uninstalled. Both used the commands on this page.

The fix, end to end

The published host archive, started from a Claude Code lead run from the native installer in bypass mode, gave a real Codex worker level 4 from that lead. The worker wrote a file and read it back.

Not yet measured

Apart from that one Codex worker, these checks use a simulator in place of model providers and no real sign-ins, so they say nothing about how well a given model does the work. Windows (WSL 2) and OpenShell versions other than 0.1.2 were not part of this round. The Windows candidate 1.10.0-rc.1 is a separate line and does not yet include this fix.