The deterministic foundation
for AI agents
The harness is probabilistic by design. The environment under it should not be. Flox pins one manifest to the same toolchain under every agent harness, on your laptop and in the cloud.
Pin the toolchain once, then run the agent inside it
One manifest, the same hash on every machine
“Flox gives us a dependable foundation so we can move fast with tight feedback loops.”
Why it matters
An agent is only as reproducible as the environment it runs in
When the toolchain, services, and pinned versions drift between a laptop, a sandbox, and CI, the agent ends up debugging the substrate instead of doing the work, and you cannot tell a real failure from a setup one.
Flox is that substrate. One declarative manifest, resolving against 120,000+ packages into a hash-pinned closure. The same definition activates the same way whether a person runs flox activate or an agent harness does it for them, fully reproducible every time.
Anatomy of an agent
Flox is the substrate under the whole agent stack
A coding agent is a tower of moving parts: a harness on top, a sandbox it runs in, plugins and MCP servers it calls, and skills that encode how to work. Every layer assumes a runtime is already there. Flox is that runtime, pinned and identical wherever the agent lands.
Swap the harness, change sandboxes, add an MCP server: the base layer does not move. The agent always resolves the same toolchain, services, and pinned versions.
Local
Composes with VS Code, Docker, devcontainers
Flox does not replace the tools your agents run in, it slots underneath them. Open the repo in VS Code, attach a devcontainer, or start a Docker box, then run flox activate and the harness drops straight into the pinned environment. Same toolchain, same services, every session.
- The editor, its terminal, and its agent all share one reproducible runtime.
- The devcontainer or Docker box stays as the isolation boundary; Flox guarantees what is inside it.
- No hand-rolled setup script that drifts away from a teammate's machine.
Remote
The same environment follows to a remote sandbox
When the agent moves to a hosted sandbox (Coder, DevPod, Daytona, E2B, Fly, or Cloudflare) the manifest resolves to the same closure it did on the laptop. Skills carry the workflow, and a hook supplies credentials only for the life of the run.
Workflow follows the agent
Skills like code-review, TDD, and your org playbooks travel with the environment. The agent works the same way on a remote sandbox as it did on the laptop, no re-teaching per machine.
Secrets injected at the boundary
A Flox activation hook fetches credentials when the env comes up, so the agent gets exactly the secrets it needs and nothing is written into a manifest, an image, or the repo.
Short-lived, never persisted
Those credentials are short-lived and scoped to the run. Their lifetime is set by your secrets backend, and they expire the moment the sandbox is torn down, so nothing outlives the session.
Nothing is baked into an image, nothing persists on the host. The remote run is the laptop run, on someone else's hardware.
Where Flox fits
One job in the stack, done deterministically
Flox is not another harness or sandbox. It owns one layer, the environment, and leaves the rest of the agent stack to the tools built for it.
The environment and the hooks
The reproducible, hash-pinned toolchain every agent resolves against, plus the activation hooks that wire in services and short-lived secrets at the boundary. One manifest, identical everywhere.
Harness and sandbox internals
How Claude Code reasons, how an MCP server talks to GitHub, how a devcontainer or E2B box isolates a run: that stays with the tools you already chose. Flox feeds them, it does not reinvent them.
The curated first mile
Which packages, versions, and skills are blessed for agents, published as a shared environment. Developers and agents inherit the golden path instead of assembling one per repo.
Clean seams, no overlap
Flox stops at the environment, so swapping a harness, a sandbox, or an MCP server never means re-pinning the runtime. The seams stay clean as the agent ecosystem keeps moving.
FAQ
Questions teams ask first
Yes. NVIDIA licensed Flox, with the Nix Foundation, to redistribute prebuilt CUDA, so the CUDA Toolkit, cuDNN, and TensorRT install from the Flox Catalog in seconds instead of hours of compilation. CUDA goes in the same manifest as your language runtimes, so an agent doing ML or inference work resolves the same GPU toolchain on a laptop, in CI, and in a remote sandbox.
No. Flox runs inside it. Keep the devcontainer, the hosted sandbox, Docker, Podman, Apple Container, or whatever isolation your agents use, and let Flox define the reproducible environment that runs in it. The boundary stays yours; Flox pins the contents.
Because the model's reasoning is the only part that should vary. If the environment underneath it also drifts, you stack two sources of nondeterminism and can no longer tell a real failure from a setup one. You cannot make the model deterministic, but you can keep everything beneath it from moving. Pin the environment and every run starts from the same toolchain, services, and versions, so the only thing that changes between runs is the part that is meant to.
You wrap the command. There is no agent plugin to install and no per-harness integration to maintain. Prefix the agent invocation with flox activate, as in flox activate -- claude, and the harness starts inside the pinned environment with the right toolchain, services, and secrets already in place. Swap the harness or the sandbox later and the wrapper stays the same.
Yes, and the change is captured instead of lost. When an agent needs a tool it does not have, it runs flox install and the package is added to the manifest, so the next activation on any machine includes it. That is the difference from an agent running pip install or apt-getinside a container: those mutations disappear when the sandbox is torn down, or drift away from everyone else’s setup. With Flox the environment stays declarative, so whatever the agent added is reproducible and reviewable, not a one-off.
Anything that can run a shell can run flox activate, so Flox is harness-agnostic by construction. The same environment activates under Claude Code, Codex CLI, Gemini CLI, Copilot CLI, Cursor, Windsurf, and whatever you adopt next, with no per-harness integration to build or maintain.
No. Flox is built on Nix and gives you its reproducibility, but you define agent environments with a declarative manifest and never write Nix. Drop down to it only if you want to.
Give every agent the same ground truth
One reproducible environment that resolves to the same hash under any harness, in any sandbox, on a laptop and in the cloud. Talk to us and we'll map it to your agent stack, or read the docs and try it yourself.