Auto-Activation Is Now Native in Flox

We noticed people hacking direnv so they could use it to auto-activate their Flox environments.

So we built a native auto-activation feature.

Flox already lets you define cross-platform, reproducible environments as code. A Flox environment declares a project’s runtime, packages, variables, hooks, managed services, even build recipes. But until now, you had to manually run flox activate to enter into an environment. Now, with Flox-native auto-activation, whenever a directory contains a valid Flox environment, that environment starts up as soon as you cd into it. In the same way, the environment automatically deactivates when you change out of it.

Flox can even auto-start a project’s services … and stop them when you leave:

• Enter the directory and Flox activates the environment and starts its declared services.
• Leave the directory and Flox stops those services, deactivates the environment, and restores your shell.

This means when you’re in your flow... everything just works. Your tools, your environment, your whole dev setup: every action flows easily, one to another. You don’t even have to think about it.

Auto-Activating / De-Activating an Environment

Let’s start with a simple example… a Flox environment that runs a llama.cpp model server for inference workloads:

schema-version = "1.13.0"
 
[install]
llamacpp.pkg-path = "flox-labs/llamacpp"
llamacpp.pkg-group = "llamacpp"
llamacpp.systems = ["aarch64-darwin", "aarch64-linux", "x86_64-linux"]
 
[services]
auto-start = true
 
[services.llamacpp]
command = '''
  [ -f "$FLOX_ENV_CACHE/llama-server.env" ] && . "$FLOX_ENV_CACHE/llama-server.env"
  exec llamacpp-proxy \
    --listen "${LLAMACPP_HOST:-127.0.0.1}:${LLAMACPP_PROXY_PORT:-8081}" \
    --backend "${LLAMACPP_HOST:-127.0.0.1}:${LLAMACPP_PORT:-8080}" \
    --backend-api-key "${LLAMACPP_API_KEY:-llamacpp-local}"
'''

The [services.llamacpp] table declares the service. The new auto-start = true setting tells Flox to start declared services when the environment activates via auto-activation. When you change into a directory that contains a Flox environment, Flox prompts you: Do you want to auto-activate? Yay or nay?

~/dev$ cd llamacpp
Auto-activate the environment in '/home/floxuser/dev/llamacpp'? [y/N] y

Flox remembers this decision for each environment. If you allow auto-activation, entering the directory activates the environment and (if auto-start = true is set in the manifest) starts any declared services.

flox [llamacpp]:~/dev/llamacpp$ flox services status
NAME    STATUS   PID
llamacpp   Running  1694723

Changing out of the directory deactivates the environment and stops the service:

flox [llamacpp]:~/dev/llamacpp$ cd ..
~/dev$ flox services status -d ./llamacpp
NAME    STATUS
llamacpp   Stopped

Changing back in reactivates it again:

~/dev$ cd llamacpp
flox [llamacpp]:~/dev/llamacpp$ flox services status
NAME    STATUS   PID
llamacpp   Running  1700183

The upshot is that Flox tracks whether an environment remains in scope, manages the services associated with each activation, and restores your shell whenever you leave the environment.

Activating Nested Environments

Flox now auto-activates nested environments, too. This is especially useful with monorepos, where nested environments define distinct tools, runtimes, or services… while also inheriting a shared base environment.

Imagine that you cd directly into your working directory: a retrieval-augmented generation (RAG) project that’s nested inside Flox environments that support data prep, generate embeddings, and serve models:

~$ cd ~/dev/ai-base/ingest/embeddings/rag_app
Auto-activate these 4 environments?
  /home/daedalus/dev/ai-base
  /home/daedalus/dev/ai-base/ingest
  /home/daedalus/dev/ai-base/ingest/embeddings
  /home/daedalus/dev/ai-base/ingest/embeddings/rag_app
[y/N]

Each directory in this path contains its own .flox environment:

~/dev/ai-base/.flox
    └── ingest/.flox
        └── embeddings/.flox
            └── rag_app/.flox

In this stack:

• ai-base provides shared tools such as Python, uv, Git LFS, and so on;
• ingest adds file-parsing dependencies + a service that monitors an input directory for file drops;
• embeddings adds PyTorch, Sentence Transformers, and a local vector database service;
• rag_app` provides the project’s runtime, API server, retrieval configuration, and dev commands.

Flox is smart enough to auto-activate the environments from the outside in:

ai-base → ingest → embeddings → rag_app

Defining services.auto-start = true in ingest and embeddings starts their services automatically.

Running Tools inside an Already-Activated Environment

The way Flox works is that any commands you run inside an activated environment automatically inherit that environment’s shell settings … including access to binaries, libraries, or executable commands on PATH.

With auto-activation, changing into a directory containing a Flox environment (or a nested series of Flox environments) gives Claude Code, Codex, OpenCode, and other coding harnesses automatic access to anything declared as part of that environment or layered stack.

I can’t tell you how many times I’ve forgotten to activate an environment when working with AI agents. I could have used direnv for this, but for reasons aforesaid, direnv doesn’t fit neatly into my preferred Flox workflow.

Now when I jump directly into ~/dev/ai-base/ingest/embeddings/rag_app and run Claude Code, it has access to everything in the ai-base stack:

flox [rag-app embeddings ingest ai-base]$~/dev/ai-base/ingest/embeddings/rag_app$ claude
╭─── Claude Code v2.1.198 ─────────────────────────────────╮
│                                                          │
│                  Welcome back floxuser!                  │
│                                                          │
│                         ▐▛███▜▌                          │
│                        ▝▜█████▛▘                         │
│                          ▘▘ ▝▝                           │
│                                                          │
│   Opus 4.8 (1M context) with me… · Claude Max ·          │
│   flox-user@flox.dev’s Organization                      │
│   ~/dev/ai-base/ingest/embeddings/rag_app                │
│                                                          │
├──────────────────────────────────────────────────────────┤
│                                                          │
│   Tips for getting started                               │
│   Run /init to create a CLAUDE.md file with              │
│   instructions for Claude                                │
│                                                          │
│   Recent activity                                        │
│   No recent activity                                     │
│                                                          │
╰──────────────────────────────────────────────────────────╯
────────────────────────────────────────────────────────────
❯  investigate why newly ingested documents are not appearing in RAG query results. use the active
flox environment. confirm that the ingestion worker is parsing the source files, embeddings are being
generated with the configured model, the vectors are being written to the local vector database, and
the RAG API is querying the correct collection. identify the root cause and fix it.
────────────────────────────────────────────────────────────

Opt in to Use It

Flox does not auto-activate environments without your say-so. You must explicitly opt in. So the first time you cd into a directory with a Flox environment, Flox will prompt you before activating it.

To make auto-activation the default behavior, run flox activate allow while inside the directory. To turn off auto-activation, run flox activate deny. You can proactively add environments (i.e., before explicitly changing into them and being prompted) by running the following command:

$ flox activate allow -d path/to/environment

To revert auto-activation for any environment, change into its parent directory and do:

$ flox activate deny

You can also do flox activate deny -d path/to/environment without changing into the directory.

The new services.auto-start setting is useful when you’re building, testing, or debugging inside a Flox environment that defines services. Its behavior is binary, however: to cd into an environment’s directory is to start its services; to cd out is to stop them, regardless of whether that’s what you want. If you need an environment’s services to remain available as you move around your filesystem, you can explicitly activate it: e.g., flox activate -s -d ./path/to/flox-environment. This way, the environment remains active (and its services keep running) irrespective of where you’re working or what you’re doing on your system.

Discover How Flox Transforms Your Workflow

Native support for auto-activation makes your Flox workflow faster and completely friction-free.

Now when you move into a repo, the right tools, variables, services, and layered environments are always available … without your having to do anything. When you move out, Flox automatically cleans up after you.

It’s just one example of how Flox helps streamline and optimize your flow. With declarative environments, reproducible behavior at build and runtime, built-in service management, and support for layering or composing environments, Flox makes it simple to reuse project setups across humans, shells, and agents … locally, in CI, and in production.

Want a tour? Start with Flox in 5 minutes, or read the docs to learn more about auto-activation in Flox!